In article <887E6B64-97BA-11D8-9038-000502FDD5CC / mac.com>,
Mark Hubbart  <discord / mac.com> 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