From: Gawnsoft Date: 2004-04-27T20:39:13+09:00 Subject: Re: Approaches to localization? On 27 Apr 2004 01:14:21 GMT, ptkwt@aracnet.com (Phil Tomson) wrote (more or less): >In article <887E6B64-97BA-11D8-9038-000502FDD5CC@mac.com>, >Mark Hubbart 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? Cheers, Euan Gawnsoft: http://www.gawnsoft.co.sr Symbian/Epoc wiki: http://html.dnsalias.net:1122 Smalltalk links (harvested from comp.lang.smalltalk) http://html.dnsalias.net/gawnsoft/smalltalk