Internationalization is a concern that affects almost everything in the frontend. It's hard to fix process mistakes. It's too easy to let cruft accumulate over a couple months, and have literally hundreds of files be affected. Adding a new locale means ensuring comprehensiveness of translation, and adding new UI text means updating all locales accordingly.
- inventory of every localized piece of text
- verify completeness of translation, audit use of idioms
- identify unused translation definitions
- integrate workflow with non-technical translator staff
- quickly detect failure cases (missing translation), but gracefully degrade if in production usage
- scenario: a message key is inadvertently renamed/deleted, breaking existing UI that uses it
- context-specific translation "namespacing" - same English words translate differently depending on which screen they are on
- complex concept + dynamic value translation ([N] of [M], last logged in on [Date], etc)
- prevent nonsensical parameter values
- possibly allow fully custom implementations per locale, not just simple string substitution
Visible text is actually a locale-specific rendering of a concept in human language. In other words, it's a taxonomy of hundreds of distinct little "view widgets", each rendering (typically) to a sequence of glyphs. Key-value l10n tables are just one possible implementation. That's the most unrestricted, flexible abstraction.
Implementation strategies should respect that footprint, but of course also optimize workflow and keep things easy and fast.