Hey Brad what the heck is Star English? A college of mine told me to use it when I started working on a project which would be translated into multiple languages.

Star English (or if your a native Français speaker maybe you call it Star Français, or Star Deutsch if your a native German speaker, basically the concept is really Star <Your Native Language>) is a technique used to test to see if you have written your application in a way that will support translating the words shown to the user into other languages.

Why do we use Star English?

We use Star English when we want to translate our application; lets say you have written an application which shows the words “Hello World” to the user but you want to release it in different parts of the world which are not all native English speakers. To gain market share in those locations having your application use their native language would be a plus. So if you release your application in France instead of “Hello World” your application when in Français mode would read “Bonjour Le Monde”.

* Note I’m just using Google Translate here so if the wording is off that’s why.

Most programming languages or tool kits have a mechanism to allow you to substitute the strings you use in your application with other strings depending on what language the user selects (which could be done automatically by asking the Operating System what language it is in). If your language/toolkit does not have a built in way of doing this its not that hard to write your own; the idea is pretty simple:

1. For each language you want to support you create a map which uses your native language string as a key and associates it with the translated version of said string.
2. When your application starts up or when the user explicitly picks a language your application loads the correct map as the one to use.
3. Anywhere you have a string which will be shown to the user you wrap it in a method which will look up the given string in the map to find the translated string to use.
4. The method returns the translated string and uses it instead of your native string you wrote in the code.

The exact syntax is different for different programming languages / tool kits but here is an example of the above done in Qt.

myLabel->setText( tr( "Hello World" ) );

In Qt the tr( QString ) method is used to do the look up; if Français is selected as the language to use the tr( QString ) method will look in a resource file (*.qm) which holds all the strings used in the application in Français and will search for the Français version of the string using Hello World as the key. If all goes well it will find the entry in the resource file and return the string “Bonjour Le Monde” setting it to the text property of the myLabel object.

So what is Star English Then?

Star English is used when things don’t go well. In the above what if we don’t have a translation for “Hello World”; The tr( QString ) method will return the key by default if it can’t find a match in the resource file. So instead of returning “Bonjour Le Monde” it will return “Hello World” which isn’t Français.

Why am I missing the translation? Well it could be because the translators missed it when they generated the resource file. It could be because I forgot to include or update the resource file. But most likely its because I forgot to use the tr( QString ) method when I wrote the code.

myLabel->setText( "Hello World" ); // oops, will always be in English

Its extremely easy to forget to wrap your string literal in the tr( QString ) method especially if your designing as you go and are continually changing the UI. And because translations are generally done at the very end that means putting off the QA for weeks or even months. In a long project with lots of UI elements you could find yourself with a release deadline fast approaching and that most of your application won’t translate.

As anyone in our business will tell you its cheaper and quicker to catch and fix bugs sooner rather then later. So instead of putting off the testing to make sure that your code is ready for translations until the very end use the Star English technique.

Star English

Because its common for translation mechanisms to default to the applications native language (in my case English) when the translation is missing when you first write your UI and select another language for which no translations exist the UI will present itself in exactly the same way as it did when you were in your native language.

So for me if I created the above dialog which shows the string “Hello World” in English then choose Français from the language selection drop down the application will look for the Français translations of “Hello World” fail to find it and default to my original English string of “Hello World”. So I nor QA have any idea if this happened because the translation file was not loaded, does not contain a translation for said string, or if I simply forgot to wrap my string literal in a translation method.

If this is net new code the answer to the issue is all three, but how do I test to make sure it wasn’t me that caused the problem and that as soon as we get translations no new code changes will be required? In other words how do I test to make sure my application will support translations without having to wait until the very end when the translations finally come in? By providing a debugging or testing translation matrix.

If I create a translation map (in Qt its a resource file with the extension *.qm) which is full of dummy translations strings I can verify that all my string literals are property wrapped.

Instead of actually translating all your strings for testing purposes (which may render the UI only readable by a portions of your team assuming not everyone can read multiple langues) simply create a test matrix which returns strings which are still legible but noticeably different from the native language (so you can tell that they were actually substituted).

For example if I have the string Hello World my testing translation matrix will contain a translation for that string which reads *Hello World*.

Notice the asterisks or stars on ether side of the English word; hence the name Star English. If your code is not written in English then use your native language. That is if you are a native Français speaker then your testing translation matrix would look like this: Bonjour Le Monde ==> *Bonjour Le Monde* and you would probably call the technique Star Français.

What this technique gives me is a way to test to make sure I wrote my application correctly to support translations and that the translation mechanism is working as expected as soon as I created the UI instead of waiting weeks or months for translations to come in. This allows me to fix bugs quickly and to catch errors in assumptions before they spread throughout the applications design.

Great but my translation mechanism only supports standard language codes (i.e. en_CA)?

Yes well that is an issue isn’t it, how do you inject a testing translation matrix if you can only use standard language codes; There is no such thing as a debug language code (debug_DEBUG).

Well the only option is to pick one and use it as a testing place holder.

The trick is not to pick one that you might actually need to use either now or in the near future.

If your application is net new and lets say is currently only in English but you know it will be translated into Français soon I would not recommend using the fr_Fr code as your Star English language matrix as you will have to remove it and replace it with the actual translation matrix. This could be an issue down the road when you go to release a new version and you’ve changed or added new UI elements and need to re-do the Star English test. Yes you could temporarily replace the fr_FR matrix with the Star English version but if you want QA to also use this technique for testing you will have to check it in and what happens if you forget to revert the change or if someone releases the wrong build?

If your translating it into Français I wouldn’t pick de_DE, it_IT, es_ES, or pt_PT as its likely you will probably support them down the road to even if its not on the immediate road map.

For me I choose to use fo_FO (which is why Star English is some times referred to as FOH-FOH). The fo_FO code is used for the language used by the people of the Faroe Islands. No disrespect to the native speakers of this fine language but according to Wikipedia they have a population of only about 50 000 people as of 2013 and in the grand scheme of things is probably not a language I’ll be asked to support for the foreseeable future (unless it is then I’ll just pick another language code which I’ll likely not be needing to support). Again no disrespect intended.

Because of the low likely hood that I will need to provide actual translations for Faroese I’ll use it to hold my Star English testing matrix. What I also like to do is leave it in place (usually only when the application is built in Debug mode) that way I don’t have to rebuild a whole new testing matrix when I make changes to the code over time.

So that is what the heck Star English is, a technique used to see if you have written your application in a way that will support translating it into other languages. If you have any questions or comments please leave them below and I’ll write back as time permits.

If your looking for a tool to help generate a Star English translation map and your using Qt I have two version here on my GitHub. One is a Python script which you can use say in an automated build system and the other is a Qt desktop application if your looking for something a bit more user friendly.

Until next time think imaginatively and design creatively