Show HN: Localization and translations should be code, not data
Caveats:<p>- Community provided translations are now a remote code execution vector, and can steal your passwords instead of merely displaying rude words.  You should now audit all translations up front before manually merging, instead of merely, say, locking down a writeable-by-default wiki after your first abuse occurs.<p>- Translation code is unlikely to be given a nice stable semvered sandboxed API boundary.  Less of an issue for in-house translation where translators are working against the same branch as everyone else, more of an issue when outsourcing translation - when you get a dump of translations weeks&#x2F;months later referencing refactored APIs, some poor fellow will need to handle the integration manually.<p>- Hot reloading and error recovery is likely an afterthought at best, for similar reasons. Translation typos are now likely to break your entire build, not just individual translation strings.<p>- Translators must now reproduce your code&#x27;s build environment to preview translations.<p>(Code-based translations may still make sense for some projects&#x2F;organizations despite these drawbacks, but these are some of the reasons dedicated translation DSLs encoded as &quot;data&quot; can make sense for other projects&#x2F;organizations)