I've tested this approach and it seems to work fine. Two further comments: - Workaround in installupdate.py was removed. We need to do more testing around beadm to try and trigger an error condition to see if simply setting _ = gettext.gettext sorts this in the beadm.py module solves this, if it doesn't we might have to put back the getext.install() but I'd prefer not to.
- GUI, we are setting self._ = gettext.gettext as a convenience which we access in its children using self.parent._ - We are allowing the path to the domain to be set relative to the application dir if needed, using environment variables for PM, UM and UMN, so the domain initialization code needs to be in the init, as opposed to the top of the file. Fujiwara and Danek can you review this patch. I have moved the gettext.install() in client.py to the top of the file as the guidelines I've been reading seems to be the pattern that is most commonly used, but if you want it moved back to main just let me know. I have also added the setlocale here as well to "set the locale for all categories to the user's default setting (typically specified in the LANG environment variable)." http://www.python.org/doc/2.5.2/lib/module-locale.html http://cr.opensolaris.org/~jmr/pm_4126_7_Oct31 Thanks, JR jmr wrote: > Apologies Fujiwara if I am being a little slow: > > It seems for the CLI the recommended use of gettext.install() fulfills > its requirements and keeps things simple by installing the function _() > in Python’s builtin namespace so it is available to all modules: > "The class-based API of the gettext module gives you more flexibility > and greater convenience than the GNU *gettext* API. It is the > recommended way of localizing your Python applications and modules." > http://docs.python.org/library/gettext.html > > Having reviewed the code, the PyGTK recommendations > [http://faq.pygtk.org/index.py?req=show&file=faq22.002.htp] and your > comments below I see what you mean that for correct glade file > translation binddomain is required. So you are suggesting we move over > to using the GNU utils throughout to be consistent. > > I understand the need for consistency, but if different clients have > different needs then we should clearly support them and make sure all > understand how we should best do so. > > Proposal: > > CLI Apps: Client.py > > import locale > import gettext > locale.setlocale(locale.LC_ALL, '') > gettext.install("pkg", "/usr/share/locale") > > And in GUI Apps: packagemanager.py and updatemanager.py and > updatemanagernotifier.py: > > import locale > import gettext > locale.setlocale(locale.LC_ALL, '') > > for module in (gettext, gtk.glade): > module.bindtextdomain("pkg", "/usr/share/locale") > module.textdomain("pkg") > _ = gettext.gettext > > > Shared Modules: > > import gettext > > _ = gettext.gettext > > > Global strings > If you need to have global strings wrap them in a dummy fuction N_() > which python translation tools can be setup to detect and extract > strings for translation from. > http://docs.python.org/library/gettext.html#deferred-translations > > Issues > --------- > Misc.py > The problem with misc.py is that its used both by the GUI and the CLI. > So in the GUI's case _( ) will not be installed in the global namespace > and we need to explicitly use the alias _ = gettext.gettext. > > Installupdate.py: > class InstallUpdate(progress.ProgressTracker): > def __init__(self, install_list, parent, api_o, \ > : > # XXX Workaround as BE is using msg(_("message")) > # which bypasses the self._ mechanism the GUI is using > gettext.install("pkg","/usr/share/locale") > progress.ProgressTracker.__init__(self) > The above module calls into the beadm.py module which in turn uses the > libbe library that for the GUI using binddomain/textdomain will not have > _() in the global namespace. Any ideas on how to better resolve this? > Should libbe be changed to alias _ and assume that its clients will be > setting the domain appropriately? > > Summary: > So the recommendation to be consistent is use gettext.install for non > GUI clients and use the binddomain/textdoamin for Glade based GUI apps > (PM and UM). If modules are shared by both and need strings translated > then setup the _ alias in that module. > > JR > > >> John Rice-san wrote (10/31/08 10:04 AM): >> >> >>> Fujiwara - we are going to RC1 next Monday and I would really like to >>> bring this to a resolution or I will not get l10n support in for PM and >>> UM for 2008.11, nor will I get the doc support landed. >>> >>> >> Yes, probably I also think RC1 is better as I think this is a stopper. >> >> >> >>> Are you saying that we must use the GNU gettext support to get the >>> translation support needed for globals via N_ and the intl tool? >>> So if we are using it in this instance you are saying we should use it >>> consistently across all of the code base. The other issue being that if >>> we do need to swap domains we can with this api and not the other class >>> based one. >>> >>> Its one argument, but I would favor simplicity every time over a >>> possible future requirement. >>> >>> >> Yes, N_ is needed because if the strings are not marked with N_(), the >> strings are not retrieved as translatable. I think it's an usual way to >> involve >> external many community. >> I also expect the global strings are not many. >> I'm not sure what you mean in the second issue. The N_ doesn't use any >> domains and it can be classed, e.g. this.N_ >> >> I'm not sure your concern. If the common part exists, probably config.py or >> init.py could be included. >> >> >> >>> When you say "install() has a problem to disable the compatibility of C >>> gettext()." Why is this a problem for us? When would we want to disable >>> it? Can you give me a concrete example in the code please, I do not >>> understand what you are saying. >>> >>> >> I'm suggesting to use gettext.textdomain() as it should be better. >> The problem is to consist the usage in the codes. >> Otherwise, why is it a problem to follow textdomain()/bindtextdomain()? >> If we don't consist the gettext usage, I think there is no problem in this >> thread. >> >> I think I have already shown the example. It's not an IPS code. >> >> >> >>> I would vote along with Danek for using gettext.install and keeping >>> things simple in the code. If at some stage down the line we do need to >>> access the domain we can use the GNU gettext API, but until we need to >>> we should stick with gettext.install(). >>> >>> Please take the webrev I created with your various mods and modify it so >>> it only uses gettext.install(). If this is not possible please explain >>> in detail why. >>> >>> >> OK, could you explan what is your suggestion exactly? >> Do you mean to use gettext.install in client.py only? >> >> e.g. packagemanager.py already has self._ . I think removing self in all >> strings(e.g. self._("foo")) and using gettext.install() don't set domain >> correctly. >> gtk.glade doesn't have install() and using gettext()/textdomain() is the >> common way between gettext and gtk.glade. >> >> >> >>> http://cr.opensolaris.org/~jmr/pm_4126_v4_Oct30/ >>> >>> If you have a specific instance such as the use of globals that needs >>> the GNU gettext API, please add in support for this only with a comment >>> explaining why this is needed in this instance. If the code can be >>> reworked to remove this dependency on the globals all the better. >>> >>> >> I think your suggestion need to be clarified above before we work it. >> >> >> >>> If this approach is not possible as when using gettext.install "Other >>> things break", please give us a detailed breakdown of what will break >>> and why, so we can better understand what you are trying to achieve and >>> work around. >>> >>> >> Hmm.., probably we may be in loop. >> My suggestion is textdomain/bindtextdomain and yours is install. >> I explained why textdomain/bindtextdomain is better(textdomain(None)) but I >> don't see why install is better. >> >> The break point is to loose the consistency if we want to consist the usage >> of gettext in IPS. >> On the other hand, I don't think any other things break when >> textdomain/bindtextdomain is used. >> >> Do we really need to consist the codes as generally I recommend >> textdomain/bindtextdomain? >> >> Thanks, >> fujiwara >> >> >> >>> Thanks, >>> >>> JR >>> >>> >>> Danek Duvall wrote: >>> >>> >>>> On Fri, Oct 31, 2008 at 03:54:52AM +0900, Takao Fujiwara - Tokyo S/W >>>> Center wrote: >>>> >>>> >>>> >>>> >>>>> I'm not convinced you have a proper reason to use gettext.install. >>>>> Other things break - they would be just easy bugs. >>>>> >>>>> >>>>> >>>> What are those things? >>>> >>>> >>>> >>>> >>>>> gettext.install is not a class based too. >>>>> >>>>> >>>>> >>>> Yes it is. >>>> Danek >>>> >>>> >>>> >>> >>> >> _______________________________________________ >> pkg-discuss mailing list >> [email protected] >> http://mail.opensolaris.org/mailman/listinfo/pkg-discuss >> >> > > _______________________________________________ > pkg-discuss mailing list > [email protected] > http://mail.opensolaris.org/mailman/listinfo/pkg-discuss > _______________________________________________ pkg-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
