When developers need to quickly prepare an interface for localisation, the „please do as I say, because God wanted it so” method seems to be the winning strategy.
- Save in resources all strings that go to the UI (don’t hardcode anything). Consider adding this condition to automatic code checks.
- Make sure with the person in charge of translations that you choose the correct resource format and that you export it correctly for translation.
- When writing UI strings:
- Give up any tricks to assemble strings from fragments because that usually works only for English (sometimes for Chinese). Examples :
- „Open” concatenated with „this folder” because [Open] is a button, or because you want „Open” in blue and „this folder” in teal. The proper solution: „Open” for a button and „Opens a folder” for its label.
- „Please insert” concatenated with „your name„, „your surname„, and „your location” because you wanted to save some bytes. The proper solution: „Please insert your name„, „Please insert your surname„, „Please insert your location„.
- Where you need to add at runtime a value to the string (or insert it into the string) – a number, a date, a name, an e-mail etc. – use variables. Example:
- „Shutdown is planned to: {0}„, where date and time will be substituted for {0}
- „A password reset email will be sent to {0} if an associated account exists„, where an email address will be substituted for {0}
- Give up the fun of WRITING IN CAPITAL LETTERS Because Reasons. Only use capital letters to indicate a product name (Microsoft Windows), a person’s name (Stefan Miotacz), a geographical location (Great Plains), etc. items that require capitalisation. Example:
- A button „Repository Cleanup” that starts a process to clean up a repository should be „Repository cleanup„; „Repository Cleanup” only applies for a name of another software product, feature, add-on etc.
- Add a comment (as the given resource format allows) to the following types of strings:
- Each short string of 1-2 words – explain its function. Example: „Open” – A good comment: „Indicates open state of the connection.„
- Each string with a variable – explain what the variable means. Example: „Password sent to {0} if the account exits” – A good comment: „{0} is substituted by e-mail address„.
- Try not to use expressions or symbols that only work in one culture. Examples:
- Hat size in inches – more universal are sizes „S”, „M”, „L”.
- Carp fish as a symbol of Christmas time – more universal is a Christmas tree.
- Give up any tricks to assemble strings from fragments because that usually works only for English (sometimes for Chinese). Examples :
- Before releasing UI strings to translation, take a deep breath and:
- Discard or comment out strings that are no longer used.
- Exclude technical strings from the translation, e.g. an URL alone or a string with parameters that have no actual effect on the UI. Nearly every resource format has a method of excluding strings from translation.
- Group the strings by where they are used (or keep them grouped that way if they were added in a logical order):
- All strings from one window belong in one block of resources, next to one another.
- if you use tooltips, save each tooltip text in pair with the option it describes.
- Do not sort the resources alphabetically – neither by string values, nor by keys. NEVER.
- Check the correctness and consistency of the English (source) version of the strings.
- Check the logic and consistency of the string keys.
- Add comments to short strings and strings with variables if it was not done before.
- Check the strings for culturally limited expressions if it was not done before.
- As a context for translators, provide one of these:
- The English (original) application with instructions how to navigate it.
- The English (original) screenshots covering 100% of the texts to be translated.
- Learn about localisation testing to add that step to your project’s budget and timeline.