Teams do internationalization of applications either from the very beginning or after delivering a primary language. Usually, the translation flow looks similar to the following:
And from a developer perspective, it contains 3 steps:
It is pretty easy to create translation keys, but hard to do it in a way that it
There are already good i18n guidelines written by Phraseapp and MDN, but they do not answer how should we name the translation keys themselves.
To abstract from implementation, we'll agree on translation function t
, which takes a translation key and returns message:
t('things') // => "How things work"
You might have only custom defined keys, without defaults. For instance:
t('landing_page.how_things_work') // => "How things work"
As for the initial translation, there will be a need to add initial messages to a translation file.
Pros
Cons
You can specify both - translation key and default message:
t({
key: 'landing_page.how_things_work',
defaultMessage: "Things explained"
}) // => "How things work"
Pros
Cons
t({ key: 'general.errors.empty', defaultMessage: 'empty'})
;You can use the same text as your message in English:
t('How things work') // => "How things work"
This way we're eliminating the necessity to maintain default messages and create keys for them.
Pros
Cons
As you might already understand, there's no 100% correct to define the translation keys and the decision should be made based on your project size, how often you change translations and team preference.
At the current project, we've decided to give a shot for "#3 Straightforward" approach for sake of simplicity, ease of maintenance and less context switching.
But how do you cook i18n keys?