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