Re: Approaches to localization?

On Apr 27, 2004, at 4:39 AM, Gawnsoft wrote:

> On 27 Apr 2004 01:14:21 GMT, [e-mail] (Phil Tomson) wrote
> (more or less):
>
>> In article <[e-mail]>,
>> Mark Hubbart  <[e-mail]> wrote:
>>>
>>> On Apr 26, 2004, at 11:09 AM, Phil Tomson wrote:
>>>
>>>> I'm developing a GUI app using Ruby and FLTK.  One of the 
>>>> requirements
>>>> that's come up lately is that this app should be 'localizable'.  I'm
>>>> trying
>>>> to figure out approaches for doing this as I design the app.
>>>>
>>>> The approach I'm thinking of is to have some seperate file, maybe in
>>>> XML,
>>>> that would contain all of the text which is used for things like 
>>>> button
>>>> labels, output messages, etc.  Then to support different languages 
>>>> all
>>>> the
>>>> customer would have to do is include a different language specific
>>>> file.
>>>>
>>>> These files might look something like:
>>>>
>>>> [...]
>>>>
>>>> So, if they wanted to make a Japanese version of the app, they would
>>>> replace each of the strings above with their Japanese counterparts.
>>>> While it seems a bit heavy, I'm thinking an XML approach would be 
>>>> good
>>>> for
>>>> a couple of reasons:
>>>> 1) this localization will probably be taking place long after I'm 
>>>> gone
>>>> (this is a contract job) and XML is widely known and understood.
>>>> 2) it's easy to extract data from it using REXML
>>>>
>>>>
>>>> Does this seem like a reasonable approach?
>>>>
>>>> Has anyone used alternate approaches?
>>>
>>> You might look at Apple/NextStep's approach to localization. 
>>> (probably
>>> others use it too) Basically, there's a file that maps english text 
>>> to
>>> the translated text. Then, anywhere in the program where a particular
>>> english string is used, it checks for a translation to the 
>>> appropriate
>>> language.
>>>
>>> So to do this in ruby, you might have a pig-latin translation file,
>>> using yaml:
>>>
>>> ---
>>> Enter text here: Enterway exttay erehay
>>> Type "yes" to continue: Ypetay "yes" otay ontinuecay
>>>
>>> Then write a small class:
>>>
>>>   class Localization
>>>     def initialize(filename)
>>>       # load yaml data from file to a hash
>>>       # stored in @translations
>>>     end
>>>     def [](text)
>>>       @translations[text] || text
>>>     end
>>>   end
>>>
>>> localization files are automatically generated for english, that
>>> include all the string literals from the source code. For the english
>>> files, they just map each string to itself. But then you can easily
>>> hand the file over for translation, and add the new one in.
>>
>> I thought a bit more about this approach, it I think I see a flaw:
>> If you change the text in your program, you need to also change the 
>> text
>> in your translation file.  For example:
>>
>> #your translation.yaml file for English:
>> "Login Failed.  Please check your proxy settings" : "Login Failed.
>> Please check your proxy settings"
>>
>> I'm assuming you use the Localization class like so:
>>
>>  #Your Ruby code:
>>  loc = Localization.new("translation.yaml")
>>  #...
>>  puts loc["Login Failed.  Please check your proxy settings."]
>>
>>
>>
>> Now let's say you want to make the message more detailed so you change
>> your Ruby code like so:
>>
>>  puts loc["Login Failed.  You could be behind a firewall.  If so,
>>  please check your Proxy settings"]
>>
>>
>> For the case of English, it's not a problem, you'll see the new 
>> message.
>> However, when you give the translation file to your translator to
>> translate, they will translate the old message and when your program 
>> is
>> run it will display the English text instead of the translated
>> text because the hash doesn't contain the
>> key for the new message.  In order to prevent this you must 
>> meticulously
>> keep your translation.yaml file in sync with your Ruby code.  This 
>> seems
>> to me to be a violation of the Do Not Repeat Yourself rule.
>>
>> Phil
>
> So you need a Ruby applet that searches the source files for all loc
> calls and checks if there's an entry for its argument -  as part of
> your test suite?

good point. I was trying to think of how to strip all the strings out 
of the source code; all that would need to be found are the translation 
calls. So if the translation calls are unique, it shouldn't be too 
difficult.

--Mark