Issues with systemLanguage condition
From a mail:
there's been a long-standing bug with systemLanguage, and you've recently edited the file or the source tree.
librsvg has its systemLanguage processing backward from the SVG specification; it does not do the language matching correctly.
if the user preference is "zh-Hans", then the second (and not the first clause) should be chosen:
The SVG language matching rule is described at https://www.w3.org/TR/SVG/struct.html#ConditionalProcessingSystemLanguageAttribute
which states the test
Evaluates to "true" if one of the languages indicated by user preferences exactly equals one of the languages given in the value of [the systemLanguage attribute], or if one of the languages indicated by user preferences exactly equals a prefix of one of the languages given in the value of [the systemLanguage attribute] such that the first tag character following the prefix is "-".
That means "zh-Hans" does not match "zh-Hant-TW". That means "zh-Hans" does match "zh-Hans-CN".
In particular, the user's langtag must be a substring of a systemLanguage.
that bug continues in cond.rs lines 86 to 92:
https://gitlab.gnome.org/GNOME/librsvg/blob/master/rsvg_internals/src/cond.rs
if sl.eq_ignore_ascii_case(l) { return true; } if let Some(offset) = l.find('-') { return sl.eq_ignore_ascii_case(&l[..offset]); }
Note that this code trims the user agent's language (l) rather than the system language sl.
Consequently, "zh-Hans" will match "zh-Hant-TW" because "zh" == "zh"; that is not the desired test.
The simple test is to just follow the words of the standard. The first if statement above is correct. The second if should be if the length of l is less than the length of sl, and all of l matches the start of sl and the next character of sl is a hyphen then return true.
Other issues:
cond.rs line 147 is incorrect because "en_US" is not an IETF language tag and should NEVER appear in an SVG file's systemLanguage attribute. "en-US" is the proper IETF language tag. (The code confuses "en_US", which is a Unix locale string rather than an IETF langtag.)
cond.rs line 165-166 should be a fail or use the correct IETF langtag "en-US"
cond.rs line 175-176 should be a fail. If the user demands content in "de-LU" (German as spoken in Luxembourg), then that demand is not satisfied by ordinary German. The user's langtag "de-LU" must be a prefix of a langtag in the systemLanguage list; "de" is not long enough.
there should be a unit test that "en" matches system_languages ("en" matches "en-US"). (A user specifying generic English ("en") does not care if he gets "en-US", "en-GB", or just "en".
for additional tests, add the string "zh-Hans-CN" to system_languages there should be a unit test that "zh-Hant" does not match system_languages there should be a unit test that "zh-Hans" matches system_languages there should be a unit test that "zhs" does not match system_languages there should be a unit test taht "z-US" does not match system_languages