Talk:Z14326
Case-sensitivity
See Z30680/Z30681/Z30682.
Wikimedia subdomains are necessarily all-lowercase, which I'm guessing is why Wikidata uses all-lowercase, and that was then copied for persistent Z60s here on Wikifunctions.
But per that third test the canonical form is e.g. sux-Latn, en-US, and these should be considered equivalent to their all-lowercase counterparts.
From the spec:
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.
[...] The format of subtags in the registry [which follows ISO standards 639-1, 3166-1, and 15924] is RECOMMENDED as the form to use in language tags.
So my question is: Are the elements of Z60s semantically IETF language tags or Wikimedia/Wikidata language identifiers?
Validate natural language (Z160) doesn't seem to inspect Z60K1 at all. YoshiRulz (talk) 02:16, 19 December 2025 (UTC)
- All Validator functions currently fail and mostly never did anything anyway.
- The structure of language tags in persistent Z60s appears to be strictly lowercase. For practical purposes, it is simpler to treat any string purporting to represent a language tag as lowercase since, outside of code, case-insensitive comparison and normalisation are relatively expensive compared to a simple call to string equality (Z866), which is case sensitive.
- This function stipulates “identical” tags, so implementations inherit that behaviour unless they explicitly normalise both tags before calling it. GrounderUK (talk) 15:17, 27 March 2026 (UTC)
Are the elements of Z60s semantically IETF language tags or Wikimedia/Wikidata language identifiers?
- Neither, but closer to the former than the latter. They exist distinctly from Wikimedia/Wikidata language identifiers almost entirely so that the Abstract Wikipedia / Wikifunctions communities can choose to support languages, dialects, and variants to an arbitrary level without needing the rest of the Wikimedia movement to agree that this is a language they wish to support (e.g. en-IN, or de-AT, or as has been suggested something like en-US-x-Grade5).
- Note that we don't actively normalise Z60K1 values (or Z60K2 ones, for that matter) on the back-end when evaluating requests. We could do so, but every additional line of code in hot paths like that would need consideration. It is indeed safest to assume that we should always use lowercase. Jdforrester (WMF) (talk) 18:21, 27 March 2026 (UTC)
- (Apologies for the late response, I must have accidentally unsubscribed from this thread.) If this is case-sensitive for performance reasons, does it follow that mixed-case values should be downcased ASAP before ending up in a Z60, and that hardcoded values should be all-lowercase? YoshiRulz (talk) 18:51, 6 April 2026 (UTC)
- @YoshiRulz: That's probably a good choice, yes. Jdforrester (WMF) (talk) 20:56, 6 April 2026 (UTC)
- (Apologies for the late response, I must have accidentally unsubscribed from this thread.) If this is case-sensitive for performance reasons, does it follow that mixed-case values should be downcased ASAP before ending up in a Z60, and that hardcoded values should be all-lowercase? YoshiRulz (talk) 18:51, 6 April 2026 (UTC)