jmr-san wrote (10/31/08 08:13 PM): > 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 >
That's a great explanation. I vote the CLI and GUI suggestions above is reasonable at the moment. > > 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? Yes, _ = gettext.gettext can be a workaround but I think dgettext is better for the shared modules. def _(msgid): return dgettext ("pkg", msgid) def init(): bindtextdomain("pkg", "/usr/share/locale") We have implemented the similar codes in C/C++ libraries. Thanks, fujiwara > > 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
