[I18n-sig] Re: Patch 101320: doc strings
François Pinard
pinard@iro.umontreal.ca
04 Sep 2000 18:32:59 -0400
> [François Pinard]
> > You ask the `locale' module to return you a Translations instance for
> > that module, maybe though another keyword argument stating the name of
> > the module for which you need a translator. This would only work if that
> > module previously registered its domain name, through asking the creation
> > of a Translations instance for itself (and without specifying the keyword
> > argument specifying a module, or course).
[Martin von Loewis]
> I doubt that *not* specifying the module name gives is acceptable,
> though - that locale function would need to know who its caller is.
> I feel doing that is too hacky to be accepted for the standard library.
> [...] With Barry's API, you do
> gettext.install(TEXTUAL_DOMAIN)
> which puts _ into __builtins__, so individual modules won't even bind
> _ themselves.
Hackery for hackery, I would prefer to see the function creating the
translating function to seek for the calling module, as this would really
useful.
As for `gettext.install' function, it looks awkward. This would be the
only case I know, in the Python library, where a library function hacks a
variable in the local name space. I do not doubt that it is clever, but
the cleverness alone does not make it attractive enough to make it look
acceptable. I would suggest that we go without it. No need having two
ways for doing the same thing, with the `gettext.install' being questionable.
> That is certain. I believe Python 2 will be well-equipped already,
> having a gettext module,
Yet, `gettext' is not an ideal name. We should avoid using it, and sticking
too closely to the `gettext' API.
> and xgettext and msgfmt utilities in 100% pure Python.
Barry wrote `pygettext.py', but I'm not aware of any `msgfmt' program.
The double hashing algorithm would have to be known for it to exist,
and would not be a legalistic problem then for the MO file reader.
> For a full i18n process, only a msgmerge utility and a po-mode editor
> (in Tk?) would be missing.
I'm starving to find some time for looking at Pango, but the little I read
about it, it looks especially promising as a basis for a rewritten PO mode.
--
François Pinard http://www.iro.umontreal.ca/~pinard