This article is about software localization and its aspects. The following aspects are shortly described in this article: why localization is needed, how it can be done and which problems you may face during localization process. It doesn’t describe any particular localization tools.
Some aspects of software localization
Hi there, I’m Alex. Today I’d like to write about software localization basing on my experience as a support person for one widely known localization tool.
Why you need multilingual software?
Today there are not so many ways to sell your software since there’s lots of software almost for everything and it depends only on user preferences which tool to use for his needs. So, to sell software it must have advantages. Here are only some of possible advantages:
- Software is free. Yeah, it’s cool. For a user. But not for you. Of course there are lots of ways how to make money from free software – ask users to donate, provide paid support etc., but all these ways can’t give you guarantee that you’ll get your money.
- Software is unique. This is really great if you’ve created outstanding software that doesn’t have counterparts. But most of such software is usually designed by scientific labs for their own internal needs, which means that it would be harder to find sphere of applied software where your tool would be unique, than to develop such software.
- Make your software intelligible for user. And one of conditions for it is to make software multilingual. You can make the most stable, quick and good looking software, but if user doesn’t understand what means names of menu items he won’t be able to use them. Of course you can make software only in one language. If you want to sell it only to those, who understand this language. But why not get some more money? It’s not to hard to add support for several langs to software, but it can significantly increase number of potential users.
There are many other ways to make your software popular (read – “get more money for it”) and it’s good if your software combine many advantages, but support of many languages is one of the most important and easiest from development side features that can help your software to get popularity.
How to make software multilingual?
There are two ways to make software multilingual:
- Write all texts in several languages at development stage. It takes much time and you have to be good linguist. Not sure that there are many people who would really want to do this.
- Use localization software. Don’t think that localization software will translate everything itself. You will still need to translate text – tool can make it easier for you but can’t do the job instead of you.
- Hire somebody to translate your software. And guess what? This somebody will use localization software and will take money for his job. From the other side – he’s professional in this sphere so most likely he will do this job better than you. And of course you can have your own translators – today many software companies have their own personnel for translation (not only localization of software).
And now we’re coming to the main part…
Aspects of software localization.
So, what you need to know about localization?
First thing – software must be localizable. This means that you must add localization support at design time. At present, almost all development platforms have special features designed to make your software localizable. This can be anything – component property, special classes, special way of storing resources, all depends on development platform, used technologies etc.
Other important thing is encoding. Yep, there are still no universal encoding that is supported by all development platforms and by all environments (operating systems etc.). Unicode is close to be such a universal solution, but still not there since not all environments and development platforms support it, even among most popular platforms. For example, VCL architecture (Delphi and C++ Builder) started to support Unicode natively only starting from version 2009. And there is still a lot of software that is being developed using older versions without native support of Unicode.
Of course you may say “Why do I need to support some universal encoding? I only need few languages that have same codepage”, and may be you’ll be right. That’s your choice. But then if someday you’ll want to add language with other codepage you won’t be happy to see some unreadable crap instead of text.
Third thing that you will need to know is mechanism of localization for chosen development platform. Whole localization process will depend on this. Will you be able to change application language at runtime or not, will you need to localize only resource file or this will be binaries or may be you’ll have to localize source code, and even which tool to choose for localization – this all depends on localization mechanism of particular platform.
Example: .NET platform version 3.x and higher has WPF technology which uses XAML to store resources in text format and BAML to store them in binary format. Problem is that BAML can be compiled from XAML only along with main assembly, i.e. it’s not possible to build localized satellite assemblies from xaml resources using 3rd-party software, only from Visual Studio – first localize xaml resources and then build satellites from VS.
And here’s another problem: from one side after localization of xaml resources user has to add all localized xaml’s to solution file (.sln) and then build assemblies. On practice this means manually adding one by one dozen of files, which is not very suitable. This could be easier if localization tool was able to update solution after writing localized files. But from other side 3rd-party software should not change original files to avoid their corruption.
As result we have to choose between two evils: to waste time on adding resources manually or localization of them from VS (not good idea) or to modify original file and if something went wrong – mess up whole project (yep, still not good idea). Of course there are tools that know some tricks how to work around such problems, but usually they are dedicated to only specific technologies.
So when you’re going to make your software multilingual, first consider which tools you will use for localization and vice versa – consider possible platform-related problems when choosing tool for localization. Read documentation and don’t be shy to google for some question or ask it on specific forums if you’re not sure if there are any possible tricky things or something like this.
Globalization comes to all spheres of our life and there are only two options: accept it and use all preferences of international community or reject and stay in your easy and comfy but still small and limited one-language-world. First way requires some efforts but gives more opportunities; second way is easier and secure. It’s up to you which way to choose. Just remember that you always can turn back to your small world, but you’ll never know how good it could be outside.
Team Lead of Support Department, Binary Studio