We currently use the library i18next for our projects. If you are not familiar with what translation files are, check out the i18next essentials for a quick run through of how their translation files are used in development.
Below are some of the best practices we use to keep translation files short, manageable, easy to read, and (hopefully) easy to translate.
Start with standardized key groups
Start with a standard template of four key groups:
app- Words that are specifically about the app (or website), like the title and copyright text.common- Things that are reused everywhere, like “Read More”, "Save", and "Cancel".glossary- Words specific to the app that are reused consistently. For example, a site might have “Tags” or “Categories”.form- Things that are used in forms, such as fields and validation messages.
For the rest of the site, group keys according to the domain the key belongs to, and let the reader know about what might be the purpose of the key. For example, adding “_placeholder” or “_button” to the end of your key gives the reader a clear idea of where the string is used.
home- Keys for the homepagenews- Keys for a news list, detail page, or navigation
Sample json file:
Naming Keys
Whenever possible, use generic, short translation keys. The shorter the key, the more places where it can be reused. While you can use nested keys, deeply nested keys are harder to manage. At Cast Iron, we try to avoid using more than three levels.