[I18n-sig] Re: Patch 101320: doc strings

[François Pinard]

> [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