[openstreetmap/openstreetmap-website] Missing translations should fall back to English (Issue #5819)

[Minh Nguyễn]

1ec5 created an issue (openstreetmap/openstreetmap-website#5819)

Fall back to English when a string is missing from the localization or the translation refers to a nonexistent interpolation argument.

## Rationale

Sometimes a localizable string has to get changed to a different ID whenever the interpolated placeholders change. Otherwise, translations coming from Translatewiki.net can get out of sync with the new string’s set of interpolations, causing the `I18n.t` function to raise an `I18n::MissingInterpolationArgument` exception. Changing the string ID can be a good signal that the translator needs to slow down and potentially retranslate the message. But often, the content change is minor yet it’s difficult to track down the old string to ensure consistency. As a translator, I feel this every time a nontrivial change occurs on the Copyright page.

Over in the OpenHistoricalMap fork of this project, we’ve had to customize many messages that have interpolation arguments. For example, we had a couple miscues merging #4572, which renamed a string on the homepage at the same time it changed its interpolation arguments. Git detected the change as a merge conflict in en.yml but not in the source files that used the string. As a result, many locales wound up with a raw ID in the UI.

I thought OpenHistoricalMap/ohm-website#264 would fix the problem on the homepage by aligning with the ID from upstream. Unfortunately, my change instead led to 500 errors like OpenHistoricalMap/issues#972, either because translators hadn’t gotten around to updating the string or because they’d accept the translation memory suggestion coming from openstreetmap-website’s localization. We can rename the string again to avoid further problems, but it’s just one of many lurking issues along these lines. Another example is OpenHistoricalMap/issues#537.

## Suggestion

Translatewiki.net assumes the software behaves like MediaWiki, which is resilient to strings that include nonexistent interpolation arguments. For the I18n library we’re using, [this blog post](https://kinduff.com/2022/02/07/an-i18n-coding-adventure/) explores setting `missing_interpolation_argument_handler` to suppress the error in favor of something gentler, such as a “missing key” string. Even better, I suspect we could implement a handler that falls back to English, the base localization, by passing the same string into `t` but passing `en` as the `locale`. If we need to retain the ability to spot when a translation is missing, maybe we can limit this handler to production code.

I might be missing a simpler solution, but in general it seems like the translation process is too fragile for a 500 error to be the right response to a malformed translation.

-- 
Reply to this email directly or view it on GitHub:
https://github.com/openstreetmap/openstreetmap-website/issues/5819
You are receiving this because you are subscribed to this thread.

Message ID: <openstreetmap/openstreetmap-website/issues/5819 at github.com>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/rails-dev/attachments/20250318/7a232c9f/attachment-0001.htm>