[css-highlight-api] i18n self review #5771
Description
Short i18n review checklist is here
-
If the spec (or its implementation) contains any natural language text that will be read by a human (this includes error messages or other UI text, JSON strings, etc, etc),
It does not.
-
If the spec (or its implementation) allows content authors to produce typographically appealing text, either in its own right, or in association with graphics.
It does not introduce any new typographical capabilities. It does allow applying a restricted subset of CSS's usual features to arbitrary ranges within the document. No i18n related issue is though to arise from that, and in any case, this merely builds up on built-in highlight pseudos as found in https://drafts.csswg.org/css-pseudo-4/#highlight-pseudos. Should there be any issue (and I don't think there is), they likely stem from that underlying technology rather than from this extension of it.
-
If the spec (or its implementation) allows the user to point into text, creates text fragments, concatenates text, allows the user to select or step through text (using a cursor or other methods), etc.
It does not.
However, it allows the author to do point to text fragments. It uses the pre-existing Range object from the DOM specification for that. Authors should be careful when doing so to avoid accidentally putting fragment boundaries in the middle of grapheme clusters. The Range object allows for that, but admittedly does not facilitate it. If it would be deemed useful to give authors advice about careful usage of the Range object to avoid getting into difficult i18n situations, it would seem more appropriate to include that advice in the upstream DOM specification.
-
If the spec (or its implementation) allows searching or matching of text, including syntax and identifiers
It does not.
-
If the spec (or its implementation) sorts text
It does not.
-
If the spec (or its implementation) captures user input
It does not.
-
If the spec (or its implementation) deals with time in any way that will be read by humans and/or crosses time zone boundaries
It does not.
-
If the spec (or its implementation) allows any character encoding other than UTF-8.
It does not.
-
If the spec (or its implementation) defines markup.
It does not.
-
If the spec (or its implementation) deals with names, addresses, time & date formats, etc
It does not.
-
If the spec (or its implementation) describes a format or data that is likely to need localization.
It does not.
-
If the spec (or its implementation) makes any reference to or relies on any cultural norms
It does not.