[Python-Dev] I18n'ing a Python program (was Re: PEP 292, Simpler String Substitutions)

[Barry A. Warsaw]

>>>>> "FP" =3D=3D Fran=E7ois Pinard <pinard@iro.umontreal.ca> writes:

    >> It may not be a significant burden, once the infrastructure is
    >> in place and a rhythm is established, but it is still not
    >> non-zero.

    FP> The Mailman effort has been especially courageous, as it ought
    FP> to address many problems on which we did not accumulate much
    FP> experience yet, but which are inescapable in the long run.
    FP> For example, I guess you had to take care of translating
    FP> external HTML templates, considering some input aspects,
    FP> allowing on-the-fly language selection, and of course, looking
    FP> into more prosaic non-message "locale" concerns.

Thanks, I think it's been valuable experience -- I certainly have
learned a lot!

One of the most painful areas has in fact been the translating of HTML
templates specifically because a template file is far too coarse a
granularity.  When I want to add a new widget to a template, I can
usually figure out where to add it in say, the Spanish or French
version, but it's nearly hopeless to try to add it to the Japanese
version. :)

Here, I hope Fred, Stephan Richter, and my efforts at i18n'ing Zope3's
Page Templates will greatly improve things.  It's early going but it
feels right.  It would mean you essentially have one version of the
template but you'd mark it up to designate the translatable messages,
and I think you'd end up integrating those with your Python source
catalogs (but maybe in a different domain?).  I'm not quite sure how
that would translate to plaintext templates (e.g. for email messages).

Input aspects are something neither MM nor Zope has (yet) adequately
addressed.  What I'm thinking of here are message footers in multiple
languages or say, a job description in multiple languages.  We'll have
to address these down the road.

I've already mentioned about efforts in Zopeland for localizing
non-message issues.  On-the-fly language selection is something that I
have had to deal with in MM, and Python's class-based gettext API is
essential here, and works well.  Zope3 and MM take slightly different
u/i tacks, with Zope3 doing better browser language negotiation and MM
allowing for explicit overrides in forms.  Some combination of the two
is probably where web-based applications want to head.

now-to-make-time-to-finish-MM2.1-ly y'rs,
-Barry