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

[Barry A. Warsaw]

Just to follow up on some ideas:

    FP> If it was systematic that `_' was assigned to, we could try to
    FP> retrieve the function stored in the `_' global variable of
    FP> `httplib', and then use it to translate any docstring from
    FP> httplib.  However, it would be nicer if the constraint of
    FP> using `_' for the translating function did not exist, and if
    FP> it was rather completely left at the discretion of the
    FP> programmer.  If we use `_' systematically in documentation
    FP> examples we produce, it is likely to become the popular
    FP> choice, but let's avoid mandating it.

Here's another suggestion.  I'm not sure I like it but here goes
anyway.

Say we had an import hook that isn't installed by default (for Python
environments that don't care at all about i18n).  If this import hook
is installed, though, it interposes a little extra functionality
whenever a module is imported for the first time.

What this hook does is import the module, then look to see if the
module has a '__domain__' attribute set.  If it does, then the
importer uses that textual domain for that module's translations,
locating the .mo file using the "standard lookup algorithm".

If __domain__ is not set, then if the module's name can be determined,
the import hook tries to use that textual domain.

If that can't be found, it falls back on the textual domain "python".

So we can generate a big .po file containing the entirety of the core
libraries, but we can override individual modules as needed.  This
would also work with 3rd party libraries, since the same import hook
would run when they are imported.

Caveats:

- Using the module's name as the textual domain may create conflicts.
  E.g. mypackage.foo.datetime and yourpackage.bar.datetime.  One
  possible resolution is to first try the fully qualified name with
  period->underscore substitutions.  If that isn't found, fallback to
  the rightmost module name.

- This is a lot of disk statting to do all these searches.  And
  because the import hook will be written in Python, it means that
  i18n'd applications will all import much more slowly.

- I think it's still tricky to get modules to play nice, especially if
  you want to handle the situation where a Python user doesn't know
  about or care about i18n.  How would you define a module's _()
  function to work in both cases?  Would the import hook poke a new
  _() function into the module namespace, or perhaps delete one it
  finds there, assuming the one in builtins will still be there?

Maybe it's a dumb idea anyway.

-Barry