[Python-Dev] Re: PEP 292, Simpler String Substitutions

[Barry A. Warsaw]

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

    FP> This is why the responsibilities between maintainers and
    FP> programmers ought to be well split.  If the maintainer feels
    FP> responsible for the work that is induced on the translation
    FP> teams by string changes, comfort is lost.  The maintainer
    FP> should do its work in all freedom, and the problem of later
    FP> reflecting tiny editorial changes into PO `msgstr' fully
    FP> pertains to translators, with the possible help of automatic
    FP> tools.  Translators should be prepared to such changes.  If
    FP> the split of responsibilities is not fully understood and
    FP> accepted, internationalisation becomes much heavier, in
    FP> practice, than it has to be.

Unfortunately, sometimes one person has to wear both hats and then we
see the tension between the roles.

    >> I18n'ing a program means you have to worry about a lot more
    >> things.  [...]

    FP> Internationalisation should not add a significant burden on
    FP> the programmer.  I mean, if there is something cumbersome in
    FP> the internationalisation of a string, then there is something
    FP> cumbersome in that string outside any internationalisation
    FP> context.

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.
Little issues crop up all the time, like the fact that a message might
have the same English phrase but need to be distinguished for proper
translation in some other languages (gettext vs. catgets), or that the
translation is slightly different depending on where the message is
output (email, web, console), or dealing with localized formatting of
numbers, dates, and other values.  It's just stuff you have to keep in
mind and deal with, but it's not insurmountable.

I think the current Python tools for i18n'ing are pretty good, and the
bright side is that I'd still rather be developing an i18n'd program
in Python than in just about any other language.  One area that I
think we could do better in is in support of localizing dates,
currency, etc.  Here, Stephan Richter is laying some groundwork in the
Zope3 I18n project, possibly integrating IBM's ICU library into Python.=


    http://www-124.ibm.com/icu/

-Barry