Marking translatable strings

[François Pinard]

[Skip Montanaro]

[About marking translation strings for which immediate translation is
delayed.]

>     FP> Another possibility is to use ''"TEXT" instead of "TEXT", making an
>     FP> overhead of two characters: that is the compile time concatenation
>     FP> of '' with "TEXT".  This combination is quite unlikely to me, and a
>     FP> bit uglier.

> Unfortunately, it is already valid usage.  Python concatenates adjacent
> strings just like ANSI C does.  While it's ugly, I wouldn't count on it not
> appearing somewhere

This is exactly _because_ it is already valid usage that I'm proposing it.
It does not look to me that such a writing (of ''"TEXT", with no intervening
space or comment, is frequent enough to really be seen as an impediment.

> As long as we're proposing things, here are some ideas.  

> 1. It seems to me that the natural extension of the current string syntax is
>    to allow a prefix 't' in front of strings intended to be translated.

It could be a good idea, yet it represents a change in the language, which I
think could easily be avoided.

> 2. Could a loadable module be defined that would put Python into "translate"
>    mode, thus forcing all string literals in the code to be mapped into
>    translatable strings at runtime (whose semantics would then be definable
>    as appropriate).

I wonder if translating strings while importing a module would not slow
down importing, especially when the module only needs to translate one or
two strings, if ever.

> 3. [...] the best forum for this would be the String SIG.

If I remember well, I went through the archives, and saw only little about
these matters.  There were a lot of discussions about regexps, however! :-)

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