Localisation in a nutshell

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.

  1. Save in resources all strings that go to the UI (don’t hardcode anything). Consider adding this condition to automatic code checks.
  2. Make sure with the person in charge of translations that you choose the correct resource format and that you export it correctly for translation.
  3. 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: For a string Open, a good comment is Indicates open state of the connection.
      • Each string with a variable – explain what the variable means. Example for a string Password sent to {0} if the account exits, a good comment is {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 XS, S, M, L, XL.
      • Carp fish as a symbol of Christmas time – more universal is a Christmas tree.
  4. 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.
  5. 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.
  6. Learn about localisation testing to add that step to your project’s budget and timeline.