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

[Martin von Loewis]

> I do not imagine all the details, but I think the spirit of the
> thing is that at "import httplib" time, some function (or class
> instantiator) was called at the top level of the httplib module, to
> produce a translating function, which the httplib module soon
> assigned to the `_' variable, or something else if the programmer
> did not like `_'.  The httplib module transmitted its translation
> domain to the mechanism generating the translating function.

Ok, so if _ is bound, all is well. That brings us back to square one:

Should we split the Python library into different textual domains? If
yes, then how? *If* we decide to split that, it would be very easy to
extract doc strings of different modules into different catalogs.

Even in that case, I guess there would be some code left that did not
have its own textual domain. So there would still be the need for some
kind of "fallback" domain for the docstrings.

The proposed operation of the help function would then be that:
- if the module of the object (function, class, etc) can be
  established, and has _ bound, then translate the doc string
  in the catalog associated with _.
- else, try to translate the doc string in the domain for Python
  doc strings ("pydoc"?).

However, you also brought the point that the doc strings should use
the same catalog as any other strings of the Python core, and that
this should be a single domain (e.g. "python"). In that case, lookup
would fall-back to the "python" domain, and it would not matter
whether _ was bound in any of the modules of the standard Python
library.

Regards,
Martin