Tuesday, June 9, 2009

You need what language supported ?

Something that every developer seems to hope they don't have to deal with.

But I'd say you should want to deal with localization, because if you're localizing your application into many languages then it's also very likely that your application is widely used and hopefully really successful.

REALbasic makes doing most localizing very easy. Just use dynamic string constants and that will take care of the bulk of your needs.

If you plan ahead and use dynamic constants for captions on buttons, strings shown in message dialogs and all the other strings you show in your application you can be ready to localize into any of the languages that REALbasic supports.

But what do you do if after you've created your application you need to localize it into a new language ? And you don't need to do anything else but localize it? You don't need to recompile the application to do this.

You use Lingua.
First you need to export the localizable strings from your application (under File > Export Localizable Values )
Specify what language localization you are creating as the target language.
Import this .rbl file into Lingua and make whatever changes you need using Lingua to add in the new values for this localization.
Then, when all your changes are done, choose "Export to Application" under File > Export.
This will add a new localized file to your application that is set up for the new language.
This works for OS X, Windows and Linux.

That's it. All done.

Note that your application MUST be set up with dynamic constants BEFORE you do this. You cannot change an already compiled application that does not use dynamic constants into one that does by this process.

On OS X there's an alternate way that does not require Lingua and can actually be done by anyone at any time.  You can open the application package and navigate to the Resources directory inside the package. Inside will be any number of directories named with a .lproj extension. There you will see a file called Localizable.strings which holds all the strings that can be localized.

If you need to create a new localization you can use TextEdit on OS X (see the Creating Strings Files Manually section here).  You can duplicate an existing localization (the directory named ending in .lproj) and rename it. The prefix of the directory name is the localization (en.lproj is English, fr.lproj is French, de.lproj is German, and so on)

Once you've created this you have a new localization without recompiling your application.


Eric Gibbon said...

Nice article, thanks.

I'd be interested to see a good way to implement button sizing & positioning to cope with different word lengths in different languages. Making buttons overly large to allow for other language translations seems a poor choice. The only other way I can think of right now is to specifically code different button lengths (& positions) for different languages. I would hate to do that with a select case statement, so each button would have to decide it's own length & position depending on it's caption. Is that right, or is there a better way?

Norman said...

Admittedly it does get really tricky to do the kind of UI adjustments that you need to accommodate different length of strings in different languages AND still not make you UI look odd with large blank spaces for short strings.

One thing I have seen done is creating a module to take an array of buttons and their captions, figure out the largest string, and then set all the buttons to the same widths.
Positioning could be done similarly.
But then you still have all the other controls to deal with (check boxes, editfields, etc) that may also need adjustments.

Anonymous said...

Is there a way to allow the user to select a language from within my application - rather than just have the OS do this?