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/5...@github.com>
_______________________________________________
rails-dev mailing list
rails-dev@openstreetmap.org
https://lists.openstreetmap.org/listinfo/rails-dev
