Software is something that theoretically has no roof. You could probably solve local problem, but with the same effort, you could solve a problem that can reach the whole world.
So, in this direction of thoughts may I ask you are you creating something for the whole world or something for some small part of the it? Are you embedding the labels and the descriptions of the stuff in the code without no chance of making it support more languages?
Sense my first project that had local audience and archived some reach, I have been obsessed with creating multilingual projects. The English language may be the most universal language for now because of the military and political power of United States, but that does not guaranty that every person that will use my software will know it. There are some billion Indians, some billion Chinese people, millions of Russians, Latinos, Arabs and Africans. Their native language is different and the education system maybe not so perfect and widespread. When you don’t translate, you are forcing them to learn English to be able to use your software. So, it is better for your software to support the locale languages of more countries as possible.
So much for philosophy. Lets get to business.
Most of the time as a Software Developer I have used Java Programming Language. On the Java Desktop and Server Platforms the standard way to internationalize is .properties files.
They are simple files with keys, equal sign and some values on the right with difference in the file name — only the language code. For accessing them there is ResourceBundle or Property classes.
On the iPhone platform localization is done with .strings files located under language code.lproj directories. It is like the Property files except the keys and the values must be wrapped in quotes.
On the Android Platform the standard way to Internationalize an application is using Strings.XML files. They are XML files with root resources element and <string name=”some key”>Some localized value. They are located in directories values-<some-language-code> with the same name “strings.xml”.
On the Front End side — in some web pages and in some hybrid applications written with HTML/CSS/Javascript I have used Javascript Objects as a way to store and load the translations.
These are objects with property — the keys — and values — some localized value. Witch language is selected in most of my applications is decided by some variable from the local storage or some cookie.
I have used Google Web Toolkit in the past and in some more recent projects. This framework allows you to write Front end and Backend code in Java and the compiler transforms the code to optimized Java and Javascript code. The oldest way to translate with this framework is using Constants. But using this way, the compiler packages and generates the whole application multiplited the number of translations. Are they nuts? In the more recent version there is a Dictionary API. In my recent projects I have used my own implementation of this pattern and I recomend it.
Recently I also tried Angular Framework. It works almost like the GWT Framework, except it uses the TypeScript language. They tried to make the functional Javascript functional language into TypeSafe Object Orientated Language. O God, why?
The Typescript Compiler works very similar to the GWT Compiler. Haven’t they learned from their mistakes or from the mistakes of others? There is also a way to compile the TypeScript to some locale at runtime — but this hits the performance. The way I have done internationalization with it is very similar to the above way — using a variable from the host page. This way static labels of an application can be translated and updated without the need of recompiling the whole application.
So, what message formats do you use for making your applications multilingual? If you need a tool to manage your translations you could checkout my TranslateApp.