[I18n-sig] Re: Patch 101320: doc strings
Martin von Loewis
loewis@informatik.hu-berlin.de
Mon, 4 Sep 2000 19:32:31 +0200 (MET DST)
> > 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