jmr-san wrote (10/30/08 09:23 PM):
> 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 for compiling the issues and putting the updated patch.
>
> 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.
Since the consistent usage of gettext is preferred, I'm pointing out it,
gettext.install() doesn't give texdomain(None).
I don't say IPS only but also as the general suggestion. Yes, the current code
doesn't get the domain name in IPS but the point is, which we use
install() vs textdomain(). install() has a problem to disable the compatibility
of C gettext().
I don't think the implementation of textdomain() is very wasteful because I
don't see any performance problems here and it's a same style with C.
> > > 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.
What is needed with intltool:
- In Python, if _ or N_ is tagged, the strings are retrieved.
- We need the file extension of .py. If the file name has no extension, the
file is not recognized.
N_ is needed when gettext is not initialized and the function _ is not defined.
e.g.
import gettext
global_array = [
N_("a"),
N_("b"),
N_("c"),
None
]
def main():
gettext.bindtextdomain ("foo", "/usr/share/locale")
gettext.textdomain ("foo")
_ = gettext.gettext
for a in global_array:
print _(a)
if __name__ == '__main__': main ()
>
>
>
> 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")
Sorry, it was my typo and failure.
>
>
> 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()
Yes, the backslash is removed to follow the suggestion.
fujiwara
>
>
>
> 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
