10 things localizers would like developers to keep in mind.

Our languages are rich and diverse.

English might be the worst, but European languages are sometimes no better.  Don’t assume languages map to your understanding as built from English.  And even when you are bilingual realise that your language may be more alike than languages that will be localized.

Think different input methods, font issues, grammar, plurals, gender and Bidi.  If your language doesn’t have issues with those then your life is easy.  So don’t assume that the localization world will map with your experience.

We use tools, please don’t make us use a text editor

There are a number of localization formats to choose from. We use some great tools that understand localization formats. Likely it won’t understand yours, and let’s be honest we don’t want to use a text editor as we lose lots of great features in our tools.

You have your editor wars as coders. Localizers also make use of tools.  Just as a coder is more productive in their tool, so a localizer is more productive in ours.  When we can’t use our tools we’re either forced to use something substandard that you’ve created or a pure text editor.  Please don’t.  Imagine if we forced you to write your C code in an HTML textarea?  No autocomplete, no lookup, no code folding.  You’d get frustrated quickly.  So do we.

Even if you have released 40 languages and nobody has complained.  Most localizers want your product in their language.  The goal is primarily our own languages, your tool is likely an important part of an ecosystem for their language.  So they work on a number of platforms, processes and formats.  When we complain we usually bring with us experience from many different avenues, even commercial localization experience.

Glossaries are a great help

Make a list of all the odd words that are part of your domain.  Ideally the translators is a user of your software.  But even if they are active users are 100% aware of the reason why it is called Rasterize and Posterize?  Having a small glossary can help teams create the needed terminology.

Add comments to strings

Sometimes a little comment can go a long way to explain what a string does.  Real candidates are those with variables, new terminology or unusual situations.  It helps if you can realise that parts of speech i.e. noun vs verb will impact a lot of languages.

Let us provide you with comments for strings

Comments are hard.  But if we are able to add the comments that relate to the issue we experience in our languages, likely we’re solving the problem for a number of other locales.  So make it really easy for others to add comments easily, not just coders.

Don’t ever split a sentence

This is sentence about


that is


into five parts

Hard to read? Now imagine when we localize a concatenated sentence? Imagine that the words “localization” and “split” are variables.  Now it’s even worse since all you gave us was.

This is sentence about

that is

into five parts

So please.  Just do whatever you need to in your code so that we’re dealing with a single sentence that we can freely translate as one whole.


Watch for named variables

Named variables e.g. $last_name can be helpful in that they tell us what the variable contains.  But be careful as new translators may be tempted to translate these e.g. $laaste_naam (Afrikaans).  Sorry not a win win for this one.

Please tell us about variables

Sometimes it’s not clear what information is contained in a variable such as %s.  Please make use of comments to tell us about the contents that will be in that variable, it may influence the way we translate and the words that we’ll use.

Allow us to reorder variables

Not all languages are structured the same you might say:

“User %s changed their password on %s”

And my language might say

“The password was changed on %s for user %s”

So don’t make any assumptions about order.  You can use named variables or if your language allows it we can order the variables as needed.  But be aware always that order can and will change.

Explain the content of variables

Too often we’re faced with one or two %s variables. But we really don’t know what data will appears in place of %s.  Knowing something about the data allows translators to adjust gender, know how to prefix the data and generally leads to a higher quality translation.

Idioms are problematic

“It’s raining cats and dogs”, means something in English.  So as a localizers I need to know:

  1. That its an idiom
  2. What that idiom means
  3. Find an equivalent one in my language

Now we don’t want your software to be dull and lifeless.  But be aware that idioms, colloquial speech, marketing blurbs are all very culturally specific.  So either remove them, reduce them or explain them to us.

One simple change multiplies a thousand times

When you want to make that one simple source string change a day or two before release realise how it multiplies.  You change a string in your English source.  This bubbles out to your 100 localization teams.  Each one then needs be communicated with, read that, fire up their tools, review the change, make a change, commit the change. Times that by the number of localizers.

It’s slightly worse when fixed punctuation, spelling or some non-critical change.

There is a good reason to have string freezes and that would be one of them, breaking string freezes has a much bigger knockon effect then you might be aware of.

Don’t build meta process around a bad process

Tempted to write another tool or another view or another things translators must do? Take a step back and evaluate if you are optimising a poor process.  Localizers are often involved with many localization processes and can give you a heads up about better processes happening elsewhere.

Remember that localizers are often localizing in multiple different places.  So each difference adds up to a lot of wasted cycles.  Rather help them focus 100% on localization.