| HN Mirror

> 1. Usually OSS projects accept patches via PRs. Translations are no different for 99% of all projects.

Plenty of non-OSS projects out there, using services like https://www.localizor.com/ or in-house equivalents, and no public VCS. OSS projects accepting translations via PR can also spend less time reviewing code, if they can just rubber stamp changes to translation data, instead of auditing changes to translation code from new contributors.

> Why? Keys with params will break no matter if it is in MessageFormat or TypeScript.

Generally in C++ projects I end up with roughly the following:

    [rest of codebase] <----> [translation bindings] <----> [translation data]

Refactoring types (say, changing a field to a function) in "rest of the codebase" will inadvertently cause changes to the translation bindings, but since that code is already remapping from C++ types/params to translation specific types/params, the latter - and thus translation data - is frequently unchanged.

When you bypass this with code:

    [rest of codebase] <----> [translation functions]

The lack of a binding layer means refactoring types in "rest of the codebase" by definition refactors translation types as well - and thus translation data must change.

JavaScript's dynamically typed, bag of string keyed objects, can subvert the need for and existence of a translation binding layer when blindly forwarded, so I suppose MessageFormat isn't a 100% win here either. And, in theory, you can have a translation binding layer without being data-driven, I'm just skeptical that people will bother to strictly enforce it's usage.

> 3. And that is great! Bugs should break builds.

Not all bugs should break all builds on large scale projects / in large scale orgs. A typo or missing string in the french translation of gmail should not break google search, even though google is monorepository. When you have thousands of employees, something will be broken by somebody at all times and progress will crawl to a halt as everyone gets blocked by everyone else - even with CI, someone will have a bypass option, or will pass preflight but not full CI, or ...

Constantly alerting programmers about unactionable CI failures merely trains programmers to ignore CI. Broken translations should perhaps be surfaced to the localization team, and perhaps QA or a project manager who can escalate things if localization drops the ball - but proper fault isolation should avoid breaking everything for everyone, and instead limit the fault to those whom said fault is actionable. A graphics or physics programmer in gamedev probably shouldn't be tasked to fix french localization typos, at least by default.

This is especially true for localization - localization always lags behind the tip of development, and is arguably always broken/buggy except for the occasions when you pick a version to stabilize, wait for translations, and release. Why should some localization errors (missing strings) be handled through placeholders, yet others (bad syntax) break the build for programmers, when the same non-programmers (localizers, project managers) should generally be in charge of fixing both?

> 4. Well, that could happen. But you could also structure your localizations into a stand-alone subproject and then it would no longer be the case.

At the very least, translators must now reproduce the build environment of the localiations subproject (so, in the context of the original article's github repository as currently stands, they'd need to install make + pnpm (+ tsc? or will pnpm auto-install tsc? will it auto-update, or will using new syntax require updating tsc for translators?)