Which type of client application localization is more flexible?

Question

JavaScript

Two options are known: strictly declared JSON objects with translations, where there can be many nestings and the entire text is determined by a key, which can be arbitrarily short, since it is not displayed as a translation itself.
As for me, the advantages of this approach:
- The original text and its translation are easy to replace (it is always located on the same key chain)
Cons:
- Each time you need to import the text-content and take the value by the desired keys
- If you break the text into groups, maybe duplication of words/translations
Vuex-i18n, for example, uses filters that take an arbitrary string (no matter where it comes from) and translate it
Pros:
- It is not necessary to move the text to a separate file, especially if it is guaranteed not to change in the future
Cons:
- In different parts of the application, the same phrase can be translated differently, and for one phrase there can be only one translation, since the list of translations key - value without nesting
- To translate entire sentences, you will have to copy the original text into files with translation for each language
Which option do you use and what other disadvantages can be in one of them?

Answer 1

staunch supporter of the second option.
code is written to be read.
string literals are the most important source of information for understanding code at a glance. There may or may not be comments in the code. the name of classes-methods-functions-variables-constants may or may not be meaningful. but the code that writes something to the user is somehow connected with this something.
any trial in an unfamiliar or well-forgotten codebase begins with localizing the problem from the user's point of view (in the vast majority of cases, this means in the interface), and then trying to understand "what he said". and a simple text search by source in the second option allows you to immediately view the list of all the places where this text occurs, and in the first option it forces you to look for one occurrence of each of the keys.
it is especially disgusting when the format string from some printf thread is localized as the first option: some parameters are transferred, but how they are interpreted cannot be found out without digging through the resources.
the very need to come up with meaningful keys for each line in the first version is something else. one of the two acknowledged hardest things in all of programming (the classics: naming things and invalidating caches) suddenly increases by the number of all lines in software.
that's what the first option is better for, it's support from the toolkit. all sorts of ide-tables resources in different languages ​​show, there are convenient online tools for collective translation, and so on.
however, in practice, this all does not work, because the translation of software is a process with the active participation of the customer's specialists (they always know better what is correct, even if they themselves are not in the tooth with their feet), and you cannot slip their ide legal department, and coordinate them the boss will be on office workflow, in extreme cases, a printout. in general, in real projects between offices a file with lines of software in excel is chasing. which is converted into resources and back by some kind of self-made tool, and then for a long time, with a curse, manually merged with the resources in the software, because under-translators are very fond of arbitrarily correcting what they were assigned, and something else, in other languages (like, "in that wording it doesn't translate beautifully, it's better to let it be so").
and this leads to the main disadvantage of the second approach: when the text in the main language is corrected, it will also be necessary to correct all occurrences of this string throughout the software. however, standard engineering practices (dry, generalization of reusable code) successfully prevent too much repetition of the same thing in different places.
about different translations of one phrase - yes, this happens, but really very rarely. so rare that some crutch with an added space and a comment why it is needed there does not subjectively seem like something that should be handled at the engine level instead. I literally can remember a couple of times in more than 20 years of writing software for the local market. and I live in Kazakhstan, everything here is in several languages ​​and this is enshrined in law.

Answer 2

The first option is proven, convenient and works great in most cases.
It is enough to write convenient helpers and pass a short key to them:

i18nMessage('landing_header');
i18nPlural('comments_count', comments.size);
i18nWrapper('landing_caption', [<strong />]);

Nested keys should be avoided. Use them only for lists.