Unescaped HTML in translation text

These translated strings contain unescaped HTML which makes the translation linter unhappy.

• [user-scalable="no"] is not used in the <meta name="viewport"> element and the [maximum-scale] attribute is not less than 5.
• The document does not use <meta http-equiv="refresh">
• [user-scalable="no"] is used in the <meta name="viewport"> element or the [maximum-scale] attribute is less than 5.
• <input type="image"> elements have [alt] text
• The document uses <meta http-equiv="refresh">
• <input type="image"> elements do not have [alt] text

[brendankenny]

1. ICU Plural and Select can but put in as regular, no changes. All other (I’ll call it non-google-ICU) ICU is to use the new placeholder syntax.
2. Why is that awful? I don’t see it.
3. Maybe updates to #9114 address this, you can see more of it there. This has a few special cases that I might need to still work out, e.g. Replacement in ICU, ICU in replacement, but replacement next to ICU should be fine within the same string.

I think I see what you’re proposing now with the change in https://github.com/GoogleChrome/lighthouse/pull/9114/commits/74e11c15bf7c7149a5863ae85b0e3a8b1dcebea8#diff-0b037964dfdf09e1e312fb06ffb7f8bcR28

description: {
  message: '{link_start}Learn More!!!{link_end}. This audit took {milliseconds} ms.',
  placeholders: {
    link_start: '[->',
    link_end: '](https://developers.google.com/web/tools/lighthouse/audits/minify-css)',
    milliseconds: '{timeInMs, number, milliseconds}',
  }
}

If real ICU replacements are always inside google placeholders, it seems like it takes care of many issues:

• it won’t even be possible to accidentally translate them in tc
• it allows interoperation between the two systems
• we don’t even have to think about positional arguments since we’ll take care of those automatically and our (real) ICU formatting can continue as before

We will have to figure out how the placeholder example will work in a way that’s useful for translators, but I can see you’re looking at that 😃

[exterkamp]

I think to me, the advantage of the objects is that we are closer to a chrome standard format for i18n and that it allows simple placeholder syntax. It isn’t strictly required, we can hack together our own replacement conversion and have the strings be processed into this format right before going into en-US, but I think that would be messier (see “2.”).

I think that our strings have gotten sufficiently complex that we should start to think about encapsulating these as objects and converging on this messages.json syntax. We already have messages, descriptions, replacements, ICU, non-translated static blocks, markdown control syntax; honestly, I think that this could use some more structure, esp if we start to follow the placeholder rules better and stop sending non-translated text through.

Specific answers to your questions:

1. We don’t need to get rid of ICU, we should keep it. It just doesn’t need to go to the translators, it is control text that is never translated. Hence being placeholder’d and then re-added. ICU will still be used, but we shouldn’t send this non-translation ICU to the translators (in fact we don’t it is removed in pre-processing). This is more in line with the third example “Message with time in ms replacement.” than the fourth. The fourth example was just a thought, but I don’t think that’s even how it should be done.
2. This is reasonable. We can continue down this path and do custom extraction/replacement. Off hand I can’t think of anything complex that would need more than a detection -> conversion->translation->re-add type deal. But this is exactly what the message.json syntax was made for, and is already a solved problem, and I think that it will be easier to maintain this moving forward if we get closer to the standard, not farther away.