Localization in Real Studio

We have clients all over the world and surprisingly most of them want their apps in English. It’s been kind of an oddity that up until a few months ago we have not had to localize an application. While it’s not hard, there are some things that are just harder than it should be.

Real Studio has some of the tools in place to make the localization process relatively easy with Dynamic Constants. Dynamic Constants let you localize strings per platform and per language. This is handy, for example, with platform differences such as Mac OS X calling it Preferences while Windows apps like to call it Options. Same with File->Quit versus File->Exit menu commands on Mac and Windows respectively.

Once you’ve created the dynamic constant strings you can then export a single Language to Lingua that the linguists can then search for missing strings and provide a translation. Lingua is only a marginally useful utility. Its biggest drawback, in my opinion, is that it only handles one language at a time. It would be way more useful if I could export selected languages from my project and have my translators be able to work on all of them.

In my most recent project I really only had to worry about Spanish so this wasn’t a concern but I could see this being an issue in the future. Of course, this feature might be useful in certain circumstances as I might be sending the Lingua files to multiple people for only the languages they handle. Either way, I only have one option now and it would be nice to have the option.

One of the things that’s missing from Real Studio is the ability to search for missing Dynamic Strings for a particular language. The only way to do this is to check each dynamic constant to see if it has a translation or run the app in the language in question and test, test, test and test some more.

If you’re not disciplined when you start your project and make all strings constants you have to search for strings after the fact. This is a royal pain – especially in large projects. In the project in question I had 30 windows, 86 classes, 28 modules and 30,000+ lines of code. And I had to do this in 2 additional sister projects (the UI was similar but each had slightly different functionality). The thought of searching all that code (3 times no less) didn’t make me happy. There had to be a way of making this easier.

The utility that I ended up using was, in fact, quite useful. Arbed http://www.tempel.org/Arbed/Arbedfrom long time Real Studio developer Thomas Tempelmann, makes this process relatively easy. It will scan your xml or binary project files searching out all strings. You then have the option of putting these strings in a global modules or making the constants local to the object. Furthermore, if you tell it to group the constants it will use the same constant for multiple instances of the same string. Be warned however as some words may actually mean different things in different contexts so you might have to break them out later.

Arbed does much more than just dynamic string creation and I highly recommend taking a look at if you are a Real Studio developer. It has a number of features that no other utility has.

Back to the Real Studio IDE. The constants editor is okay for dynamic strings but it’s not exceptionally smooth and like many of the editors in the IDE it’s acts stupidly at times causing me to pause for a moment until it will recognize a mouse click. Ideally, when it comes to dynamic strings in controls, I’d like to somehow have the creation of the dynamic string in the properties list without having to break concentration to go to a separate editor. I also find myself doing a lot of unnecessary copy/pastes.

It would be handy to be able to tell the IDE to make a string property a dynamic constant (using some standardized rules) so make it even easier. Perhaps when Real Studio releases their new IDE interface with its redesigned properties list (it’s no longer a listbox but dynamically generated controls from what little I’ve seen of the UI so far) they’ll somehow make this a reality in a future version.

I’m NOT a normal user of Real Studio. I understand that. This pain isn’t something most users are experiencing. But, the localization process could be simpler and making it simpler makes Real Studio even that much more powerful. Let’s hope they can do something in future versions of Real Studio.

What pains have you experienced localizing a project in Real Studio?

6 thoughts on “Localization in Real Studio

  1. Hi Bob,

    just one tip – leave your constants local – I originally put them all into a module called Localization, but when I reused a window in another app of course all the constants were missing. So now they go with whatever window, containerControl etc uses them, and I rather have a constant twice or more often than impacting the reusability of my windows.

  2. My biggest wish is to have the dynamic constants working for Web Edition.
    Second, it would be nice to see them in introspection. Like being able to query all constants in a projects and have code to check if all of them are localized.

  3. Christian Schmitz :

    My biggest wish is to have the dynamic constants working for Web Edition.

    Amen brother. It’s so jacked up at this point that it’s not even worth trying. The official RS ‘solution’ isn’t workable.

  4. Markus Winter :

    Hi Bob,

    just one tip – leave your constants local – I originally put them all into a module called Localization, but when I reused a window in another app of course all the constants were missing. So now they go with whatever window, containerControl etc uses them, and I rather have a constant twice or more often than impacting the reusability of my windows.

    I fight with this one. It’s convenient to have them local, but then the localizers complain about having the same string multiple times. But you bring up a valid point. It might be better to have them local if you tend to reuse your windows.

  5. @Bob Keeney
    It is not just about portability – it is also that the module becomes very large and unwieldy quickly. I rarely have more than 40 constants in a window, but the module had over 700 so became a pain to use (and you do not want to prune that in case you delete a window – so a lot of dead constants start to pile up).

    One convention I follow: constants for object names have a prefix like k_PB_ (for pushbuttons) while constants used in code just have k_ – this way I quickly find the one I’m looking for.

    > but then the localizers complain about having the same string multiple times
    They have heard of copy/paste??? ;-P

Comments are closed.