Marking translatable strings
Skip Montanaro
skip at mojam.com
Thu Sep 16 11:39:27 EDT 1999
FP> ... I came to realise that I'm more naturally tempted to stick to
FP> the 'TEXT' notation for computer strings and "TEXT" notation for
FP> human strings, the reasons being that there might be a lot of
FP> apostrophes in human text, and that traditionally, we more usually
FP> quote sentences with "TEXT", while we quote words with `TEXT' (note
FP> the grave accent at the left).
François,
While your custom is a straightforward way to partition the use of "- and
'-quoted strings, it's unfortunately not the only reasonable way to "free
up" a string prefix for use as markable text. Over time I've adopted the
convention in my own code that pretends that " and ' have the same meaning
as in C, so a fair amount of my more recent code (when I'm thinking
rationally) has single-character strings that look like 'a' and longer
strings that look like "My father owns a grocery store and he sells `T'".
To make matters worse, regular, triple-quoted and raw strings all appeared
in the language at different times, so there is a lot of existing code (does
Python have "legacy" code yet? :-) that doesn't already conform to your
convention and would have to be changed. When triple-quoted strings first
appeared I frequently used '''-quoted strings, and have been gradually
converting to """-quoted strings when I encounter python-mode problems
caused by ' embedded in '''-quoted strings (and vice versa on occasion). In
short, it's a hodge-podge at best.
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
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.
t"My father owns a grocery store and he sells `T'" would translate to
"Mon pere ..." in Quebec and other French-speaking locales.
2. Could a loadable module be defined that would put Python into "translate"
mode, thus forcing all raw strings in the code to be mapped into
translatable strings at runtime (whose semantics would then be definable
as appropriate).
3. Fredrik Lundh and many others have been working on Unicode modules and
other internationalization issues. My guess is that for longer term
discussions, the best forum for this would be the String SIG. You might
want to locate its archives on the Python web site and see what's already
been discussed on the subject.
damn-i-wish-i-spoke-french-ly y'rs...
Skip Montanaro | http://www.mojam.com/
skip at mojam.com | http://www.musi-cal.com/~skip/
847-971-7098 | Python: Programming the way Guido indented...
More information about the Python-list
mailing list