<span style="color: transparent; display: none; height: 0; max-height: 0; max-width: 0; opacity: 0; overflow: hidden; mso-hide: all; visibility: hidden; width: 0;">
  <p dir="auto">Fall back to English when a string is missing from the localization or the translation refers to a nonexistent interpolation argument.</p>
<h2 dir="auto">Rationale</h2>
<p dir="auto">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 <code class="notranslate">I18n.t</code> function to raise an <code class="notranslate">I18n::MissingInterpolationArgument</code> 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.</p>
<p dir="auto">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 <a class="issue-link js-issue-link" data-error-text="Failed to load title" data-id="2184006104" data-permission-text="Title is private" data-url="https://github.com/openstreetmap/openstreetmap-website/issues/4572" data-hovercard-type="pull_request" data-hovercard-url="/openstreetmap/openstreetmap-website/pull/4572/hovercard" href="https://github.com/openstreetmap/openstreetmap-website/pull/4572">#4572</a>, 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.</p>
<p dir="auto">I thought <a class="issue-link js-issue-link" data-error-text="Failed to load title" data-id="2787981070" data-permission-text="Title is private" data-url="https://github.com/OpenHistoricalMap/ohm-website/issues/264" data-hovercard-type="pull_request" data-hovercard-url="/OpenHistoricalMap/ohm-website/pull/264/hovercard" href="https://github.com/OpenHistoricalMap/ohm-website/pull/264">OpenHistoricalMap#264</a> would fix the problem on the homepage by aligning with the ID from upstream. Unfortunately, my change instead led to 500 errors like <a class="issue-link js-issue-link" data-error-text="Failed to load title" data-id="2851794382" data-permission-text="Title is private" data-url="https://github.com/OpenHistoricalMap/issues/issues/972" data-hovercard-type="issue" data-hovercard-url="/OpenHistoricalMap/issues/issues/972/hovercard" href="https://github.com/OpenHistoricalMap/issues/issues/972">OpenHistoricalMap/issues#972</a>, 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 <a class="issue-link js-issue-link" data-error-text="Failed to load title" data-id="1721544126" data-permission-text="Title is private" data-url="https://github.com/OpenHistoricalMap/issues/issues/537" data-hovercard-type="issue" data-hovercard-url="/OpenHistoricalMap/issues/issues/537/hovercard" href="https://github.com/OpenHistoricalMap/issues/issues/537">OpenHistoricalMap/issues#537</a>.</p>
<h2 dir="auto">Suggestion</h2>
<p dir="auto">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, <a href="https://kinduff.com/2022/02/07/an-i18n-coding-adventure/" rel="nofollow">this blog post</a> explores setting <code class="notranslate">missing_interpolation_argument_handler</code> 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 <code class="notranslate">t</code> but passing <code class="notranslate">en</code> as the <code class="notranslate">locale</code>. If we need to retain the ability to spot when a translation is missing, maybe we can limit this handler to production code.</p>
<p dir="auto">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.</p><p style="font-size:small;-webkit-text-size-adjust:none;color:#666;">—<br />Reply to this email directly, <a href="https://github.com/openstreetmap/openstreetmap-website/issues/5819">view it on GitHub</a>, or <a href="https://github.com/notifications/unsubscribe-auth/AAK2OLJOFYD6MCXYOZF4ZU32VCK5JAVCNFSM6AAAAABZJJ5QC2VHI2DSMVQWIX3LMV43ASLTON2WKOZSHEZDSOJXHAYDGMY">unsubscribe</a>.<br />You are receiving this because you are subscribed to this thread.<img src="https://github.com/notifications/beacon/AAK2OLJ7KFVXJGNDVTC24332VCK5JA5CNFSM6AAAAABZJJ5QC2WGG33NNVSW45C7OR4XAZNFJFZXG5LFVJRW63LNMVXHIX3JMTHK5I7KWE.gif" height="1" width="1" alt="" /><span style="color: transparent; font-size: 0; display: none; visibility: hidden; overflow: hidden; opacity: 0; width: 0; height: 0; max-width: 0; max-height: 0; mso-hide: all">Message ID: <span><openstreetmap/openstreetmap-website/issues/5819</span><span>@</span><span>github</span><span>.</span><span>com></span></span></p>
</span>


<div style="display: flex; flex-wrap: wrap; white-space: pre-wrap; align-items: center; "><img alt="1ec5" height="20" width="20" style="border-radius:50%; margin-right: 4px;" decoding="async" src="https://avatars.githubusercontent.com/u/1231218?s=20&v=4" /><strong>1ec5</strong> created an issue <a href="https://github.com/openstreetmap/openstreetmap-website/issues/5819">(openstreetmap/openstreetmap-website#5819)</a></div>
<p dir="auto">Fall back to English when a string is missing from the localization or the translation refers to a nonexistent interpolation argument.</p>
<h2 dir="auto">Rationale</h2>
<p dir="auto">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 <code class="notranslate">I18n.t</code> function to raise an <code class="notranslate">I18n::MissingInterpolationArgument</code> 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.</p>
<p dir="auto">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 <a class="issue-link js-issue-link" data-error-text="Failed to load title" data-id="2184006104" data-permission-text="Title is private" data-url="https://github.com/openstreetmap/openstreetmap-website/issues/4572" data-hovercard-type="pull_request" data-hovercard-url="/openstreetmap/openstreetmap-website/pull/4572/hovercard" href="https://github.com/openstreetmap/openstreetmap-website/pull/4572">#4572</a>, 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.</p>
<p dir="auto">I thought <a class="issue-link js-issue-link" data-error-text="Failed to load title" data-id="2787981070" data-permission-text="Title is private" data-url="https://github.com/OpenHistoricalMap/ohm-website/issues/264" data-hovercard-type="pull_request" data-hovercard-url="/OpenHistoricalMap/ohm-website/pull/264/hovercard" href="https://github.com/OpenHistoricalMap/ohm-website/pull/264">OpenHistoricalMap#264</a> would fix the problem on the homepage by aligning with the ID from upstream. Unfortunately, my change instead led to 500 errors like <a class="issue-link js-issue-link" data-error-text="Failed to load title" data-id="2851794382" data-permission-text="Title is private" data-url="https://github.com/OpenHistoricalMap/issues/issues/972" data-hovercard-type="issue" data-hovercard-url="/OpenHistoricalMap/issues/issues/972/hovercard" href="https://github.com/OpenHistoricalMap/issues/issues/972">OpenHistoricalMap/issues#972</a>, 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 <a class="issue-link js-issue-link" data-error-text="Failed to load title" data-id="1721544126" data-permission-text="Title is private" data-url="https://github.com/OpenHistoricalMap/issues/issues/537" data-hovercard-type="issue" data-hovercard-url="/OpenHistoricalMap/issues/issues/537/hovercard" href="https://github.com/OpenHistoricalMap/issues/issues/537">OpenHistoricalMap/issues#537</a>.</p>
<h2 dir="auto">Suggestion</h2>
<p dir="auto">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, <a href="https://kinduff.com/2022/02/07/an-i18n-coding-adventure/" rel="nofollow">this blog post</a> explores setting <code class="notranslate">missing_interpolation_argument_handler</code> 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 <code class="notranslate">t</code> but passing <code class="notranslate">en</code> as the <code class="notranslate">locale</code>. If we need to retain the ability to spot when a translation is missing, maybe we can limit this handler to production code.</p>
<p dir="auto">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.</p>

<p style="font-size:small;-webkit-text-size-adjust:none;color:#666;">—<br />Reply to this email directly, <a href="https://github.com/openstreetmap/openstreetmap-website/issues/5819">view it on GitHub</a>, or <a href="https://github.com/notifications/unsubscribe-auth/AAK2OLJOFYD6MCXYOZF4ZU32VCK5JAVCNFSM6AAAAABZJJ5QC2VHI2DSMVQWIX3LMV43ASLTON2WKOZSHEZDSOJXHAYDGMY">unsubscribe</a>.<br />You are receiving this because you are subscribed to this thread.<img src="https://github.com/notifications/beacon/AAK2OLJ7KFVXJGNDVTC24332VCK5JA5CNFSM6AAAAABZJJ5QC2WGG33NNVSW45C7OR4XAZNFJFZXG5LFVJRW63LNMVXHIX3JMTHK5I7KWE.gif" height="1" width="1" alt="" /><span style="color: transparent; font-size: 0; display: none; visibility: hidden; overflow: hidden; opacity: 0; width: 0; height: 0; max-width: 0; max-height: 0; mso-hide: all">Message ID: <span><openstreetmap/openstreetmap-website/issues/5819</span><span>@</span><span>github</span><span>.</span><span>com></span></span></p>

<script type="application/ld+json">[
{
"@context": "http://schema.org",
"@type": "EmailMessage",
"potentialAction": {
"@type": "ViewAction",
"target": "https://github.com/openstreetmap/openstreetmap-website/issues/5819",
"url": "https://github.com/openstreetmap/openstreetmap-website/issues/5819",
"name": "View Issue"
},
"description": "View this Issue on GitHub",
"publisher": {
"@type": "Organization",
"name": "GitHub",
"url": "https://github.com"
}
}
]</script>