CODEWITHSUNDEEP
localizationinternationalizationmultilingual
Tantelope
Tantelope

Reputation: 617

What is the most practical approach to using and/or reusing localized strings

Problem

Say I have at least 3 different dialog views:

Create Would you like to create this? [Cancel][OK]

Save Would you like to save this? [Cancel][OK]

Delete Would you like to delete this? [Cancel][OK]

What would be the most practical approach to creating key/value pairs to use in this case?

Option 1: Unique keys for each view

createTitle : "Create"
createDescription : "Would you like to create this?"
createPositiveButton: "OK"
createNegativeButton: "Cancel"

saveTitle : "Save"
saveDescription : "Would you like to save this?"
savePositiveButton: "OK"
saveNegativeButton: "Cancel"

deleteTitle : "Delete"
deleteDescription : "Would you like to delete this?"
deletePositiveButton: "OK"
deleteNegativeButton: "Cancel"

Drawbacks: lots of duplicate values across keys. Lots of time spent on changing each one, for example if you want to change Ok to Accept

Option 2: Reusable variables for common strings

genericPositiveButton: "OK"
genericNegativeButton: "Cancel"

createTitle : "Create"
createDescription : "Would you like to create this?"

saveTitle : "Save"
saveDescription : "Would you like to save this?"

deleteTitle : "Delete"
deleteDescription : "Would you like to delete this?"

Drawbacks: If individual changes are needed, for example to change OK to Confirm Create Confirm Save and Confirm Delete then the variables in the code need to be changed.

Summary

Obviously there is no one-size-fits-all answer here, but I'm wondering if there is a set of best practices regarding the use and reuse of variables for localization files, especially in a large multi-platform application.

Upvotes: 1

Views: 523

Answers (2)

Jim DeLaHunt
Jim DeLaHunt

Reputation: 11395

I advocate for Option 1. And double down.

But really, this is an important design decision, and you should talk it over with your internationalisation team. Be prepared for careful tradeoffs of investment now and faster, cheaper localisation later, versus faster, cheaper time to first market now and rework costs later. "Practical" usually boils down to a set of weights placed on those tradeoffs.

Here's the case for Option 1. Invest now, for faster, cheaper localisation later. You say you are interested "especially in a large multi-platform application". Let's assume that "large" also means, "ready to be localised into a large number of languages around the world", and, "large enough to harvest economies of scale".

Any localisation done at scale should involve automation, by the core developers, the localisation team, and the language service providers who do the translation. An important piece of automation is the use of a translation memory. This is a tool which recognises when a source phrase is identical or similar to a source phrase already translated, and offers the translation for re-use with that source phrase.

As you localise to more and more languages, you are more and more likely to come across distinctions which the original developers didn't know to make, because they don't matter in the language which the original developers speak.

In your examples, the word "this" jumped out at me. You are omitting the object of the sentence, the noun which names the thing being created or saved. You are making no provision for the word "this" to be declined differently depending on the gender or quantity of the implicit object. You should expect to encounter a language where the object needs to be explicit, or the reference to it to be spelled differently for creation versus saving.

When you allow messages to be stored as complete units, you allow the translators and localisers the control they need to get the phrase right.

You should not fear the effort required to change "OK" to "Accept". If you have automation, and consistent spelling of the keys for the button texts, then you should be able to write a tool to make the changes in bulk. For instance, a regular expression can recognise the keys "createPositiveButton", "deletePositiveButton", and "savePositiveButton", then change the "OK" text after all those keys to "Accept", in one action.

Upvotes: 1

ymbirtt
ymbirtt

Reputation: 1666

You've not been specific with languages here, so I'm going to use Ruby on Rails to hash together a simple toy example.

Option 3: Fallbacks when translations are missing

verbs:
  save: 'save'
  delete: 'delete'
  create: 'create'
dialogs:
  default:
    ok: 'OK'
    cancel: 'Cancel'
    title: '%{verb}'
    text: 'Would you like to %{verb} this?'
  delete:
    text: 'Are you sure you want to %{verb} this? Warning: This cannot be undone'
  save:
    ok: 'Confirm %{verb}'

You could then use a helper which is intelligent enough to use these fallbacks:

module DialogHelper
  def dialog_text(verb, field)
    translated_verb = t("verbs.#{verb}")
    t("dialogs.#{verb}.#{field}", default: t("dialogs.default.#{field}", verb: translated_verb), verb: translated_verb)
  end

  def nicely_render_a_dialog(verb)
    render(partial: 'nice_dialog_box', locals: {verb: verb}) # This then calls dialog_text(verb, 'ok'), dialog_text(verb, 'cancel') repeatedly
  end

  def create_dialog
    nicely_render_a_dialog('create')
  end

  # et cetera...
end

If you want to change the default "OK" text, it's defined in exactly one place. If you want to specifically override the delete confirmation text, you just write that one case under the dialogs.delete subtree. I've yet to find any published best practices for something like this, but I imagine a hierarchical structure, possibly with multiple layers of fallbacks, would afford the sort of flexibility you're after.

Upvotes: 0

Related Questions