Thanks to J for the backout of the webrev. I have taken the latest set of changes and created a new webrev and done a smoke test against PM, UM and CLI.
The issue remaining is the as Danek points out is "the inconsistency of the way the i18n is handled". We need to have clear instruction as to what needs to be added to the applications to have l10n support going forward so as we add new components we are not left wondering what needs to be done. http://cr.opensolaris.org/~jmr/pm_4126_v4_Oct30/ Fujiwara could you please clarify the points below: Thanks, JR Summarizing briefly from the email thread (omissions are mine alone): 1. By default we would expect to just use gettext.install("domain") to support l10n in our python apps: Class Based API: http://www.python.org/doc/2.2.1/lib/node201.html#tex2html37 Danek: gettext.install("domain") instantiates a GNUTranslations object bound to "domain", and installs its .gettext() method into the __builtins__ dict as "_( )". Thus, once you call gettext.install(domain) in the front-end program, _("message") will translate "message" in domain "domain" via the .mo file that was found when the GNUTranslations object was instantiated. 2. Under exactly what circumstances (please provide use cases in the current code) do we need to use the alternative GNU gettext API: GNU gettext API: http://www.python.org/doc/2.2.1/lib/node200.html#l2h-1818 Danek: bindtextdomain(), textdomain(), and gettext() functions use a completely different mechanism to maintain the notion of the current domain. They use the global variable _current_domain, and instantiate a GNUTranslations object for that domain on every message lookup. It seems very wasteful, and I don't see why it's there. You point out that you need to use this API if you want to retrieve the current domain, but I see nowhere in the current code base where this is done. > > current_domain = textdomain (None) > > open (something + current_domain + ".txt", "r") > > print dgettext (current_domain + "-lib", "msgid") 3. Can you explain the l10n tools requirements so we can understand why things like N_() are needed. Are the strings being setup before main() is called and so before gettext.install() has a chance to set things up correctly? Please give specific examples from the code why you need to alias gettext.gettext to _ as opposed to using the builtin, again so we can understand the requirements more clearly. Additional changes applied from recent emails: -------------------------------------------------------------- line 394 - if uom != "EB" and bytes >= limit: + if uom != _("EB") and bytes >= limit: +++ b/src/client.py - gettext.domain("pkg") + gettext.textdomain("pkg") Confirmed that the following had been added to 638: ---------------------------------------------------------------------- +++ pkg/src/client.py 2008-10-29 02:05:40.317422169 +0900 @@ -85,6 +85,7 @@ from pkg.client.retrieve import Datastre CLIENT_API_VERSION = 2 PKG_CLIENT_NAME = "pkg" +_ = gettext.gettext def error(text): """Emit an error message prefixed by the command name """ +++ pkg/src/updatemanager.py 2008-10-29 21:04:37.794975099 +0900 @@ -211,11 +212,10 @@ class Updatemanager: # packagemanager.glade file, so we wanta single domain for strings from # updatemanager.glade and packagemanager.glade for module in (gettext, gtk.glade): - module.bindtextdomain("packagemanager", self.application_dir + \ + module.bindtextdomain("pkg", self.application_dir + "/usr/share/locale") - module.textdomain("packagemanager") + module.textdomain("pkg") # Required for pkg strings used in pkg API - gettext.install("pkg","/usr/lib/locale") self._ = gettext.gettext # Duplicate ListStore setup in get_updates_to_list() Takao Fujiwara - Tokyo S/W Center wrote: > Danek Duvall-san wrote (10/30/08 01:03 AM): > >> Huh. This still doesn't resolve my concerns about the inconsistency of the >> way the i18n is handled, and there's a bug in misc.py that I finally >> noticed. I didn't have a chance to review this new code before you pushed >> it, and most of my concerns which I've raised several times over the past >> couple of days with Fujiwara hadn't been addressed yet, though I think we >> were making progress towards resolution. >> >> FWIW, the bug is that the unit names in the table of units are all i18ned, >> but the comparison on line 394 is against a non-i18ned string, which will >> fail if the unit names are, in fact localized. This can't have been >> tested. In very large cases (> 2^70), bytes_to_str() will return None, >> causing a stack trace. >> >> It probably should be uom on line 401 that gets i18ned. >> > > OK, thanks for this point. > uom != "EB" is a problem. I noticed it with this mail just now however I'm > not sure you raised it before. > > Yes, either your suggestion(_("EB")) or adding N_() can resolve this. Let's > fix it. > > line 394 > - if uom != "EB" and bytes >= limit: > + if uom != _("EB") and bytes >= limit: > > Do you have other issues? > > fujiwara > > >> 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
