In the past, I have worked with many software companies, and they all have one problem in common: Software developers like home-brewed solutions, independent from the development language they use.
The reason is this: Software developers are all brilliant in their job! And there is nothing on earth they cannot code in a few hours, especially if the code concerns exporting and importing strings. Don’t take me wrong: I have falling into this coding trap many times.
A developer may think that having all strings in one format can do the job. However, the context for the strings can be lost in one file format. He/she may produce a text file, Microsoft Office® document, database, or xml file(s). If the programmer plans in advance, he/she might even export only changed or new strings; or, even better, add this kind of information to the translatable text. But have ever considered working with translation memory. Usually, money is not the issue: even successful software companies resist spending money on a localization tool.
The funny thing is that software developers love to automate their work and hate to code the same thing twice. That is exactly the point where you can get them.
Life is like that: if you havenâ€™t done it, you can hardly imagine doing it. To be honest, if you never have localized software on your own, especially for more than one release, you hardly know anything about the complexity of the process.
No translator enjoys translating the same strings again and again. And translating text out of context is just guessing. trust me: you should not hire a professional software translator for that kind of work.
Markus article A beginnerâ€™s guide to Windows software localization provides more detailed information about these issues.
â€” Renate Reinartz