Marking translatable strings

[Andy Robinson]

François Pinard <pinard at iro.umontreal.ca> wrote:

>Hello, people.
>
>So, I want the big picture right now.  That is: a technique for marking
>strings for automatic extraction and building of PO files, and a technique
>for using PO files from within Python scripts.  I foresee that Python
>introduces an usual difficulty in that the textual domain for translations
>may vary quite unexpectedly, when the control dynamically flies between
>independent packages under different textual domains.

Big picture:  are you looking for run-time translation, or
'build-time'?  i.e. should a Python application be able to switch
languages in mid-run when a user hits a menu item?  The latter can
actually be easier - each string needs to be replaced with a lookup
into a mapping from  (language, message_id) -> local message, and it
is really quick to test.

Also do you want an automatic and theoretically perfect tool to
understand every context in which quotes occur and do the right thing,
or a practical one to reduce the cost of internationalizing apps by
90%.

I made the mistake of hard-coding messages into a Delphi app I later
had to painstakingly internationalise.  I considered doing something
semi-automatic so I could use the English messages as the key, but
then hit a situation where a simple English message was used twice in
two different contexts.  Now, I have a function 'tr' - short for
translate - and an explicit constant, and do stuff like 
   ShowMessage(tr(USER_FORGOT_THE_FLOPPY));
But this involves adding USER_FORGOT_THE_FLOPPY to a separate file
every time.  

In Python, I'd be tempted to have a special tag to use at the
beginning of the string I wanted internationalized, say
"@@@USER_FORGOT_THE_FLOPPY".  Then I'd write a script to walk through
the project finding these, and on each occurrence 
(a) replace it with a function to do a run-time lookup into a
constants database, or a constant in a module, and 
(b) add the string to my database or the source of my constants
module.   We end up with a database in no particular language e.g.
{ 
...
("LINGO", "USER_FORGOT_THE_FLOPPY") : "USER_FORGOT_THE_FLOPPY"
...
}
Of course someone else needs to sit down later and add entries for all
the languages you wish to support (including your own native one), but
it does not have to be the programmer.  And your app can at least run
in development at each stage before running the database-builder
script.

Tagging the strings which really are messages and using 'constants'
seems a lot safer than messing with the language.

Come to think of it, this could be quite a useful Python package - we
could kick it off with a few dozen common error messages in several
languages to get people going!

Python-parsing-Python-beats-Delphi-parsing-Delphi'ly yours,

Andy Robinson