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

[Martin von Loewis]

> > That brings us back to square one: Should we split the Python library
> > into different textual domains?
>=20
> I miss the logic of sliding over the snake, down to square one.  I percei=
ve
> the issues as rather orthogonal.  How are they connected?

[me, paraphrasing]

Me:    I propose a single domain for docstrings, 'pylib'.
Barry: This is too large, split it up.
Me:    Then how do you access the individual strings?
Barry: Use the module name.
Me:    This will give too many domains.
Barry: There might be some point in having a /docstring/ domain [for
       the python library]
You:   Why should we have one? All docstrings should be in the same
       domain as the module.
Me:    Then how do you access individual strings?
You:   I don't know, but maybe you can use the binding of _.
Me:    I propose a single domain for docstrings. Anybody proposing
       a different organisation?

> > 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 doc strings.
>=20
> Why should we use separate domains for doc strings?

I did not propose a *separate* domain for doc strings. I proposed that
there is one well-known domain in which the doc strings of the core
python library can be found. I don't care too much at this time
whether it contains anything else - there are no other translatable
strings in the Python sources at this point in time.

> My feeling is that we should not rely on `_'.  The variable used to hold
> the translating function should be left at the discretion of the
> user.

Well, what else do you propose?

> > - else, try to translate the doc string in the domain for Python
> >   doc strings ("pydoc"?).
>=20
> Why not just use the textual domain of a module, to translate the doc
> strings it contains?

How do I find out the textual domain of a module? How do I find out
the module of a builtin function?

> However, all modules holding translated strings should also get,
> right on initial import, a translating function out of their textual
> domain, and the mechanics producing that translating function might
> save a correspondence between the module and the textual domain for
> that module (unless we find something more straightfoward).

So you propose that there be some kind of protocol to be observed by a
module that wants to make "its" textual domain known. What is that
protocol?

I also propose a protocol: A module can announce its textual domain by
binding _. It may chose not to bind _, or it may chose not to bind it
to a catalog method. In either case, it does not follow the protocol,
so anybody using that protocol may get some kind of failure.

> > However, you also brought the point that the doc strings should use
> > the same catalog as any other strings of the Python core,
>=20
> I just checked the `To:' of your message to make sure, and indeed, you
> are writing to me :-).  No, I'm pretty sure I never said that, or else,
> if I did, I surely was extremely tired! :-) Simplicity asks that doc
> strings share the textual domain of all other strings for the same module.
> Is there a need to do otherwise?

Maybe my logic is somewhat flawed:
- Did you agree that doc strings of a module should use the same
  domain as all other strings of the module?
- Did you propose that a single package, distributed as a whole,
  should have a single textual domain?
- Do you agree that the Python core+libs is a single package?

=46rom that, I'd conclude that you are in favour of having a single
domain for the Python core+libs, which contains both doc strings
and other translatable strings of Python core+libs.

> P.S. - I slightly begin to fear that we will not have a full, clear
> consensus by the 4th of September... :-)

I've given up on having message catalogs in the Python 2.0
distribution. Since there is no point in having the catalog without
any translations, this is not so urgent. What *is* urgent is to give
the catalog to the translators.

Regards,
Martin