DOs and DON'Ts in programming for successful internationalization

[Spline]

While looking at a half-translated version of The Events Calendar, I found that some of the messages to be translated were made up of several strings. For instance, to display “Previous Events”, there was a one string containing “Events” and another one containing “Previous %s”. Similarly, for “New Event”, there was a string for “Event” and another one for “New %s”.

While this may be smart from a programming point of view for reasons I’m definitely not in a position to judge, it’s typically what you shouldn’t do when you want your project to be translated. Fact is that in English, you use the same form of the adjective (e.g. Previous or New) regardless of the noun after it. But in French, to give just one example, the adjective for “new” can have up to 5 forms:

• nouveau if followed with a singular, masculine noun which starts with a consonant (nouveau calendrier)
• nouvel if followed with a singular, masculine noun which starts with a vowel (nouvel événement)
• nouvelle if followed with a singular, feminine noun (nouvelle catégorie)
• nouveaux if followed with a plural, masculine noun (nouveaux événements, nouveaux calendriers)
• nouvelles if followed with a plural, feminine noun (nouvelles catégories)

As a result, there is no way we can correctly translate “New %s” for all possible values of %s. Again, this is just one example; some languages are even more complex. The French language does not use case, unlike Russian or Icelandic, for instance.

Anyway, if you want your strings to be translatable:

1. Avoid inserting words as variables in a sentence fragment.
   You may, however, insert a variable part if it’s separated from the rest of the sentence (e.g. after a colon).
2. If you really, really have to use a variable in your string, document it in your code so that translators know what will be inserted here and can figure out what it all means. Will a number be inserted? A date? A user-created description? A status or condition?
3. If you think documenting your code is not worth the effort, wait until you have 30 community translators for 30 different languages asking you what’s in the variable – or until you have 300 customers complaining about wrong translations.

These are just a few ideas; is there anything else you community translators found difficult/impossible to translate because of the way it was programmed?

[Barry]

Hi Spline,

Thanks for your feedback.

I’m particularly interested in your comments about strings such as “New %s”.

To give some further context, we’re not just trying to make it easier on ourselves when it comes to implementing strings that support singular and plural forms – we’re also supporting a use case where users may wish to replace usage of “event” and “events” with some alternative nomenclature, like “party” and “parties”.

Arguably, this could also be handled by using a purpose-built set of translations and avoid the need to embed strings like “New %s”, however that’s not always an efficient or easy way for users to do things.

That to say, what we’re aiming for here is a pragmatic way to provide reasonable support for localization whilst still making it easy to perform other customizations at the same time.

If you really, really have to use a variable in your string, document it in your code so that translators know what will be inserted here and can figure out what it all means. Will a number be inserted? A date? A user-created description? A status or condition?

From your point of view as a potential translator, do you see any way for us to make things easier for you without dropping the above capability?

For instance, would it help for us to add some context or inline documentation to the effect that the placeholder is likely to be replaced with a word meaning “event”, but can actually be user defined and so may be anything?

If you think documenting your code is not worth the effort, wait until you have 30 community translators for 30 different languages asking you what’s in the variable – or until you have 300 customers complaining about wrong translations.

We’ve been investing more and more resources in this area but that doesn’t mean we’ll always get it right.

Please do continue to provide your feedback and we’ll be happy to see what we can do: we fully realize how important this is – and how vital it is to have community participation.

[Spline]

Hm, that’s a tricky one 🙂

It’s an interesting feature indeed, but then you would also want to make it convenient for your international users, not just the English-speaking ones, right?

If so, you may try and implement fully customizable labels for the most visible fields, buttons, links and headers containing the word for Event. If the user chooses to use a different word, give them the ability to change those labels too – while providing default values you would build using the “New %s” mechanism. English-speaking users would be happy with the defaults, and users from “morphologically rich” languages would appreciate being able to edit them for their specific needs.

Would that do?

[Spline]

Hi Barry,

Plus, you can take that as an opportunity to showcase the feature for your users, giving them a preview of how the new word will be reflected in several labels.

But by all means, yes indeed, it’s a good idea to let your translators know that the variable part will most probably contain the word “event”, so that at least the default label is correct.

[Barry]

Spline: thanks for taking the time to provide your feedback. I’ll discuss this with the team and we’ll see what we can come up with.

Please note however there won’t be an immediate change (simply because we’re about to launch a new release and a lot of work is already in progress for the subsequent release) – but we’ll certainly take this on board and see how we can improve going forward.

[Spline]

You’re most welcome! Thanks for considering them.

And congrats for your app, by the way, I’ll really love to use it with its updated translations 😉

[Barry]

Thank you 🙂

[Author]

Posts