Localization in Windows Tip

Real Studio makes it very easy to create localized applications. When you use Dynamic Constants and create strings based on language the application will switch, at runtime, to the proper language. It’s pretty easy and straightforward.

In Windows, the only thing you have to do to set the language to something other than the default language is to change the Date/Time format settings in the control panel in Windows 7 to the language (and variation) of choice. This makes it very easy to test since you can have a different OS language than your apps (even if you can’t read the language).

This week, however, we had a client take our Spanish (and English) localized apps to a country in South America for installation only to find out that their default configuration is to leave everything in English. That meant the apps wouldn’t run in Spanish. I have no idea why they do this, but it certainly wasn’t what my client expected!

Major bummer and we all went into panic mode.  We went through various ideas on how to get work around the situation (and all of them ugly) until we stumbled upon the idea that the en.mo and es.mo files (located in the Resources directory next to the executable) could be swapped. So, we deleted the en.mo file and then renamed the es.mo to en.mo.

Voila! Problem solved. The client is happy, the folks on site are happy, and ultimately that makes me happy. The only minor issue is that the apps won’t run in English without swapping the files around again.

Happy coding!

10 thoughts on “Localization in Windows Tip

  1. Thanks for the tip. We actually had the opposite problem with the application I’m developing (the overseas client wanted to force the program to appear in English, because they found our foreign translations to be fairly laughable!) We’ve tried to get the app itself to handle the swapping of the .mo files, behind the scenes, based on user-selected settings- but it doesn’t work on some systems, presumably due to issues with privileges. In any case it’s great that you were able to make your customer happy.

  2. Can you explain Dynamic Constants and how you’d create strings based on language. I did a search in the Language Reference for Dynamic Constants and nothing was returned. Has anyone tried Lingua?

    Thank you.

  3. Oh, that is very common in some places. Sometimes due to international companies which install english, but users want to use native language or sometimes as computer is used by several persons and the OS uses english as a common language.
    From time to time I’m asked by people to have possibility to overwrite the OS language.
    I just filled a feature request for this: feedback case 22565.

  4. One of our application supports 14 languages and we went the way of dynamically change all controls in the Window.Open event. This allowses us to change language at run-time with have to relaunch after moving around the language resources. Furthermore, if your app is installed in Program Files it is not possible to muck around with the files unless you are an admin.
    In your case I guess you don’t change language dynamically – you swaped the files and solved the problem.

  5. @Ken Whitaker
    Sounds like a perfect training video, Ken! (Now added to my list).

    If you know how to make constants using the Constants editor then you can make Dynamic Constants. In the definition area of a constant, next to the popup dialog you can see a Dynamic checkbox.

    Then, underneath that area there’s a spot to add a different string based on Platform, and Language. The number of permutations are nearly limitless.

    If you are using the string constant in code you need do nothing more. If you are using it as part of your control (caption, text, helptag, etc) then you have to prefix it using the “#”. So if you create a Caption for your pbCancel button name kCancel then the Caption property would be #kCancel.

    Lingua is used to create localizations PER language. If you have English and use the File->Export Localizable Values it will contain the English (or the default) values and have a space for the Spanish version. Lingua then lets you export to a couple of different options and import them back in. Regardless, it has some utilities that find variables that haven’t been localized yet. When you’re done you import them back into your Real Studio project.

    Sadly, I found the process to be harder than I felt it should be. Using Arbed made it a little easier but it’s still pretty manually intensive work.

    Web Edition has no good solution at this point though one of the RS engineers said a better solution was coming.

  6. Mattias, I have ended up doing the same. There must be a separate selection of UI language in the application properties, otherwise it just doesn’t work. This issue with apps having different language than Windows may become easier in the future when in Windows one can change the language on the fly. Earlier the language was bolted in the Windows Install CD so for the companies it was easier to buy 1,000 English Windows licenses to cover all the country offices just to make sure only one installation image was then required. I think I have only used Lingua in one project that had very few captions to translate so the limitations of Lingua when compared to products like Multilizer were not that much of a problem.

  7. @Timo,
    agreed that there must be a better way to select the language to use dynamically and possibly leverage the Lingua tool and built-in stuff to get the strings in the correct place.

    As Swedish is a small language and the translation of Windows is a bit crappy in some areas, most of our users are running English Windows but would like to run most software in Swedish (if available). Also our software is used in Universities with many foreign student speaking many other languages. This mix is clearly not supported currently.

  8. Well, you can always go back to the old system–compile a Swedish .exe/.app, a Spanish .exe/.app, etc.

Comments are closed.