[Python-Dev] Re: String substitution: compile-time versus runtime

[François Pinard]

[Paul Prescod]

> I think that what I hear you saying is that interpolation should ideally
> be done at a compile time for simple uses and at runtime for i18n.
> [...]  If "%" survives, it would be used for positional parameters,
> instead of named parameters.  [...]  I think we are making progress
> if we're coming to understand that the two different problem domains
> (simple scripts versus i18n) have different needs and that there is
> probably no one solution that fits both.

[Moore, Paul]

> The internationalisation issue is clearly important.  However, it has
> very different characteristics insofar as the template string is (of
> necessity) handled at runtime, so issues of compilation and security
> become relevant.  I'm no I18N expert, so I can't comment on details,
> but I *do* think it's worth separating out the I18N issues from the
> "simple interpolation" issues...

You know, the ultimate goal of internationalisation, for a non English
speaking user and even programmer, is to see his/her own language all over
the screen.  This means from the shell, from the system libraries, from
all applications, big or small, everything.  For what is provided by other
programmers or maintainers, this may occur sooner and later, depending on
the language, the interest of the maintainer, and the development dynamic.
The far-reaching hope is that it will eventually occur.

For what a user/programmer writes little things himself/herself, and this
is where Python pops up, there are two ways.  The simplest is to write all
strings in native language.  The other way, meant to help exchange with
various friends or get feedback from a wider community, is to do things
properly, and internationalise even small scripts from the start.  It is
easy to develop such an attitude, yet currently, examples do not abound.

I surely had it for a few languages, despite it was rather demanding on me,
at the time `gettext' was not yet available -- and in fact, my works were
used to benchmark various ideas before `gettext' was first written.

The mantra I repeated all along had two key points:

1) internationalisation will only be successful if designed to be unobtrusive,
   otherwise average maintainers and implementors will resist it.

2) programmer duties and translation duties are to be kept separate, so these
   activities could be done asynchronously from one another.[1]

I really, really think that with enough and proper care, Python could be set
so internationalisation of Python scripts is just unobtrusive routine.  There
should not be one way to write Python when one does not internationalise,
and another different way to use it when one internationalises.  The full
power and facilities of Python should be available at all times, unrelated
to internationalisation intents.  Non-English people should not have to pay a
penalty, or if they do, the penalty should be minimised As Much As Possible.

Our BDFL, Guido, should favour internationalisation as a principle in the
evolution for the language, that is, more than a random negligible feature.
I sincerely hope he will do.  For many people, internationalisation issues
cannot be separated out that simply, or otherwise dismissed.  We should
rather learn to collaborate at properly addressing and solving them at
each evolutionary step, so Python really remains a language for everybody.

--------------------
[1] In practice, we've met those two goals only partly.  For C programs,
the character overhead per localised string is low -- the three characters
"_()", while exceptionally _not_ obeying the GNU standard about a space
before the opening parenthesis.  The glue code is still small -- yet not
as small as I would have wanted.  I wrote the Emacs PO mode so marking
strings in a C project can be done rather quickly by maintainers, and so
translators can do their job alone.  These are on the positive side.

But I think we failed at the level of release engineering, as the combined
complexity of Automake, Autoconf, Libtool and Gettext installation scripts
is merely frightening, and very discouraging for the casual user.  There were
reasons behind "releng" choices, but they would make a long story. :-) Also,
people in the development allowed more fundamental unneeded complexities,
and which had to sad effect of anchoring the original plans to the point
of being stuck.  On the other hand, people not understanding where we were
aiming, are happily unaware of what we are missing.  (Maintainers may become
incredibly stubborn, when having erections. :-) Eh, that's life...  Sigh!

Python can do better on _all_ fronts.  By the way, I hope that `distutils'
can be adapted to address internationalisation-related release engineering
difficulties, so these merely vanish in practice for Python lovers.
We could also have other standard helper tools for non-installed scripts.

-- 
François Pinard   http://www.iro.umontreal.ca/~pinard