Closed csarven closed 4 months ago
annevk
commented
4 months ago Because we want color and not colour, for instance. It might be useful to maintain a dictionary as there is certainly ambiguity even within that narrowing. E.g., for WHATWG we have https://whatwg.org/style-guide.
csarven
commented
4 months ago I think a principle would have more to do with advising on consistency. So, if CSS uses US English, for instance, all new names should continue to use that as opposed to mixing other locales.
annevk
commented
4 months ago US English is the consistency we're looking for, so why not say it?
csarven
commented
4 months ago The difference is that a technical report should be internally consistent as opposed to requiring every report to be US English-centric.
That aside, as mentioned above, is there a conformance test for US English, and why not "encourage"?
annevk
commented
4 months ago The requirement is on naming in APIs, not documents. It's perfectly fine to have a "Colour API" specification describing the color() method. At least as far as these requirements are concerned.
Also, I don't think you need to have a conformance test in order to use must? (It also certainly seems testable, if anyone cared enough.)
cynthia
commented
4 months ago @annevk is spot on here. This guidance specifically was written for API naming, so that we have consistent spelling across APIs. The US English guidance was a conscious tradeoff for pragmatic reasons - the majority of terms in API naming are already US English, and writing "consistent" would require painfully combing through past names for the reader.
I don't think there is anything to change here, but will leave the call up to current TAG to decide.
On conformance: this is not a normative document, you can choose to ignore it.
csarven
commented
4 months ago Thanks. Ack "tradeoff for pragmatic reasons", and so it can be left at that.
While the document does not constrain the use of keywords like "must" which are RFC requirement level terms that are commonly used in technical reports, I'd encourage the editors to consider using different terms, e.g., "strongly encouraged", where applicable.
cynthia
commented
4 months ago @LeaVerou in case you want to make the editorial suggestion above (I don't feel too strongly either way)
riannella
commented
4 months ago Ironically it says "Keep in mind that most web developers aren’t native English speakers" after mandating the use of "US English" ! It would be better (as the first W in W3C is "world") if the principle was around supporting multiple language "labels" for fixed character names used in APIs.
LeaVerou
commented
4 months ago By that reasoning, why mandate English at all? Agreed with @annevk and @cynthia that consistency is more important than political correctness here and the ship has sailed about which dialect of English or which language would be most consistent. We do have a separate principle on consistency, but happy to merge a PR that explains the rationale for US English better.
riannella
commented
4 months ago Agree. Don't mandate any Language. BTW, calling this "political correctness" does not improve the conversation.
https://w3ctag.github.io/design-principles/#naming-common-words states:
Why must on "US English" as opposed to just "English"?
Is there a design-principles conformance test for "must [..] US English"?
Or should this be an advisement rather than a requirement, and so the "must" should be changed to "strongly encouraged" (e.g., non-normative term from INFRA Conformance).
On a related note, the Internationalization Best Practices for Spec Developers does not make any recommendation for "US English".
FWIW, even the HTML source of https://w3ctag.github.io/design-principles/ uses just
en, e.g.,<html lang="en">.