Jump to content

英文维基 | 中文维基 | 日文维基 | 草榴社区

Wikipedia:Standardize spellings

From Wikipedia, the free encyclopedia

I've created my final proposal on the subject, Wikipedia:Spelling Standardization Improvement Drive which would serve only to make current policy more efficient. Juppiter 15:05, 26 August 2005 (UTC)[reply]

See also Wikipedia:Standardize spellings/Archive for an earlier proposal that was rejected by the community.

I understand the practical reason why Wikipedia is neutral wrt British vs American spellings (i.e. getting a large number of chauvinistic people who are divided into two camps to agree is difficult), but it is getting a little out of hand when articles are randomly titled "color" or "honour"; or "palatalization" and "velarization", but "labialisation" and "pharyngealisation" (the latter four are four closely related linguistics topics). There is no guarantee that redirects from the other spelling(s) will necessarily exist, and hence searches may come up wrong, with no possible way for the searcher to know in advance other than guessing. (For example, a search for "rhotacization" brings up the R-colored vowel page; a search for "rhotacisation" comes up empty.)

I am aware that there was a recent, more general, proposal to standardise spelling that was turned down, but I think that the case of article titles is particularly important, since searches are primarily done based on titles. Can we really guarantee that all the proper redirects will be inserted? As I just showed above, there are cases (probably lots) where not all such redirects are present, and I don't see any general attempt to add the necessary redirects every time a new article is created. (Note that with the current "agnostic" policy, such redirects are imperative, whereas with a consistent policy this would not so obviously be the case, as it would be more generally known how to spell titles for proper search.)

ADDED: The problem of duplicate entries under different titles. This is another issue that will come up in the absence of standardisation.

ADDED: The problem of not knowing which spelling to use when creating an article links, which can easily lead to broken links due to incomplete redirects. I ran into this many times w.r.t. to incorrect use of case in article title links, until I figured out the standard. See below.

BTW I doubt that a one-time effort to appropriately change the 600,000 titles would be impossibly difficult.

Note that I am not proposing which spelling to adopt; what matters is consistency. (How many other organisations in the information-production business can you name that encourage, much less tolerate, naming inconsistencies?)

As an alternative, we need to ensure that appropriate redirects go in for every page with potential spelling problems; currently this is not happening. I also hope some effort goes into making the obvious changes to the Wikipedia search engine, so that searches for e.g. "localization" and "localisation" don´t produce radically different results, as they do currently. (BTW I would hope that at least as much effort will go into fixing the redirect and search problems as currently goes into ridiculing people for trying to address the problems created by spelling inconsistency.)

Benwing 03:39, 26 July 2005 (UTC)[reply]

We already have a guideline saying that redirects should be created - but we can't force people to make them (or remember to make them, or even to realise to make them). I recommend that when you see a missing redirect, you create it, jguk 05:58, 26 July 2005 (UTC)[reply]
We either need to adopt standardised spellings or we need to ensure that appropriate other-spelling redirects automatically get created within a certain time (e.g. 6 hours) of the creation of a page with a word with spelling variants. This is my proposal; it is not about "forcing" people to do it, or about asking *me* to fix things as I notice them. It's a more systemic problem.
For comparison: We *do* have standards wrt punctuation (e.g. capitalise only the words of a title that need to be capitalised, rather than use Title Case, like many would naturally do at first), and we *do* have a standard that says "name all articles about a language FOO "FOO language". In both cases, having a standard avoids the numerous problems listed above. In the case of article capitalisation, the adoption of a standard means that only the most common articles have redirects to handle the use of Title Case; with an inconsistent policy, *every one* would require this, which consequent massive increase in Wikipedia editor effort, esp. given the lack of any automated robot-style tools to do this.

Benwing 10:43, 26 July 2005 (UTC)[reply]

Here's a similar gotcha. There is a link from "federal offence" to "federal crime" even though this is primarily a US-specific page. However, there is no link from "federal offense" (US spelling) to "federal crime", and Wikipedia search on "federal offense" doesn't find the correct "federal crime" at all; it's not in the top 20, at least. there must be hundreds or thousands of such problems, and they cannot be fixed by a policy of haphazardness. Benwing 11:05, 26 July 2005 (UTC)[reply]

We could ask those who patrol "New pages" to look out for such instances and create redirects as appropriate, and you can always look on "what links here" if you think a page should have a redirect to it and add it if it's missing, but I'm not sure what else we can do that's practical and that will be accepted, jguk 12:25, 26 July 2005 (UTC)[reply]

I agree with Jguk, there's no way to enforce standardization of names and no way to ensure all possible redirects will be created, and the best thing to do when you notice a missing redirect is to make it yourself. When I created r-colored vowel I tried to think of all possible variant spellings to redirect from; I did make a redirect from r-coloured vowel, for example, but I forgot rhotacisation. I've just now made a redirect from rhotacisation and rhoticisation to r-colored vowel as well as one from federal offense to federal crime. --Angr/tɔk mi 05:31, 27 July 2005 (UTC)[reply]