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
