Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Informal spellings in specifications #5850

Closed
SebastianZ opened this issue Jan 10, 2021 · 8 comments
Closed

Informal spellings in specifications #5850

SebastianZ opened this issue Jan 10, 2021 · 8 comments
Labels
a11y-tracker Group bringing to attention of a11y, or tracked by the a11y Group but not needing response. i18n-tracker Group bringing to attention of Internationalization, or tracked by i18n but not needing response. meta

Comments

@SebastianZ
Copy link
Contributor

SebastianZ commented Jan 10, 2021

For some time now informal spellings for commonly used words made it into the specifications. Some examples are "thru", "thruout", and "tho". Examples for specifications using them are CSS Environment Variables 1, CSS Syntax 3, and CSS Images 4.

As a non-native English speaker who learned English at school, it initially took me a moment to understand what those words actually mean. And my personal thought is that technical specifications, and especially those read by a global audience, should strictly keep to a formal language. As I know that @tabatkins is an advocate of this informal spelling, I already wrote him privately about this some time ago.

His answer back then was:

"Thru" (and "tho") is a perfectly cromulent spelling. it's considered
informal at this point, but it's been strongly advocated by spelling
reformers in the past, and is specifically used in some technical
journal-ese. It's not prone to non-native misunderstanding; if you
look up "thru" or "tho" it immediately comes up as a spelling variant
of "through"/"though". At worst people might misread it as a spelling
variant of "threw", but that's nonsensical in context and thus not
worth worrying about.

While informal, it's definitely "correct" English, just a spelling
you're not used to. But I feel strongly that the "silent gh" needs to
die in English, and no longer spell words with it when I can help it.

Though today I saw @dholbert's patch for fixing "typos" in CSS Images 4 changing "tho" to "though".

Therefore I thought (or as Tab would probably spell it, "thot" 😉), I'd bring this up to a broader audience.

Should it be allowed or even be encouraged to use colloquial or informal spellings and words in specifications?

Sebastian

@plinss
Copy link
Member

plinss commented Jan 10, 2021

FWIW the TAG has a writing style guide: https://github.com/w3ctag/process/blob/master/style-guide.md *

It's (currently) silent on the subject of neologisms (however cromulent they may be), but keeping in the spirit, the question should be "does this word make the document easier to understand or harder?" I accept the informal spellings make the document easier to write, but that's not what we should be optimizing for.

I'd like to hear from more non-native English speakers on this topic.

Also, pinging @alice for her input (the author of the TAG style guide).

  • Note that at this point the guide is directed towards the TAG, and is not meant to be an authoritative style guide for all of W3C, it might be a good foundation for one tho...

@rachelandrew
Copy link
Contributor

With my "editor of technical material written for a global audience" hat on, I'd suggest to avoid these spellings. They are unlikely to be the English people have learned, and specs are hard enough to understand as it is.

I am not a fan of the idea that people could search to find out what they meant. If there is a word that people are likely to understand and not need to search for the meaning of, it makes more sense to use that word. Formal usage is more likely to be globally understood. Things do change, it used to be that contractions were said to be bad practice, but - as in the TAG guide - more style guides encourage the most common contractions. So if there is actual data on these words being better, that's a discussion to have. I think it would be good if we are consistent however.

As far as style guides for technical content go, the Microsoft Style Guide is very good https://docs.microsoft.com/en-us/style-guide/welcome/ but I don't think I have seen anything in there that addresses this particular issue.

@alice
Copy link

alice commented Jan 10, 2021

I can only second everything @rachelandrew said, and agree with @plinss that we should be aiming for readability.

The advice on contractions is based on advice from professional copy-editors that they improve readability, e.g. https://stroppyeditor.wordpress.com/2015/10/12/contractions-which-are-common-and-which-arent/ (which is also linked in the style guide), and backed up by anecdotal reports from speakers of English as a second language.

It would be good to find analogous evidence for or against non-standard spelling; the fact that @SebastianZ filed this issue is a strong start in the "against" direction.

My personal opinion is that a technical spec isn't the place to try and move the needle on not-yet-standardard spellings like those mentioned above: specs are tough enough to read already, without added speed bumps from non-standard spelling.

As @plinss noted, we don't have any advice for spec language currently, and creating a style guide for specs would be a big project. However, honestly I think we probably only need to convince one or possibly two people to change practices in this specific instance.

Edit: The Microsoft style guide @rachelandrew linked is very good, and reminded me that another potential issue with non-standard spellings (particularly something like "thruout") is that TTS (text-to-speech) engines may struggle with them.

@frivoal
Copy link
Collaborator

frivoal commented Jan 11, 2021

I'm not opposed to linguistic activism in general, but I think specifications are a poor place to do it. As a non native speaker of English, who is nonetheless reasonably fluent, I'd like to mention the effect this sort of things has had on me: broadly speaking I have not faced particular difficulties understanding documents that used informal language (including unusual spellings, colloquialisms, in-jokes, jargon, etc). However, since reading W3C specifications represent a significant percentage of my exposure to English, in the absence of contradicting information, I tend to assume that whatever is common in such documents is "normal written English". Occasionally though, something I learned there is not (yet?) accepted as mainstream or formal English, and when I later reuse these words in other contexts, it can lead to people being surprised or even confused at the language I use.

To some degree, this achieves Tab's goal: if people start to use these spellings after seeing them, they spread, which is what he wants. But spreading them through people for who English is a second (or third, or…) language isn't at no cost to those people if it occasionally causes additional communication difficulties or social faux pas.

@svgeesus
Copy link
Contributor

But I feel strongly that the "silent gh" needs to
die in English, and no longer spell words with it when I can help it.

CSS specifications are an unsuitable venue to promote possible future spelling reforms.

since reading W3C specifications represent a significant percentage of my exposure to English, in the absence of contradicting information, I tend to assume that whatever is common in such documents is "normal written English"

Yes, that is the normalizing, language activism part.

a technical spec isn't the place to try and move the needle on not-yet-standardard spellings

I agree. If the intent is to build up a body of published work which can then be pointed to as evidence of usage, this can be easily accomplished by personal blogs and the like.

@svgeesus svgeesus added a11y-tracker Group bringing to attention of a11y, or tracked by the a11y Group but not needing response. i18n-tracker Group bringing to attention of Internationalization, or tracked by i18n but not needing response. meta labels Jan 11, 2021
@css-meeting-bot
Copy link
Member

css-meeting-bot commented Jun 3, 2021

The CSS Working Group just discussed Informal spellings in specifications, and agreed to the following:

  • RESOLVED: We consider informal spellings to be typos to be fixed when found and avoided if possible
The full IRC log of that discussion <dael> Topic: Informal spellings in specifications
<dael> github: https://github.com//issues/5850
<TabAtkins> i write all nite tho
<dael> florian: Keeps coming up and never had cnetral discussion. Mostly manifests in TabAtkins using spellins he believes is appropiate but many don't recognize.
<dael> florian: Double question. Are they appropriate and, given they're not recognized, as should specs stick with mainstream?
<dael> florian: I suspect would liek spec to stick to mainstream
<TabAtkins> q+ re my "goals"
<dael> florian: As a non-native speaker I didn't find them confusing but given my exposure to standards is a large part of how I learn English what I see in specs I assume to be normal. I think it's unpleasent for non-native speakers to assume thigns are mainstream when they are not.
<iank_> fwiw "thru" is very common in australian english
<astearns> ack TabAtkins
<Zakim> TabAtkins, you wanted to discuss my "goals"
<dael> florian: When you're a non-native speaker people look at you weird and think you don't speak properly. Probably not the goal of this, but a risk
<dael> TabAtkins: There has been speculation as to waht my goals are. I don't have any and that's how I write. It's not easy for me to train my fingers. Happy if people want to run spell check. We don't do it in general.
<dael> TabAtkins: This is just how my fingers spell the words. It was intentional on my part, but not a drive on my part ot make changes to English.
<dael> astearns: So you say TabAtkins you are fine with corrections. If people point out descrepencies will you make edits?
<dael> TabAtkins: I suspect if I say yes someone will go through and tell me to make changes and I'd rather they put in a PR
<iank_> q+
<dael> astearns: Oh yes. But I think I have seen I have this PR, please give review, and some comments are a misspell, I would appriciate if you made those changes
<dael> TabAtkins: Sure. It's fine.
<astearns> ack iank_
<dael> iank_: I wanted to quickly say I somewhat worry if we have a hard and fast rule about the type of English will be a barrier for people writing spec. Specifically non-US-English speakers
<dael> TabAtkins: There is a W3C rule that we write in Amreican English, but that's the whole rule
<smfr> q+
<dael> astearns: Fine for spec writers to use the skills they have and if a typo is pointed out we can fix
<astearns> ack smfr
<dael> fantasai: Should make an effort not to make typos
<dael> smfr: I think we spec undergo transition is a good time to do editorial pass and make sure spec is generally American English. Just like a privacy and security review
<dael> astearns: Makes sense
<dael> fantasai: Sounds like converging that non-standard spellins are typos and should be handled as such
<dael> astearns: Yep
<dael> florian: Works for me. Wanted to avoid having the discussion 23 times and do it once centrally
<dael> astearns: Prop: We consider informal spellins to be typos to be fixed when found and avoided if possible
<TabAtkins> fwiw: https://www.merriam-webster.com/dictionary/tho
<dael> RESOLVED: We consider informal spellins to be typos to be fixed when found and avoided if possible

@fantasai
Copy link
Collaborator

fantasai commented Jun 3, 2021

Thanks for raising the issue @SebastianZ :) I think we had a good discussion.

@SebastianZ
Copy link
Contributor Author

Thank you all for clarifying this! I guess there's nothing left to say, so I close this issue now.

Sebastian

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
a11y-tracker Group bringing to attention of a11y, or tracked by the a11y Group but not needing response. i18n-tracker Group bringing to attention of Internationalization, or tracked by i18n but not needing response. meta
Projects
None yet
Development

No branches or pull requests

8 participants