Currently, we store cert error title strings in netError.dtd [0] and use it in aboutNetError.xhtml [1]. Since we want to eliminate the usage of innerHTML in aboutNetError.js [2], we should consider porting these strings to Fluent [3] and set them dynamically in aboutNetError.js depending on the error encountered like this [4].

[0] https://searchfox.org/mozilla-central/rev/fa2df28a49883612bd7af4dacd80cdfedcccd2f6/mobile/locales/en-US/overrides/netError.dtd#53
[1] https://searchfox.org/mozilla-central/rev/fa2df28a49883612bd7af4dacd80cdfedcccd2f6/browser/base/content/aboutNetError.xhtml#44
[2] https://searchfox.org/mozilla-central/rev/fa2df28a49883612bd7af4dacd80cdfedcccd2f6/browser/base/content/aboutNetError.js#245
[3] https://searchfox.org/mozilla-central/source/browser/locales/en-US/browser/aboutCertError.ftl
[4] https://searchfox.org/mozilla-central/rev/fa2df28a49883612bd7af4dacd80cdfedcccd2f6/browser/base/content/aboutNetError.js#671

I don't believe this is a good first-bug, because there is a lot to plan for first, and to fix.

Take this string for example:

<!ENTITY inadequateSecurityError.longDesc "<p><span class='hostname'></span> uses security technology that is outdated and vulnerable to attack. An attacker could easily reveal information which you thought to be safe. The website administrator will need to fix the server first before you can visit the site.</p><p>Error code: NS_ERROR_NET_INADEQUATE_SECURITY</p>">

DOM overlays don't support nested markup. I believe, if I remember previous conversations correctly, that we would migrate this as separate messages and lose most of the markup.

inadequate-security-error-desc = <span data-l10n-name='hostname'></span> uses security technology that is outdated and vulnerable to attack. An attacker could easily reveal information which you thought to be safe. The website administrator will need to fix the server first before you can visit the site.
security-error-code = Error code: { $errorCode }>

The same is true for lists

<!ENTITY sharedLongDesc "
<ul>
  <li>The site could be temporarily unavailable or too busy. Try again in a few
    moments.</li>
  <li>If you are unable to load any pages, check your computer’s network
    connection.</li>
  <li>If your computer or network is protected by a firewall or proxy, make sure
    that &brandShortName; is permitted to access the Web.</li>
</ul>
">

We should migrate each bullet item as a separate Fluent message.

@pike

1. Does this match your expectation?
2. Is there a way for us to migrate this content, and avoid losing all translations?

Yes, I think we should take those strings apart.

Can we migrate them? Maybe maybe dirty dirty.

The challenge is to get xml-ish content segments, w/out a proper parse environment. It might help to replace &brandShortName; with { -brand-short-name } as literal text, and to then try to do XML parsing on it. And then to create FTL.TextElement instances of it.

Those don't escape {-brand-short-name} on serialization, so this might be OK. But it's also a bit fishy. Looking at stas here.

The whole thing would need a good check, and it might need some upstream fluent.migrate changes to survive python errors constructively. 'Cause I'd be very surprised if there wasn't a language that had parsing errors etc.

@prathiksha
Sorry, I think we should put this on hold until we have a clear answer for migrating the existing translations.

I honestly don't feel comfortable in losing this amount of translations, especially for pages that have security implications for users.

@pike
Could you get a bug on file blocking this one and describing what needs to be done in fluent-migration in order to support this? I understand that giving a clear scope and a timeline is not a fair expectation, given our constant resourcing problems, but I'd like at least:

• A description of what needs to be done, and where in the code.
• Who could mentor and provide guidelines, in case someone wants to pick up the work.

I filed bug 1626976, but I'm not sure that that's blocking this bug. It might just be that we figure out here if that's needed, prove that it works here, and if it does, uplift the fix to fluent.migrate upstream, and figure out how to write tests for it.

(In reply to Axel Hecht [:Pike] from comment #5)

I filed bug 1626976, but I'm not sure that that's blocking this bug. It might just be that we figure out here if that's needed, prove that it works here, and if it does, uplift the fix to fluent.migrate upstream, and figure out how to write tests for it.

We also need something to parse the translated HTML and return a specific node, don't we? Or would that be part of the ad-hoc recipe?

I'd suggest to keep that in the recipe, at least for now.

Upstreaming that if it proves to be successful and generally applicable would be a separate task.

I filed a bug for the latter, and set the dependencies. In the current status, we're blocked from completing this migration.

Both bugs require time even for investigating the issue and prioritizing, and they're competing with a lot of other projects and requests. If this is needed, we need to have a conversation about which projects should be deprioritized to make space for this. In case, that's a conversation where Jeff (localization's manager) should be involved.