Join Dennis Meyer for an in-depth discussion in this video Evaluating string context and reuse, part of Localization for Developers.
- Within many applications, certain messages may appear in a number of different locations. This might be a labeled button, an error message, or it might be a helpful reminder to your users. Many experts will advise you to make sure you never reuse a string in more than one location. And even beyond that, to only interpolate a string where you desperately need to. This seems pretty strict to most developers, but there's a real advantage to that advice, since it can help you avoid a number of complications down the line.
Personally, I think that this advice makes more sense if you realize that you can't use the same string in two different contexts. The first concern that most developers raise when they hear this, is that it creates a lot of inefficiencies since you're duplicating content. Surely there must be some more efficient way than storing multiple copies of identical, or nearly identical strings, right? Well, to respond to that concern, I assure you that any extra work in translation that might be created by having multiple copies of a string can be very quickly dealt with by making use of a proper translation memory system, like we discussed previously.
The reason you need duplication is that if the same phrase occurs in two different contexts, that phrase will likely be translated two different ways. And to add to that complication, some of those contexts that you'll need to keep separate may not even exist in your native language. I'm not going to get too nitty-gritty with grammar here, but I want to give you a couple of brief examples to demonstrate what kinds of complications can arise. Firstly, there's ambiguity.
If the word edit is used in English on a button in multiple locations or menus, perhaps, the question could arise for the translator, is that a verb or a noun? Is it the action of editing like in, "Would you like to edit this video?" Or is that referring to a specific change that was made, like in, "The most recent edit was made 10 minutes ago." You can see that when these are used in full sentences, the context is very obvious. Secondly, as an example of contexts that don't exist in English, there are concepts like grammatical gender and noun cases.
If you've ever taken a high school Spanish, French or German class, you'll probably be familiar with the concept of gender. In some languages, a gender is assigned to all nouns. When talking about people, that gender makes sense. But, for inanimate objects, this concept of gender affects the way the word is formed and how it behaves. For the most part, the only practical effect it has is on the surrounding words used to introduce or describe that term. In Spanish, "The new car" can be translated as "El nuevo coche," but "The new table" could be translated as "La nueva mesa." "El" and "la" both mean "the," but since coche is masculine, and mesa is feminine, they use different forms for the word "the." It's the same with nuevo and nueva.
It's the same word, but in its masculine and feminine forms. If you were to use string interpolation to add a word to a string, perhaps a user name, you can see how this starts to complicate things since you would need multiple versions of the same interpolated string to accommodate the different genders of your user. But even worse than that, I want to give you an example of just how complicated things can become if you rely only on your understanding of your native language.
I once worked on a video game, where the game designer and programmers had used a system of base equipment and modified them with prefixes and suffixes, combining them to get items with different stats and abilities, like the "Emperor's shield of strength," or the "Enchanted defender of might." Everyone agreed that it was really clever that by creating and combining only 25 entries in each of these three categories, they were able to generate over 15,000 different items.
That is, until we went to start localizing the game, and we ran into some real problems. Firstly, word order changed. Secondly, should the French team translate the word "fortifie" for a masculine noun like shield, or for a feminine one, like sword? And if you're familiar with inflected languages that use noun cases like Russian or Finnish, that added a whole new set of complications that we won't bother getting too bogged down in right here.
In that instance, we really only had two options. We could maintain the fluidity and cleverness of that original system, but it would require that each language be handled uniquely, and it would place some very specific constraints on the translators. The other option was to generate 15,000 unique strings to be translated, and to rework the function that determined the name of any given item. In the end, the decision for us came down to translation memory, and unfortunately, at the time, the system we were already invested in using simply wasn't robust enough to help us translate that amount of text efficiently.
Many of these sorts of complications can be avoided up front if you're developing an application to be localized from the very beginning. But if you're working to localize an existing product, be aware that there will probably be some cases where you'll need to rework a few things to help make translation easier. Often, the best way to work through these is by getting input from your translators, or localization consultants, to understand how your current product is getting in the way of a good translation, and how you can rework things to provide the best experience for all of your users, regardless of their language.
- Timing internationalization and localization efforts
- Researching localization targets
- Evaluating and localizing text
- Internationalizing media
- Converting to Unicode
- Supporting right-to-left languages
- Working with translators
- Testing your localization