So I have a bit experience in this field.
When I have worked with developers, I have heard many excuses for either not doing internationalization (roughly, the process of making a program translatable) at all or for only providing incomplete support.
I will present you a list of those lame excuses and an explanation of why I think those excuses are so lame. If you have any used of those excuses, read on.
List of lame excuses for poor or no internationalization:
- “We have way too many strings.”
- “Nobody can ever translate this.”
- “Our strings change very often.”
- “This particular string does not need to be translated.”
- “Credits don't need to be translated.”
- “Names do not need to be translated.”
- “I don't know how to this particular string can possibly be translated.”
- “We don't accept your translation in XYZ because it is not a language.”
“We have way too many strings.” / “Nobody can ever translate this.”
This excuse often comes up when there is no support for translation yet or it is incomplete and a key part of the program is not yet available for translation.
This is wrong on so many levels.
First, remember, as a developer, you don't need to do the translations all by yourself, and, in fact, you probably can't. That's what translators are for.
Second: You never know when a horde of translators shows up and boost translation.
Third: It is not you to decide how much strings are “too many”. If you are really concerned, you may talk to people who are willing to translate.
Fourth: Translations may take their time, just as your software project. If you don't have a hard deadline, then translation can be seen as a long-term goal which does not need to be met instantly. But this is no reason for avoiding support altogether.
Granted, some software projects have a scarily high number of strings. But that shouldn't stop people from trying. Humans have been able to translate entire books and movies, so some strings in a software should be doable as well.
If you decide to add internationalization, your task as a developer is to make the entry barrier for translators as low as possible, which may attract more translators.
“Our strings change very often.”
This is another excuse for not providing internationalization at all. But this is also flawed: The fact that your software is still in English only allows you to mess with the strings as often as you like. It makes sense for you to not bother about
But if you add internationalization, you may want to change your habits.
But even if you can't or don't want to change your habits, the excuse is still not neccessarily a good one.
If you'd use GNU gettext or Qt's translation system, then it is not that a big deal even if strings change often. Gettext still saves old versions of strings, so from a translator view, they see old versions which they can reuse, so they only need to do some adjustments and not neccessarily write the entire translation from scrath. There are also other tools with this feature. Check out the features of your toolchain.
Another way to overcome rapidly-changing strings is to make sure all strings have a reasonable length (about 1 paragraph), so a minor change to a string has not a major impact on the whole. (See also: https://www.gnu.org/software/gettext/ma ... ng-Strings). Extremely long strings (let's say > 1000 words) need to be broken up into multiple strings for sure.
You may also consider doing string freezes, a period of time before release where no strings are added or changed so translators can translate without fear.
In general, listen and talk to the translators and work out what might be best for the project.
“This particular string does not need to be translated.”
It depends. I'd say in 95% of cases it is wrong.
There is a very simple rule I'd follow: If the string is exposed to the user interface, then it clearly must be translated, unless it is an unchangable string like a file name (see below). Strings which are only used internally and are never seen by the user do of course not need to be translated.
I have heard many reasons for not translating a particular string:
- Too short
- Too long
- Only contain punctation characters
- Too much work for translators (see above)
Those and similar reasons are all invalid, at the end of the day the user ends up seeing an English (untranslated) string in a supposedly localized application, and as such will be cryptic for those who not speak English.
So: Normally, all visible strings must be translated, no excuses. I hope it should be clear to everyone that it is generally a bad idea for intentionally leaving out parts of the program for translation.
“Credits don't need to be translated.”
This excuse seems to be fairly common, I have no idea why. For me, it does not make any sense whatsoever. The credits are a part of the program as everything else, so they need to be translated.
“Names do not need to be translated.”
This probably is based on the assumption that a name is just a string which can be dumped as-is into the text, no matter the language. But this assumption is wrong, let me explain why:
First, names can be handled very differently in different languages.
There are languages where names are written differently depending on the grammatical case. Always writing the name as-is would be ungrammatical. There are languages which do not use the Latin script (surprise!). Some languages make use of transliteration in this case, and it would be unusual to use Latin characters.
The only names which you don't need to make translatable (and shouldn't) are unchangable strings (see below) like file names.
Long story short, make names translatable and let translators decide what to do. They probably know better. You may want to add a translator comment (if your translation system supports this) for complex of “difficult” names, explaining things like pronounciation, historical background (if it is important), etc.
Here is some interesting insight on names:
https://www.gnu.org/software/gettext/ma ... html#Names
“I don't know how to this particular string can possibly be translated.”
(or a number of strings, of course)
That's fine, but no reason to either dropping internationalization at all or to not mark a particular string for translation. Generally, let the translators figure it out.
If you think the string itself is flawed, confusing or poor in its English form, then consider rewriting it, that way you improve text quality of both English and (indirectly) other languages.
But even if some strings are flawed, that's still better than having no internationalization at all. Either fix it immediately or but it on your bug list to fix it later.
Unless the string is an unchangable string (see below) or not exposed to the user, you should probably mark the string for translation anyway.
If you are really baffled by the string and can't figure out a better worded alternative, you may also start an open discussion with translators to work out how to fix this.
“We don't accept your translation in XYZ because it is not a language.”
(or “(…) because it is not a real language.”, which is not much better)
This is actually related localization, not internationalization, and I heard this crazy excuse once only, but it was too crazy for me not to include.
In that particular case, someone translated a software into Esperanto which is a constructed language. But the translation was intentionally not included into the software because the developers thought Esperanto is not a language.
Of course constructed languages like Esperanto are languages, they are, perfectly suited for communication between humans, as a quick lookup on Wikipedia would reveal.
The only thing which should matter to you is: Is this a human langauge, i.e. can it be used by humans for communication? If yes, then you probably should include it.
Unchangable strings: An unchangable string is a string which can only be used as-is. Only the exact string of characters can be used, any changes to it will break it, so it must be copied perfectly, like a code. Usually this is for technical reasons. Examples: file names, identifiers, passphrases, IP adresses, URLs. Counter-example: Names of humans
Developers should try to keep the number of unchangable strings exposed to the user interface at a minimum. If it is possible for exposing an alternative, maybe more language-friendly, represantation of such an unchangable string, then go for it. For example, instead of cryptic identifiers for maps, show the “real” map name which can also be translated.
Many lame excuses probably come from the fact that developers have a unfamiliarity with languages in general. They make assumptions based on the languages they know and try to apply them to all languages. Most fallacies can be overcome by accepting that you don't know all languages and you better make fewer, not more assumptions about them. Some other excuses seem to come from the fact that translations are only seen as a “bonus”, so incomplete translations are seen as no big deal. I have explained above why this is flawed.
In hope for better internationalization in software, I have a few guidelines to follow:
- Follow the hints for preparing strings in the GNU gettext manual, they are important to know even if you don't use Gettext
- Read the manual of the translation system you're using, you may miss out on key features otherwise
- Make all strings exposed to the UI translatable, unless they are unchangable strings
- Don't be afraid of a mountain of strings
- Be prepared to change your habits if you add internationalization
- Listen to your translators and work with them
Feel free to add your comments, questions, etc. Maybe you have heard a lame excuse I have not included, I would be glad to hear about it.