Skip to content

systemLanguage is not clear about case-insensitive matches #517

Closed

Description

Image for: Description

Document structure chapter
Switch and systemLanguage
https://svgwg.org/svg2-draft/struct.html#SwitchElement

The systemLanguage attribute is a comma-separated list of BCP 47 langtags.

The SVG 2.0 spec states the systemLanguage attribute:

Evaluates to "true" if one of the languages indicated by user preferences exactly equals one of the languages given in the value of this parameter, or if one of the languages indicated by user preferences exactly equals a prefix of one of the languages given in the value of this parameter such that the first tag character following the prefix is "-".

The phrase "exactly equals" has misled many implementers. It would be better to state explicitly that the comparison is a case-insensitive match. For example, the langtag "en-US" is equivalent to "en-us". To most readers, it is not "exactly equals" but is "equivalent". Saying it is a case-insensitive match would just make it clear.

Clarity is an issue. Chrome and Firefox browsers currently use case-sensitive matches for systemLanguage. Consequently, systemLanguage="EN" evaluates to false but systemLanguage="en" evaluates to true on those browsers.

BCP 47 (https://tools.ietf.org/html/bcp47) implies that the case of the langtag does not matter when doing some operations, but doesn't actually make a clear statement that case does not matter for any comparison. You can search through the RFCs and find mention that case does not matter in some situations, but I did not find the broad statement.

Search the BCP 47 document for "insensitive" to find statements such as

At all times, language tags and their subtags, including private use and extensions, are to be treated as case insensitive: there exist conventions for the capitalization of some of the subtags, but these MUST NOT be taken to carry meaning.

and

Language tags and thus language ranges are to be treated as case-insensitive: there exist conventions for the capitalization of some of the subtags, but these MUST NOT be taken to carry meaning. Matching of language tags to language ranges MUST be done in a case-insensitive manner.

A better statement for the SVG specification would be (also using "language tag" instead of "language"):

Evaluates to "true" if one of the language tags indicated by user preferences is a case-insensitive match to one of the language tags given in the value of this parameter, or if one of the language tags indicated by user preferences is a case-insensitive prefix of one of the languages given in the value of this parameter such that the first tag character following the prefix is "-".

Interestingly, BCP 47 (RFC 4647 section 3) states

Protocols and specifications requiring conformance to this specification MUST clearly indicate the particular mechanism used in selecting or matching language tags.

SVG is a specification, but it has not clearly indicated the mechanism used in matching langtags. SVG 1.1 uses 3.3.1 Basic Filtering; there's a match if the basic filtered set is not empty. The SMIL allowReorder semantics are more complicated (and even ambiguous).

Metadata

Image for: Metadata

Metadata

Image for: Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions

    Image for: Issue actions