The function registry needs something more powerful than readonly

[mihnita]

The current definition is

<!ATTLIST input readonly (true|false) "false">
<!ATTLIST option readonly (true|false) "false">

I would propose something along these lines:

<!ATTLIST input l10nAccess (hidden|readonly|values|pattern|freeform) "readonly">
<!ATTLIST option l10nAccess (hidden|readonly|values|pattern|freeform) "readonly">

[mihnita]

Justification

This is (most likely) something for translators and the tools they use.
Developers can do whatever they want, including changing the readonly flag.

Hence the proposed name: l10nAccess

For the possible values, this covers the main kind of access translators might:

• hidden: These are things that don't affect translation, there is not need for translators to even see this field.
  Similar (for example) to "on click" attributes in HTML.
• readonly: these are fields that can't be changed by the translators, but it might be handy for them to see, because it gives them more context.
  For example URLs to images.
• values: translators might need to change these values, but only to select from a list.
  For example grammatical case (locale dependent, but a fixed set)
• pattern: translators might need to change this, but the translated string is subject to validation.
  For example changing the URL to a wiki page?
  TBD: a name other than pattern that means some kind of validation...
• freeform: translators might need to translate, and are free to do whatever they need.
  For example the alt attribute of an image.

And finally, defauly=readonly is a safer than readonly=false, which allows translators to change everything they want except if explicitly forbidden.

[mihnita]

Maybe ITS 2.0? https://www.w3.org/TR/its20/

For some kind of validation, more powerful than a regex pattern.
It is designed exactly for this...

---

And might have more than one rule for a field?
Do we want 2 fields, for example validated (instead of pattern) and validationRules that contain several regexp + ITS 2?

[eemeli]

Given that we already have the values and pattern attributes on <option>, what is the benefit and meaning of the corresponding values of the proposed l10nAccess attribute?

In other words, how would

<option name="key" values="one two three" l10nAccess="values">

differ from

<option name="key" values="one two three" readonly="false">

?

Regarding l10nAccess="hidden", could you give an example of a usage case? My own presumption would be that we should not be encouraging any content within messages that would not be even shown to translators.

[aphillips]

What's the status of this discussion? Is this resolved?

[aphillips]

This is out of scope for 45. Will consider in 46.