Wikipedia talk:Naming conventions (technical restrictions)/Archive 1

Archive 1

/.

trying to make the page "/." a reidrect to slashdot but cannot get the page to create, any ideas? —Preceding unsigned comment added by MisterUser (talk • contribs) 20:42, 28 November 2008 (UTC)

Special Characters (ñ)

Moved from Wikipedia:Village pump on Saturday, August 2nd, 02003.

I want to add an entry that contains a Spanish "enye" character - Buñol - should the entry/filename be:

• Bun~ol
• Buñol
• Bu + whatever hex unicode thing it takes + ol
• Bunyol (English phonetic)
• Bunol (just pretend the tilde isn't there)

???

AHands 11:58 25 Jul 2003 (UTC)

The usual practice I've seen is to use the unaccended (for example, Vasco Nunez de Balboa), so Bunol should probably be the article title. Of course, you can use the special characters within the article itself; it may also be good to redirect Buñol to Bunol, to aid in searching and whatnot. -- Wapcaplet 13:39 25 Jul 2003 (UTC)

Hello, AHands. According to Wikipedia:Naming conventions (use English), you should "Name your pages in English and place the native transliteration on the first line of the article unless the native form is more commonly used in English than the anglicized form." So for example the article about Christopher Columbus is there rather than at Cristóbal Colón (an alternative form of his name, which a certain rather controversial Wikipedian once recommended), because he is more commonly known as "Christopher Columbus" in English. However, if there is no well-known English-language form of a name, the native form should be used. Wikipedia:Naming conventions (use English) says that "Languages like Spanish or French should need no transliteration". The system we have allows Spanish characters like "ñ" to be used, so you can use them. If a name is always spelt with "ñ" rather than "n", then I think we should use the right character in the title for accuracy. But the form with an "n" should be made a redirect, so that we don't accidentally end up with a duplicate article at the alternative title. -- Oliver P. 16:11 25 Jul 2003 (UTC)

Which characters are excluded?

Why is ? listed? O Brother, Where Art Thou? works fine. Tuf-Kat 18:20, Dec 19, 2003 (UTC)

And what about "=" ?
=/Kx'au//'ein language works. --Henrygb 18:41, 19 Aug 2004 (UTC)

Is this list correct? Are "*" and "$" permissible characters? Can M A S H be moved to M*A*S*H and Deal dollar store be moved to Deal$? - SimonP 22:09, Aug 20, 2004 (UTC)

The characters =?$* all seem permissible in page titles. So I moved the article on M*A*S*H to M*A*S*H (movie), and so on. Gdr 21:08, 2004 Aug 23 (UTC)

As of MediaWiki 1.3.1, it looks like the following characters are allowed in titles:

%!"$&'()*,-./:;=?@\^_`{}~

as well as A-Z, a-z, 0-9, the space character (0x20), and ISO 8859-1 characters 0x80-0xFF. Wmahan. 21:21, 2004 Aug 26 (UTC)

Whoa there. You can't have _ in a title. [[_]] doesn't wikify, and [1] gives an error, so we definitely can't start with an _. Any underscores in titles are mapped to spaces, so it's inaccurate to say that underscores are really allowed. grendel|khan 08:04, 2005 Feb 27 (UTC)

Material moved here from Wikipedia:List of pages whose correct title is not allowed by MediaWiki

I made Wikipedia:List of pages whose correct title is not allowed by MediaWiki into a redirect to Wikipedia:Naming conventions (technical restrictions) since the Special:Whatlinkshere/Template:Wrongtitle is more managable than a list of pages. However, a few categories of pages perhaps deserve to be listed somewhere, so here they are. (This is really a "todo" list for when MediaWiki fixes the problems with page titles.) Gdr 21:06, 2004 Aug 23 (UTC)

Redirects with not-allowed characters

• Gulf and Western Industries should at least have a redirect at "Gulf+Western"
• Slashdot - /.

Articles which cannot be linked to

• //Gana language
• /Anda language
• /Gwi language
• /Xam language
• //Xegwi language

Computer command-line programs

Most of these are not misnamed. The executable file may be named "bash", but the program is called "Bash", so the article is fine. And so on for most of the rest. So please don't go through this list marking them all with {{wrongtitle}}. Gdr 21:06, 2004 Aug 23 (UTC)

Not entirely so. Bash is uppercased, but check out the GNU coreutils FAQ. Commands are referred to by their lowercased names; larger software packages (Bash, Emacs) are usually capitalized, presumably because one is talking about something larger than just a one-off command. (There are exceptions, however---vi is always lowercase-v, lowercase-i.) So it's really sorta complicated, and has to be done on a case-by-case basis. grendel|khan 08:16, 2005 Feb 27 (UTC)

• bash
• bzip2
• cat (Unix)
• cd (DOS / Unix Command)
• cfdisk
• chmod
• cls
• comm (Unix)
• dir (DOS Command)
• fdisk
• grep
• ircII
• irssi
• ls
• mkdir
• more
• pwd
• rm (Unix)
• su (computing)
• tcsh
• uniq
• vdiff
• vi
• wget
• w3m

Pages beginning with slashes

Hi, I noticed that people use external links to refer to articles beginning with a slash, since it is not possible to make wikilinks to such articles. I think this is harmful because it reduces the usefulness of the What links here facility, arguably violates Wikipedia:Avoid self-references, and may make such links display in a different color from wikilinks.

Now that subpages are no longer used in the main article space, is there any reason to disallow linking to pages beginning with a slash? In other words, is there any remaining need to treat a link like [[2]] differently from a link without a slash? Wmahan. 23:13, 2004 Sep 4 (UTC)

Subpages are often used in other namespaces, so I think "/" has to remain a special character. However, you can trick the parser by using / instead of a slash. For example, link to [[//Gana language]], like this: [language]. (Some characters are so special that even cheating like this doesn't work, but "/" is not among them.) You can avoid self-references by using {{SERVER}}{{localurl://Gana language}} (which comes out like this: //en.wiki.x.io/wiki///Gana_language ) instead of directly using http://en.wiki.x.io/wiki///Gana_language. —AlanBarrett 17:17, 5 Sep 2004 (UTC)

Neat trick! Now the "What links here" page for //Gana language links here. :) It seems that we could change the pages that use external links to instead use HTML entities as you suggest.

Still, I wonder if it would be more user-friendly to change the parser to not handle slashes specially in the namespaces where subpages are disabled. Maybe I'll look at the code and see if such a change would be feasible. Thanks! Wmahan. 18:42, 2004 Sep 5 (UTC)

Fixing the problem

Just off the top of my head, it seems like there should be some way to make these titles work. Map the bad characters into good ones, somehow. For example, __pound__ (double underscores) in the URL would become # in the title. The search mechanism would have to be able to handle the special characters, too.

Has anyone looked at doing this? Are there obstacles I'm missing Tualha 00:55, 10 Sep 2004 (UTC)

There is already an escape mechanish that often works. Use SGML entities to refer to the problematic characters by their numeric codes; for example, # refers #. I think that it would be easier to fix the bugs in this system (which works for most but not quite all characters) than to design a new system. —AlanBarrett 08:40, 12 Sep 2004 (UTC)

I wouldn't think that would work for # - if "#" were written literally into the HTML like others are it would still mark a fragment ID in the URI and the browser would not send it. The URI coding %23 would have to be used. But right now neither works: [[%23]] becomes # and [[#]] becomes #, both with null titles. This is a wikicode-to-HTML problem. But http://en.wiki.x.io/wiki/%23 doesn't work either; this is a problem translating HTTP path to title. It's not okay to simply encode # in all forms since WP uses fragment IDs (eg Wikipedia:Naming conventions#Music).

[[%3F]] and [[?]] both have the "right" thing happen just now (? ?).

Brackets, being URI neutral, could be coded with entities: but neither entity [[[]] [[]]] nor URI [[%5B]] [[%5D]] codings are even recognised as links right now ([[[]] [[]]] [[%5B]] [[%5D]]).

The handling of coded / eg [[a%2Fb]] (a/b) is pretty hosed. And some browsers do the wrong thing anyway (eg http://en.wiki.x.io/wiki/a%2Fb is presented properly by WP but mangled in Konqueror), so / may not even be worth fixing. Kwantus 23:18, 2005 Jan 2 (UTC)

Why don't we just use an Escape character?--Terrible Tim 19:46, 6 Jan 2005 (UTC)

Why not just parse the wrongtitle tag at view-time, and modify the title displayed to match the one given in the wrongtitle template? The reader doesn't care what the page is actually named, as long as he sees the correct title. For ease of linking, it might be worth adding a little bit at the bottom, giving the real name of the page.

• I like this idea. I just randomly came across this problem twice in successive articles, for Krzysztof Kieslowski and iRiver, and no matter how good the content in those articles is, it surely creates an air of doubt/amateurishness when the very first line of the article is an apology for it not working properly. Fosse8 03:51, 3 Jun 2005 (UTC)

Namespaces

I wonder if it would be possible to clarify exactly how "problematic" it would be for names to coincide with namespaces. Is it merely confusing, or is it actually broken? Terry 21:03, 29 Sep 2004 (UTC)

I think theoretically, they should be entirely impossible: barring bugs, an article seemingly called "Wikipedia:Foo" will actually be an article called "Foo" in the Project ("Wikipedia:") namespace. What's problematic, I guess, is that Wikipedia:Foo is a perfectly valid link, giving the illusion that the article could exist. - IMSoP 18:23, 7 Oct 2004 (UTC)

It's only problematic when a new namespace is added and pages with conflicting names already exists. This is generally a problem on new wikis where the namespace names are not yet localized at the time the wiki is created; some people jump the gun and create pages that look like they would be in a localized namespace, and then ask to have the namespace names actually localized. They can be cleaned up in the database fairly easily at the time when the change is made, as long as we know to check for it. --Brion 11:37, 19 Nov 2004 (UTC)

Wiki character encoding

Perhaps it is a silly question, but I noticed that most (if not all) wikipedias out there support all the non-English diacrytes. At least that's the case with French, German, Polish and Spanish WPs. Why is English wikipedia different and will the software be ever upgraded? [[User:Halibutt|Halibutt]] 22:03, Oct 30, 2004 (UTC)

The software already supports them but the English language enycyclopedia would take so long to convert (perhaps 24 hours with the site offline) that the method used for the others is impractical. Instead the software has been modified so it can be converted gradually. It's not a great problem fortunately, since in most cases the English Wikipedia policy to use the English forms for article titles makes such characters inappropriate in the title. Jamesday 07:30, 17 Nov 2004 (UTC)

When will it be done then? [[User:Halibutt|Halibutt]] 02:11, Dec 20, 2004 (UTC)

It was done yesterday with the update to 1.5 Plugwash 28 June 2005 19:35 (UTC)

fixing the problem

is this in the wikimedia software roadmap?

Lower-case first letters - tech limitation or not?

From the Ebay page: The title given to this article is incorrect due to technical limitations. The correct title is eBay.

But from the Wikipedia: Naming conventions page, the section mentioning that "the English language encyclopedia is set not to accept a lowercase character as the first letter of a page title." says: This is a policy choice, not a technical limitation.

Aren't the two italicised statements contradictory? Loganberry 00:50, 19 Nov 2004 (UTC)

The claim that it's a "policy choice, not a technical limitation" is absolutely false. I've replaced it with an explanation. The author of the statement was probably confused by the existence of a configuration option which has been put into place on many of the Wiktionary sites and a couple of obscure-language Wikipedias to allow lowercase letters as the first character of a title: this option is highly disruptive and would destroy many thousands of links on a wiki like this Wikipedia, where many titles are common words and are linked both at the beginning of sentences, and in the middle, and where many links from the outside are already in place. We don't currently have a configuration option that would be usable on this site. --Brion 11:31, 19 Nov 2004 (UTC)

But Wiktionary currently has an automatic redirect from every nonexistent capitalized page to the corresponding uncapitalized one. Linking to Dog produces the same result as linking to dog (but Cat is different from cat, as one is a nickname for Catherine and the other is a furry meowing thing). They also appeared to transfer all existing links fine in the software upgrade. —Simetrical (talk) 16:58, 4 August 2005 (UTC)

Whilst things are just about ok on enwikitionary now there was huge disruption over on en wikitionary. someone turned on that option without understanding (last i heared none of the developers admitted to actually doing it). brion then ran a server side script which moved articles to a lower case first letter and put redirects in (this took some time). This improved the situation considerablly but also lead to a lot of double and triple redirects to be cleaned up by hand. There is also the question of if we wan't to disabiguate articles by case alone, i can't say its an idea i like myself especially as many (possibly most) wikipedia articles are terms that are seen both capitalised and uncapitalised having a case sensitive first letter would double the number of redirects we had to maintain. Plugwash 12:14, 5 August 2005 (UTC)

Does the root of all this stem from *nix's file case sensitivity? I though that Apache could deal with this transparently? It may seem like small thing, but I really think that this should be fixed. Not only do the "The title of this article begins with a capital letter..." look quite unprofessional, but don't all the redirects just add more strain on the servers? Soupisgoodfood 04:35, 14 November 2005 (UTC)

Ah, I see. Hope this gets changed in some future version—having articles like VBulletin instead of vBulletin is ridiculous. —Simetrical (talk) 20:52, 5 August 2005 (UTC)

Though I sympathize with the coders and the difficulty of making the change, does that invalidate the need for it? This is not unlike Slashdot's old broken HTML, and even they have finally fixed it. This is another useful technical site's major technical flaw. I'm just a user with no current ability to code, but this irritates me as someone who maintains foobar2000. -- Canar 01:57, 5 May 2006 (UTC)

To my opinion I have the following proposal: In the 'add a new article' page let the user select from three options:

• The word can be case insensitive and special characters are also not important, i.e. when a user types "united nations", United_Nations", "unIted-nAtions" it all redirects to the page "United_Nations". This saves a lot of mistypes and/or redirects.

• Spelling must be exact (case sensitive) so "iPod" and "Ipod" are not the same. Useful for such brand names or chemical formulas where e.g. "HCl" should open the hydrochloric acid page but "Hcl" not.

Furthermore, allow the user fill in redirects here (e.g. UN or U.N.) instead of creating a new page with #REDIRECT United Nations (the latter option should remail available of course.

All existing keywords can be transferred to the first option with the exception of keywords consisting of capitals only or chemiical formulas. These should be transferred to the second option. The advantage is preventing lots of mistypes and correct spelling for words starting with lowercase.

S k a t e b i k e r 08:43, 30 July 2006 (UTC)

Isn't this a language- specific issue? If I understand correctly, in English, as well as in my native Finnish, the names start with a capital letter. Thus, for example, the standard disclaimer ("The correct title of this article is easyJet. The initial letter is capitalized due to technical limitations.") is wrong. The correct title (and company name of easyJet) would be EasyJet, but they themselves have opted to use incorrect spelling for style reasons.

In my opinion, if the grammar requires that a sentence (or a name) starts with a capital letter this should override companies' marketing decisions.

Call me a perfectionist, but this limitation really pisses me off. A lot of words are supposed to have an initial lower-case letter, even in the beginning of a sentence, such as dB, chmod, iPod, etc. Also, in my opinion, every common noun should not be capitalized. I understand the problem, but I really can't see why it can't be easily solved. Fix it.

• Is this limitation still valid? Right now, I see articles as eBay and iPod without the first letter capitalized.- dariopy 18:54, 10 January 2007 (UTC)

charset issues

Should this really be added to all pages that have e.g. Latin2 characters with diacritics? I'm not really convinced that this is a good idea for terms that are always transliterated in English without diacritics, it just adds top-of-the-page spam. --Joy [shallot] 21:32, 9 Jan 2005 (UTC)

This is also discussed at Wikipedia talk:Naming conventions (use English). --Joy [shallot]

What do people think about creating a new flavor of Template:Wrongtitle, one that would look more like the Template:Shortcut in the sense that it wouldn't be placed at the top left but floating at the top right? That would make the information less intrusive but still there. --Joy [shallot] 11:26, 3 Feb 2005 (UTC)

Seeing how people persist in using the wrongtitle template for this, I've been bold and created Template:Titlelacksdiacritics. I'll replace {{wrongtitle}} with {{titlelackdiacritics}} in several articles and see how it goes. --Joy [shallot] 15:16, 19 Mar 2005 (UTC)

I've seen no real opposition to this proposal, and have been converting an increasing number of articles to use it.

One semi-anonymous user changed the template to drop the "English-language conventions" clause but provided no explanation and had no other edits, so I reverted that. Even if, in the unlikely event, one day that becomes the majority opinion, I still see the use of the differently named template as useful because it delineates these uses of wrongtitle from the ones where it's used e.g. because of the inability to lowercase the first letter of a title.

I noticed a technical problem with the new template in that it doesn't stack up well with various other 'boxes' we have in articles, and have had to kludge its inclusion in several already. A particularly egregious case was the one at Boris Tadic, where I had to {{subst:...}} it :( and drop the extra width parameter. Suggestions as to how to reimplement the template's formatting without loss of functionality are most welcome. --Joy [shallot] 23:36, 20 Mar 2005 (UTC)

There's a corner case that I don't know how to handle - the double acute being transliterated as an umlaut instead of stripping diacritics. Examples include Paul Erdös (should be Paul Erdős) and Györ (should be Győr). Does other English literature use the umlauted o's in those cases? --Joy [shallot]

Tilde

On this page Help:Page name it lists the "~" tilde as a character that can't be in a title. Is this because of a technical restriction? It doesn't list why as it does with many of the others. On this page, however, it doesn't mention the tilda at all. Just wondering K1Bond007 18:59, Mar 7, 2005 (UTC)

progra~1 seems to redirect to tilde just fine (though i'm not entirely sure it should be redirecting there). Plugwash 23:29, 19 October 2005 (UTC)

I fixed that. It should be redirecting to the arcticle on 8.3 filenames (which is possibly more relevant). --208.138.31.76 (talk) 20:21, 20 February 2008 (UTC)

Lower case first letter (again)

(The following appeared on the main page but is discussion, as far as I can tell. -- JTN 19:01, 2005 Apr 30 (UTC))

If a term should never use capital letters, then in response to The English language encyclopedia  : the language rule dictates to use small caps when invariants/specific terms use them. Thus this software design intents for applying language rules in place of human writers, could be out of scope, and prone to errors - probably a lot more than a human writers would do. For example, "writers" should not have its plural form in the later sentence context : do not use the "English Language" rethoric to justify and impose something, when only a tiny part of it is actually used by your process - thus makes it erroneous in many cases towards its own "God" : the rule it pretends to represent!

When a technology does not enhance a process, imposes limitations when compared to the "old" process, or obliges people to make errors in regards to some given rule or other process, then that piece of bits & bites should go back to the shop. This is a serious bug, as the software addresses to writers: to assess the quality of a process before production (live context), content management should be considered secondary when its production, its main goal, becomes crippled. Either one should remove (temporarily?) the "syntactic" knowledge base - or whatever regular grammar the process is trying to reproduce, either one should improve this knowledge, either both. Then make that process pass a severe "proof of concept" test, before putting it back into production.

-- 67.68.210.145 16:48, 2005 Apr 30

Other odd case problem

What's up with Beta hCG? It is listed as a technical problem and it seems that moving the page to the correct place doesn't work. — KayEss | talk 14:35, 26 May 2005 (UTC)

fix the capitalization problem

Isn't there some simple hack to fix the capitalization problem? Like, the software automatically capitalizes all article titles, BUT, if the title starts with an underscore, the first letter is considered lowercase. Or something. So you could move EBay to _eBay, but the title of the article so linked would be rendered as "eBay"? - Omegatron 19:39, Jun 4, 2005 (UTC)

That does not work but you can use [[ eBay]] giving  eBay.--Patrick June 29, 2005 11:15 (UTC)

Less restricted restrictions?

Is it true that since yesterday English Wikipedia now has UTF-8 support in article titles? If so, what additional characters are now possible in article titles? If title can now support certain diacritics, we can begin reducing the size of Category:Articles lacking diacritics. --Angr/_{tɔk tə mi} 28 June 2005 08:56 (UTC)

pretty much the whole of unicode is supported. theres nothing stopping you from creating an article with a title in chineese right now.

we need to form a policy on what we should and shouldn't use in article titles ASAP now that the technical restrictions are gone.28 June 2005 18:38 (UTC)

use of unicode in article titles

(from Wikipedia:Village pump (technical)) Now this is techincally possible we need to form a policy on it. imo we should restrict ourselves to ASCII LATIN1 and LATIN EXTENDED A and B and there should always be a redirect from the title stipped to plain ascii what do others think? Plugwash 28 June 2005 15:49 (UTC)

I suggest this discussion be continued at Wikipedia_talk:Naming_conventions_(technical_restrictions). Wikipedia:Naming conventions (technical restrictions) has already been changed to suggest Latin-1 can be used. -- Rick Block (talk) June 28, 2005 18:34 (UTC)

I think we need to be careful about this since not everyone uses browsers that are fully Unicode capable (particularly not everyone in the US). Technically possible doesn't mean the same thing as advisable. -- Rick Block (talk) June 28, 2005 18:43 (UTC)

It should be noted that because of the conversion taking account of windows-1252 charactors we already have stuff from latin extended A in page titles. Browsers that don't support unicode will now have problems with latin1 stuff here because of the utf-8 conversion. Also remember that very old browsers that don't support the host header can't be used here anyway.

in summary i think that nearly all browsers that can't deal with unicode are going to be unusable here for other reasons anyway. Font support may be slightly more of an issue but i'm pretty sure latin extended A and B are pretty well covered in most fonts Plugwash 28 June 2005 19:09 (UTC)

It could be useful if a set of "Wikipedia en: recommended fonts" (freely downloadable and usable without restrictions) were created. Does Bitstream Vera cover enough? --cesarb 28 June 2005 19:34 (UTC)

what exactly does it cover? i guess it may be usefull for *nix users, windows actually comes with a pretty good selection of fonts anyway. I'd wan't a reccomended font to cover the vast majority of latin extended A and B as well as the basic greek stuff (for math) and probablly IPA stuff (which we use for pronounciations) at the very least. Plugwash 28 June 2005 19:45 (UTC)

i've just started Wikipedia:Naming conventions (Unicode) (draft) to try and show whats in the various ranges that i think may interest us with the aim of forming a policy on them. If you wan't tables adding for new ranges just ask and i'll run my generator on them. Plugwash 28 June 2005 20:35 (UTC)

Moving articles lacking diacritics

According to section 2.1:

Articles where the title was incorrect only insofar as it lacked diacritics were tagged by adding the {{titlelacksdiacritics}} template rather than the {{wrongtitle}} template. These articles can now be moved to the correct title. For a list of articles that are subject to these limitations, see Special:Whatlinkshere/Template:Titlelacksdiacritics. Please help out by moving some. When doing so, be careful to avoid double redirects.

Well, I've tried to move some of them, but the software doesn't recognize <n> and <ń> as different letters, or <s> and <š>, so it thinks I'm trying to move an article to the same name it already has. What to do? --Angr/_{tɔk tə mi} 28 June 2005 20:59 (UTC)

are you sure you are using the move form correctly. The new reason field seems to be confusing some people. Plugwash 28 June 2005 21:09 (UTC)

You're right, I wasn't. I was indeed confused by the new reason field. Thanks! (unsigned comment by Angr)

combining diacritical marks

i'm kind of dubious about using combining diacritical marks in titles because from what i've heared browser support for them is not exactly brilliant. so do people think we should move This Is Spinal Tap or not (there is no precomposed n with that diacritic)? Plugwash 28 June 2005 21:11 (UTC)

I agree, we're probably better off not using ad-hoc characters in titles by means of "combining diacritics". Keep This Is Spinal Tap where it is. --Angr/_{tɔk tə mi} 28 June 2005 21:48 (UTC)

ok well i'm going to update the template to reflect that then. Plugwash 28 June 2005 21:50 (UTC)

I just came here from the Spinal Tap page, let me repeat what I wrote on the talk page there. I would rather have an incorrectly displayed attempt at using the right letter than an incorrect letter (n). My browsers do a reasonable job, placing the diacritic after the letter, or ignoring it. We really need to survey the situation before we make decisions based on "technical limitations" (see below). Also, at least the i could become dotless without any difficulties. Arbor 29 June 2005 09:40 (UTC)

Somebody moved the Spın̈al Tap article to use the combined diacritic, which is now at This Is Spın̈al Tap. (I then removed the dot over i as well, and cleaned up a lot of double redirects.) I suggest we keep this page around where it is now, it's a good lightning rod to find problems and stress-test the setup. Have a look. Arbor 9 July 2005 16:31 (UTC)

Quick and dirty survey to find the worst offenders

Display of the letter n-umlaut, Unicode: n̈ (using {{unicode}}: n̈). (please remember the unicode template cannot be used for article titles however). The character is composed of 0x006E (Latin small letter N) followed by 0x0308 (Combining diaeresis).

correctly

• Firefox (Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.8) Gecko/20050511 Firefox/1.0.4)
• Opera (8.0, Win2000)
• Internet Explorer (6.0.2900, Windows XP SP2) using {{unicode}}
  • obviously it won't cooperate to the point of letting me know which font it's actually using :-( --Phil | Talk July 6, 2005 17:01 (UTC)

almost correctly (n with an umlaut offset to the right)

• Netscape 7 (Windows 2k); window title uses n-followed-by-umlaut (probably because it is configured to a not-so-Unicode font). Switching Netscape's Sans Serif font from Arial to Arial Unicode MS fixes the first problem. Urhixidur 19:01, 2005 August 1 (UTC)

n-followed-by-umlaut

• Safari (1.3, Mac OS X 1.3) — but correctly on window title, address bar URL, and tooltip over a wikilink (I carefully conclude that the culprit is WebCore, not Cocoa (API))
• Firefox (Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.5) Gecko/20041107 Firefox/1.0)
• Internet Explorer (5.2, Mac OS X)
• Internet Explorer (6.0.2900, Windows XP SP2) in tooltips and on toolbar
• Firefox (Windows XP SP2) (Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 Firefox/1.0.7)

n-followed-by-square

• Internet Explorer (6.0.2900, Windows XP SP2)
• Internet Explorer (6.0.2800, Win2000)

n-with-square-above

• Konqueror 3.3.1 (Mozilla/5.0 (compatible; Konqueror/3.3; Linux)(KHTML, like Gecko))
  • This representation with an attempted but not quite functioning character combining maybe because of the somewhat fscked up state of fonts on my machine. I can only attest to the missing but correctly placed umlaut on my KDE 3.3.1 desktop on SUSE Linux 9.1. 84.251.253.98

n-followed-by-question-mark

• Firefox on Win98 (Mozilla/5.0 (Windows; U; Win98; en-GB; rv:1.7.8) Gecko/20050511 Firefox/1.0.4)
  • (re This Is Spın̈al Tap: display is 'n?' in article title in HTML, article body, and tab title, but 'n' followed by something that looks like a macron in the window title; I suppose this could be a badly-drawn umlaut)

n

• (please put browser and OS here)

garbage

• (please put browser and OS here)

cmd.exe

Does anyone else find that cmd.exe breaks their browser? It seems to me that if I enter the URL http://en.wiki.x.io/wiki/Cmd.exe, I get a "This page cannot be displayed" error in Internet Explorer, or a "The document contains no data." popup in Firefox. The page loads alright if I go to http://en.wiki.x.io/wiki/Cmd, which is a redirect to Cmd.exe, but I can't click on the links like discussion, edit this page, etc. Since I can't actually talk about it on that article's talk page, and I thought it might be a technical naming issue, I am mentioning it here. --timc | Talk 19:53, 22 August 2005 (UTC)

works fine here are you using any form of proxy/filtering software? Plugwash 20:00, 22 August 2005 (UTC)

That's probably what it is; the corporate proxy must be messing around with it. I haven't seen that happen before. I wonder if it is a good idea to name articles in a way that causes problems with proxies, but I guess that depends on whether anyone else is affected. --timc | Talk 20:12, 22 August 2005 (UTC)

New template created for miscapitalization

I've just created Template:Miscapitalization as an alternative to Template:Wrongtitle and Template:Lowercase, as I feel that miscapitalization is a better term to use. While Template:Lowercase is suitable for pages such as five, it implies that the title should be all lowercase and therefore Template:Miscapitalization would be more suitable for pages such as iiNet. Thoughts? I haven't yet converted any of Template:Lowercase uses and Template:Wrongtitle uses to the new template yet. splintax ^(talk) _{07:24, 11 September 2005 (UTC)}

I see no need for another template. If the phrasing on {{lowercase}} is not good enough, feel free to enhance it. The name of the template itself is not important, since it's visible only when editing. --cesarb 22:47, 17 September 2005 (UTC)

I agree with cesarb. And if the name were a problem, you could just move the template. —Simetrical (talk) 05:58, 18 September 2005 (UTC)

Uppercase first letter illogical

It's a bad mistake for any dictionary or encyclopedia to misspell its entry words (article titles) by erroneously mapping characters in the title words to upper or lower case. To map the first character of each title to upper case just so "it will provide the correct default link in the event someone uses the raw link as the first word of a sentence," makes no sense at all, as that's what [[title | display name]] is for. This is an illogical design choice that needs to be changed. I propose the following software change to fix this problem.

1. Map all title characters in URLs (and in searches) to lower case.
2. An optional title display parameter must be specified within each article to display the title with correct spelling, specified by authors/editors. When mapped to lower case, the Display title must match the page name. If no title display parameter is specified, the default lowercase title will be displayed.
3. When you hover over an internal link, the tool tip will be displayed in whatever case is supplied by the author/editor, even though the link will of course point to the lowercase URL (per rule 1, above). This eliminates the plethora of misspelled tool tips.
4. Note that redirects due to case changes will no longer be necessary (due to rule 1).
5. During the conversion, a one-time conversion routine will look at the current title, and if the current title of non-redirect pages contains any uppercase character as the first character of any word other than the first word, then the routine will go ahead and create a title display parameter for that page using its current capitalization, and will also capitalize the first character. (For pages not covered by rule 5, humans will later add the title display parameter per rule 2 if the page needs one; but there's no rush in doing so, since nothing will be broken in the interim.)
6. The first letter of a title should never be capitalized (by humans) unless the first word requires capitalization to be spelled correctly in a dictionary. In other words, title case should never be used for encyclopedic nor dictionary entries.

It's easy for software to do this correctly. The majority of words are common nouns, and it's wrong and a misspelling to capitalize them for encyclopedic (or dictionary) entries. E.g., there are countless units of measure and unit symbols misspelled in titles and tool tips, one of the important examples of this problem, causing users to misspell units. --Simian, 2005-10-07, 02:46 Z

�

What character is this: �? On my browser, it's just a square. ⇒ JarlaxleArtemis 01:13, 5 December 2005 (UTC)

Oh. Never mind. When I paste it onto Microsoft Word, it appears as a question mark within a black diamond. ⇒ JarlaxleArtemis 01:15, 5 December 2005 (UTC)

Both cases mean the same: a "replacement character", meaning you do not have the character on your fonts. In this case, unless Firefox's copy-and-paste copied it wrong, it's exactly the replacement character, U+FFFD. --cesarb 15:14, 6 December 2005 (UTC)

There's one other restriction...

Even with UTF-8 fully supported, it should be noted that Unicode does not (and has no plans to) support every glyph ever conceived by man. (now Prince) and File:Msglitchname.gif (a.k.a. 'M) are examples of glyphs that won't ever make it into Unicode, and that is a subtle but real restriction right there. —tilde 01:07, 8 January 2006 (UTC)

The capitalisation issue, again

We've established that it would break stuff to change settings regarding the initial capital. However, would it not be possible to implement something in MediaWiki which would allow the correct title to be specified on the page? Then we can have a page at http://en.wiki.x.io/wiki/EBay which contains some {{title|eBay}} code (that's a template, but you get the idea) which specifies that MediaWiki outputs a page titled 'eBay'. In fact, if this were implemented, the existing technical limitations/wrong capitalisation templates could be replaced with a reference to this new wikicode, seamlessly switching over the display. -- Mithent 21:07, 14 March 2006 (UTC)

Now that sounds like a good idea. --pile0nades^{talk | contribs} 07:20, 20 March 2006 (UTC)

It can be done, and many articles over at Uncyclopedia use this little workaround code. In fact, I could go edit Template:lowercase right now to do this, but I'll wait for a consensus on this. Anyway, I've got an example of it on my userpage, and it should be cross-browser compatible. --Nintendorulez talk 01:17, 4 May 2006 (UTC)

During the meanwhilst (?), I've made a script which does this to any page with the {{lowercase}} template on it. User:Haza-w/Title corrector haz (user talk) 15:51, 13 May 2006

The Chinese Wikipedia has already implement this one year ago, see this page. It uses a similar syntax as above (-{T|new title}-) Yao Ziyuan 04:04, 14 May 2006 (UTC)

The same for the italian wikipedia, two month ago, see here. The script tweak is nice, however. --Banus 17:16, 25 May 2006 (UTC)

You can thank me for this tweak, I got my programmer to write the code for another (competing) Encyclopedia Project and promptly donated it to the English Wikipedia. I cannot fathom the reason why the donation was rejected.

There are no "technical restrictions" that force articles like iRobot to have their titles displayed like IRobot - it's sheer bureaucratic inertia. (P.S., I'm the guy who got Tim Starling to supply m:ParserFunctions ;-) --Uncle Ed 14:54, 14 July 2006 (UTC)

Misuse of 'due to'

It is ungrammatical to say 'The title given to this article is incorrect due to technical limitations.' The bit that goes before 'due to' should be a noun (or a clause that describes an object.) This quote from Wikipedia is in common use, but still incorrect. It should be replaced by one of the following:

The title given to this article is incorrect. This is due to technical restrictions.

The title given to this article is incorrect because of technical restrictions.

That's a prescriptivist POV. :) For example, [3] says, "It used to be thought that it was incorrect to use due to in this way, but modern usage shows no hesitation...." Wmahan. 15:19, 14 July 2006 (UTC)

It could be there's an implied, unspoken "which is" right after "incorrect."--pile0nades^{talk | contribs} 03:11, 24 September 2006 (UTC)

Exclamation Mark

I haven't seen anything regarding this, but I'm reluctant to use it because the address it produces has an escape character (%21). Any thoughts? --Trent Arms 14:10, 2 June 2006 (UTC)

Like Yahoo! ? -- Mithent 00:00, 15 June 2006 (UTC)

eBay etc.

however, there is currently no way to do this

Yes, there is. Code has been written in PHP to customize the display of an article title, to permit an article like eBay to be displayed as eBay. Contact me if you want a copy of this code. --Uncle Ed 03:26, 30 July 2006 (UTC)

Getting rid of these technical restrictions

Is there a way to get rid of these technical restrictions? Voortle 18:07, 17 September 2006 (UTC)

Easy way to at least mask the lowercase first letter problem

Make any page with a {{lowercase|lowercasetitle}} template actually change the displayed page title, and only show the template when editing the page. I'm sure I could whip up a quick Greasemonkey script to test this out. *goes to write one* ... *15 minutes later*

Done! Here's the script at userscripts.org.

And a screenshot:
File:Fixwiki.jpg

One question though, is the lowercase template the only one that uses a dl tag? Also it would be helpful if it had an ID to go by. Also, as a side effect, it changes the title of the main article to "Correct Title." This isn't a "real" fix but it works for me. --pile0nades^{talk | contribs} 04:46, 24 September 2006 (UTC)

Script updated, two bugs fixed. It now replaces only the incorrect text in the title with the correct version, leaving " - Wikipedia, the free encyclopedia" intact, and only hides the correct template now. --pile0nades^{talk | contribs} 09:19, 25 September 2006 (UTC)

Updated again, now includes a check for whether the original page title matches the corrected version. This avoids acting on non-"real" uses of the lowercase template, such as this article. --pile0nades^{talk | contribs} 10:40, 25 September 2006 (UTC)

You may want to present this somewhere else, so mediawiki can use it. I think this would be a great addition for all the articles with a lowercase letter. have fun, and keep up the good work. 70.111.218.254 13:28, 14 October 2006 (UTC)

Link on WP for script: Wikipedia:WikiProject User scripts/Scripts/Edit Top 70.111.218.254 13:31, 14 October 2006 (UTC)

I've added the script here.

Wouldn't it be easier if a template was set up, and when used at the start of page would change the first letter to lowercase instantly? If it was set up right, perhaps the code would only work if an administrator added it, and if anyone, not an administrator tried to delete it, then the page would update but leave the code there? A simpler way might be simply letting Administrators "flag" a page using a button. Perhaps an extra field can be added at the bottom of the Move page for administrators only, and it will allow them to move the page to another page, where Technical Restrictions on the title for letter-cases are ignored. This way any links that may be broken due to the move will redirect to the new page, and can later be edited to go directly to the new page, instead of renaming the page link to show the lowercase letter.--Pyrgus 04:06, 17 October 2006 (UTC)

Summary of lower case first letter issue

The discussion of the lower case first letter issue is just as contorted as the actual problem. Would someone who understands the javascript impacts on all the style sheets just PLEASE fix it! Apparently it's been fixed in many other Wikipedias, but not in the English Wikipedia. A quick summary of the discussions spread randomly through many pages:

Wikipedia User javascript solution - Fixes window title and article title. While beautiful, it's useless because it doesn't work for the actual users of wikipedia, only the authors. Such a script is counter-productive because it hides the existance of a big problem from those best able to fix it.

Italian Wikipedia Solution - Fixes article title only, window title still incorrect. Causes small bars under the article title in Safari.

Swiss German Wikipedia Solution - Fixes article title only, window title still incorrect. Displays perfectly in Safari.

Proposed change to Template:Lowercase by Water Bottle that caused undocumented display problems:

<h1 class="firstHeading" style="display: block !important; border-bottom-style: none; float: left; position: absolute; left: 0.25em; width:100%; top: 0%; background-color:#FFFFFF"> {{{title}}}</h1>

Uncyclopedia Solution:

<div class="firstHeading" style="font-size: 188%; padding-top: 0.5em; padding-bottom: 0.17em; float: left; position: absolute; left: 0.5em; top: 0%; width: 98%; background-color:#FFFFFF">{{{1|{{PAGENAME}}}}}</div>

Discussion of the above two solutions

Discussion of why it should be fixed

Plus, lots of other useless banter about the wording of the apology itself that I'm not going to link. Why don't we just fix it instead?

UncleDouggie 08:23, 15 October 2006 (UTC)

Is O-macron okay?

The article Hoei is tagged "wrongtitle|title=Hōei". Is this an artifact of pre-unicode days? Is there anytihng wrong with moving it to Hōei?

Actually, it isn't just O-macron. Is there an easy way to tell what is okay in a title? Should I just try the move and see if it goes? -- Randall Bart <wiki@randallbart.com> 08:37, 17 October 2006 (UTC)

if you can type it wikipedia will accept it, whether other people will be able to see it is another matter but o with macron should be fine as its in wgl4. Plugwash 07:18, 18 October 2006 (UTC)

Okay. Actually sumbuddy beat me to Hōei, but I did Hōei eruption of Mount Fuji. I'm going to try to clear up a lot of wrongtitle tags. They usually require double redirect fixing too, which I have to do else I'm messing up my cleanup of double redirects. The whole redirect mechanism is a malimplementaion anyway.-- Randall Bart 09:00, 26 October 2006 (UTC).

The use of  : like in Nd:YAG

The use of : in naming is not recommended as is shown in the YAG series, wikilinking to these articles disapear or end up as a interwikilink, Nd:YAG Nd:YCOB, (Ti:sapphire) (Tm:YAG)Ce:LiCAF) (Sm:CaF2) Nd:GdVO4, Yb:LuVO4 or Er:YAG laser in the examples shown the used format of the name is the same as the wiki format. suggested is change the the : to -like in nl:Nd-YAG laser nl:Er-YAG laser, a new template can be used above the article or just a line.

• The name of this article has been changed because of Wikipedia:Naming conventions (technical restrictions) The correct name of this article is Er:YAG laser. reg. Mion 15:35, 24 October 2006 (UTC)

My request is to mention it in Naming conventions (technical restrictions), and to correct the articles involved. Mion 17:13, 24 October 2006 (UTC)

Note that the nonworking examples (Ti:sapphire Tm:YAG Ce:LiCAF Sm:CaF2) were added to the comment above by Mion after much of the discussion below took place. My replies below reflect Mion's original complaint about the perfectly valid Nd: Er: and Yb: prefixes. I'm sure Mion did not intend any deception, but it is definitely not acceptable to alter your comments after someone has replied to them.--Srleffler 20:15, 25 October 2006 (UTC)

Sorry. Mion 20:24, 25 October 2006 (UTC)

There is no need for a new template for this. If the articles are renamed the {{Wrongtitle}} or {{namespace}} template will do just fine. I don't see what the problem is, though. Links to these articles seem to work fine, both within the English 'pedia, and from other languages. Why invent technical limitations that do not exist?--Srleffler 01:01, 25 October 2006 (UTC)

Try to link Ho:YAG laser from one page to another, you will find instead of the link a interwikilink. Mion 01:09, 25 October 2006 (UTC)

That's because there really is a technical limitation that prevents Ho:YAG laser from being a valid article title, and as a result there is no wikipedia article with that title. No such limitation exists for Nd:YAG, Nd:YCOB, Nd:GdVO4, Yb:LuVO4, or Er:YAG laser. These are all perfectly valid article titles. There is no rule against using colons in article titles; just a rule against using a colon preceded by the name of a namespace. Nd is not a namespace. Nor is Yb. Again, there is no need to invent false technical limitations that do not exist.--Srleffler 01:27, 25 October 2006 (UTC)

Point is that if in future times a language pops up in Er, Yb, Nd, and so on, the same happends as already happened to Ho, that all the internal wikilinks automatic move to the interwikilink section. Mion 01:24, 25 October 2006 (UTC)

That is not likely to happen. I believe the Wikipedia language codes are taken from ISO 639, which is a closed standard covering the world's "major" languages. More minor languages are listed in ISO 639-2, and are forbidden from being later issued a two-letter code. So, Er: and Yb: are safe. If the northern Ndebele people want to start a wikipedia in their language, we can rename the Nd: articles at that time.--Srleffler 01:39, 25 October 2006 (UTC)

and you are going to do that at that time? , through all wikipedia's at the same time ? thats my point, it will happen , better to take action now, .Mion 01:55, 25 October 2006 (UTC)

I will take inventor as a compliment. Mion 10:19, 25 October 2006 (UTC)

meaning inventor of problems, the inventor of the : issue might be found here [[4]]. Mion 20:38, 25 October 2006 (UTC)

Also see the {{DISPLAYTITLE}} magic word, in the external links. Bug votes and discussion would help get it the attention it needs. See Template_talk:Wrongtitle#This_is_a_bug_that_can_be_fixed — Omegatron 00:44, 26 October 2006 (UTC)

This template as a see it(maybe wrong) , will fake the title for the viewer (main goal) and show that on top of the page, what its not faking is the name to the rest of the software, which would be the same as renaming and which is the question here, so i still go for exluding :, or : on the third position, reg Mion 12:01, 26 October 2006 (UTC)

Colors

Prior to Deadkid dk's October 25th revision, there had stood for nine days an addition for colors to the article (for instance House of Leaves, or Higurashi no Naku Koro ni). I've heard it said that this is a WP:MOS violation, but it seems like a reasonable technical restriction to me; titles being alotted more room for merit than propogating advertising. Since it went un-reverted for a while, I thought I'd poll the consensus, see what others had to say. --mordicai. 14:55, 26 October 2006 (UTC)

I tend to think i would group both color and pictoral names in the "things we wouldn't wan't to use even if the software allowed them" category. IIRC when unicode was introduced there were a lot of moves that got reverted before things settled down to more or less how they had been before (with the exception that we now use eastern european letter/diacritic combinations as well as western european ones and we occasionally use a symbol thats part of the official english name). Plugwash 14:15, 29 October 2006 (UTC)

The Wikipedia:Manual of Style (trademarks) suggests that in an article about a trademark, the special characters appear once at the begining of the article. If we don't want to call color a technical restriction, would that be a good example to follow, whether for titles or other article names that could conceivably crop up? For a lot of articles I could see this being nothing more than a vanity issue, but for something like House of Leaves, where use of color whenever the word house crops up is part of the po-mo riddle, I think it has merit. --mordicai. 15:39, 29 October 2006 (UTC)

Javascript hack

A javascript hack has been added to the common.js [5] that makes the title for pages like iPod show up as "iPod" rather than "IPod" when users have javascript turned on. The "due to technical restrictions" blurb will normally be hidden in these cases, and displayed only if the user has Javascript disabled.

In addition, if the suggested article name can't be copy-n-pasted to form a valid wikilink to the article, then the article title is not replaced. So, if I put {{lowercase|User talk:Jimbo}} on my talk page, that won't actually make people think my talk page is Jimbo's. Though this appears on more subtle situations, like C Sharp, and even talk (Unix) (which currently has {{lowercase|talk}}, and "talk" isn't a copy-n-pasteable link back to the article). --Interiot 07:14, 24 November 2006 (UTC)

Might wan't to add some code to correctly handle cases like the talk (Unix) one (maybe change the code so that it only looks at/swaps the first letter rather than the entire title). Plugwash 17:15, 1 December 2006 (UTC)

The issue is that the actual lowercasing is done by the template, it's not done in the javascript code. That's because there's a number of other titles that the code can fix, eg. mod_perl. I think this is proper, {{DISPLAYTITLE|...}} does the same thing... it handles other cases than simply lowercase, by allowing the article to propose a new title, and itself not automatically lowercasing the title.

At most, the javascript could more or less handle the pipe trick. But I'm leery of increasing client-side code complexity, and maybe this is something that article editors will start fixing on their own, now that the code is available site-wide. (fixing it means that when Javascript is turned off, users will see "the correct name of this article is 'talk (Unix)'", which does seem a little less natural... but at this point, most people should see the "fixed" version) --Interiot 18:00, 1 December 2006 (UTC)

My opinion is that the trick needs to be copied into a few other templates used for this purpose. For example, MARRS (properly displayed as M|A|R|R|S) uses a different template, and the {{lowercase}} cannot be used because it explains the reason for the notice incorrectly. Should I request this elsewhere or is this the best place? --Romanski 20:55, 8 January 2007 (UTC)

Apostrophe

When trying to search for or link to Actors' Fund, this user was going nuts trying to discover why it wouldn't work, and looked in vain for the answer. Finally I was helped by an old timer who pointed out that the page creator had used the legacy form found in punctuation which needed to be changed to the typewriter vertical form found in apostrophe. I've added a notation to the project page under 2.8 in the hope that newer editors like me can find this answer. JohnClarknew 02:50, 25 November 2006 (UTC)

CSS changing title

I recall there was a CSS-hack template to change the displayed title (mentioned at Template talk:Wrongtitle#New Template), that was rejected and deleted (but I cannot now find).

I just found this, which I imagine should also be deleted: Wikipedia:WikiProject User Page Help/Do-It-Yourself/Title Headers, but I need the previous discussion to refer to, for an MfD. Anyone know where to look? Thanks. --Quiddity 04:38, 6 December 2006 (UTC)

Wikipedia:Miscellany for deletion/User:1ne/Title is one such MfD, from a month ago, with a result of keep. In any case, much the same thing can now be done with the Common.js hack. Also, the same thing may be possible with the {{DISPLAYTITLE|xyz}} feature implemented by the MediaWiki bugs mentioned on this page (it's not clear what the restrictions are there). --Interiot 05:12, 6 December 2006 (UTC)

Ah, not deleted/rejected. I will ignore then. -Quiddity 20:50, 6 December 2006 (UTC)

Lower-case first letters: Looks like it's been fixed

It seems like the whole section about this restriction is outdated now. Should it be deleted?151.202.111.202 05:02, 21 December 2006 (UTC)

I'm not sure. Editors will probably always need to place {{lowercase}} to change the default behavior. Readers with browsers that don't support or don't have javascript turned on will still see the same thing that was seen before. Maybe once the MediaWiki fix goes in, and javascript support isn't an issue, then the section can be trimmed down, but since the current behavior hasn't changed for some segment of users, I don't know that it needs to be trimmed down a lot right now. --Interiot 05:11, 21 December 2006 (UTC)

Change in this article not shown in edit history

I'm very confused. Earlier today, I linked to this article, specifically, the section on Pictorial names. I used the text in this section to justify an argument that the Unicode heart symbol should be permitted in an article title, as the peace symbol was permitted in the article title of the film, Sign_“☮”_the_Times_(film).

If you visit Talk:We ♥ Katamari, you can see my edit from this morning includes information about the album, which I took directly from this page. Now, later today, I'm looking at this page, and this section has completely changed. Gone is the mention of the Prince album as an example of how it is "permissible to use Unicode characters in article names".

I would like to know who made the edit to this page and why. Do admins have the ability to make hidden changes? The content here is different from what it was this morning, and it's not in the Edit history. Joie de Vivre 01:14, 8 January 2007 (UTC)

Yes, admins can change a page and then delete the change from the edit history. But it's very rarely done - generally for legal reasons or vandalism to sensitive pages. The google cache of the page shows no change, for what that's worth.

Looking at the article, I see the following:

File:Prince symbol.svg was for many years the proper name of Prince. MediaWiki does not support including an image in the title of an article. Such images should be replaced by Unicode characters. On the other hand, the peace symbol used in Sign “☮” the Times is a valid Unicode character (U+262E), so it can be included in this title.

What text (exactly) were you expecting to see? John Broughton | Talk 03:29, 8 January 2007 (UTC)

I wish, now, that I had copied and pasted it, but I trusted that any changes would be apparent in the edit history. I can't recall the exact text, but I can give you the basic idea. You can see that currently, it says (emphasis mine), "(the peace symbol)... is a valid Unicode character, so it can be included in this title." I recall the previous version as being explicit in stating that Unicode characters are permissible in all article titles that require them. I recall the Prince album being mentioned as only one example of appopriate use of a Unicode character in a title. I don't recall the phrase "on the other hand" being used. Granted, it's possible that something is wrong on my end, with either my technology or my own memory, but it struck me immediately that it seemed different. In an argument I was making over at Talk:We ♥ Katamari I quoted this section as being "explicitly clear", which it no longer seems to be. I would like this to be made transparent. Joie de Vivre 13:48, 8 January 2007 (UTC)

First, as I read the naming convention, pictorial symbols are not listed in the first two section ("totally forbidden" and "with some problems"), and so are allowed. Second, the google cache as of 5 January at 16:13 GMT looks identical to the current version of the project page. Third, I wonder if the confusion may be some underlying change in the wiki software (no idea what) or something else quite technical. For example, I'm seeing "?" in the title "Sign '?' the Times", using Firefox. When I use IE 7.0, I see a box. Were you perhaps using another browser, one that had a different font that could actually display this symbol? (Apparently, most browser fonts can't.) John Broughton | Talk 01:48, 9 January 2007 (UTC)

I see the peace symbol in Firefox, but a [] box in IE 7, on the same PC with the same fonts used. Strangely enough, IE7 can actually display the correct character on the page itself - except in the article title. Weird browser. I don't know how to make IE7 display the character properly. --Romanski 09:33, 9 January 2007 (UTC)

Moving the page?

This page should probablly be moved, it's a document on things that we can't name pages for technical reasons not a document on what we should be naming things. Plugwash 13:54, 9 January 2007 (UTC)

While some of the page is about things that can't be done, other parts are advice - for example, Care should be taken that the proper vertical typewriter form of apostrophe is used in the title. If the non-standard form found in punctuation is used, the page cannot be linked to. -- John Broughton | Talk 13:58, 9 January 2007 (UTC)

Maybe it should say: "makes it hard to link to". Anyway, it's not a technical issue, so it does not belong on this page. Simple as that. – gpvos (talk) 17:35, 3 February 2007 (UTC)

Apostrophe

Removed the paragraph about the apostrophe, since it has no technical reason. Moved the paragraph about dashes to the section about browser problems, since it's not a MediaWiki technical issue. Maybe it should be removed too. – gpvos (talk) 17:33, 3 February 2007 (UTC)

Not set in stone

The template at the top of the page says, in part, "However, it is not set in stone and should be treated with common sense and the occasional exception."

I'm not sure that's strictly true. Unlike other style guidelines, these technical restrictions are set in stone. --ESP 04:55, 19 June 2007 (UTC)

Fair use rationale for Image:Fixwiki.jpg

Image:Fixwiki.jpg is being used on this article. I notice the image page specifies that the image is being used under fair use but there is no explanation or rationale as to why its use in this Wikipedia article constitutes fair use. In addition to the boilerplate fair use template, you must also write out on the image description page a specific explanation or rationale for why using this image in each article is consistent with fair use.

Please go to the image description page and edit it to include a fair use rationale. Using one of the templates at Wikipedia:Fair use rationale guideline is an easy way to insure that your image is in compliance with Wikipedia policy, but remember that you must complete the template. Do not simply insert a blank template on an image page.

If there is other fair use media, consider checking that you have specified the fair use rationale on the other images used on this page. Note that any fair use images uploaded after 4 May, 2006, and lacking such an explanation will be deleted one week after they have been uploaded, as described on criteria for speedy deletion. If you have any questions please ask them at the Media copyright questions page. Thank you.

BetacommandBot 01:34, 8 July 2007 (UTC)

Italics in binomial nomenclature

Resolved

Biologists and others fond of accuracy often get quite worked up about the typesetting of binomial species names. You can lose marks in academic exams for failing to follow the conventions. Apologies if this has been discussed before, but since it's possible to transform article titles in the page heading to override initial capitalisation and other such things, would it be possible to create a template that, using CSS or whatever, allowed scientific names of biological species to be italicised. It seems a shame when you look at articles like Acer rubrum and care has been taken throughout to italicise the name, but the heading is out of reach. This sticks out like a sore thumb to biologists. 79.68.236.197 (talk) 11:26, 19 December 2007 (UTC)

There are also articles such as p-group, where the initial p should be in italics but the rest of the title shouldn't. --Zundark (talk) 14:01, 19 December 2007 (UTC)

solution posted at Wikipedia:Requested_templates#Article_titles_in_italics --Ludwigs2 21:26, 28 September 2008 (UTC)

{wrongtitle} should be last

This page needs to be refactored a bit so {{wrongtitle}} appears to be the last option, after all the other templates listed in the {{wrongtitle}} documentation. Too often people use {{wrongtitle}} where other templates are more appropriate (especially {{lowercase}} which doesn't even need JavaScript) ∴ AlexSm 05:39, 4 January 2008 (UTC)

Park/Ratheniska

After reading the guideline, I'm unsure what to do about the article Park/Ratheniska.

The title is correct — it's a GAA club name Park/Ratheniska (with the slash) — but i'm not sure whether the article should stay where it is or be moved to Park-Ratheniska, with a {{wrongtitle}} template as a hatnote. Any suggestions? --BrownHairedGirl (talk) • (contribs) 18:52, 22 February 2008 (UTC)

The current title is ok, there are a lot of other articles with slash, see Wikipedia:Articles with slashes in title. The only side-effect is automatic Talk:Park link at the top of Talk:Park/Ratheniska. —AlexSm 19:42, 22 February 2008 (UTC)

I also had to come here to know what to do about an article with a slash in the title. I'll add a note to this effect in the guideline. --Slashme (talk) 13:06, 25 June 2008 (UTC)

Unicode in article titles or not?

I'm confused by this policy. It's not allowed to use "#" in an article title for technical restriction reasons, but it's okay to use a unicode mess that looks somewhat like a "#" instead? Besides the fact that no one can type that into the search form and many users won't be able to see it properly? The article for S♯arp used to be at Sharp (group) but someone decided it just had to be at the former, so they moved it. Now the only way to get to the article is to copy-paste the name (which means you have to find it in the first place) or through a redirect. How can this be "correct?" --hamu♥hamu (TALK) 19:52, 4 July 2008 (UTC)

Replacement characters

I would like to propose that we establish some consistent system for handling titles including disallowed characters. It could be as simple as a list of character replacements and a prescription that we include a redirect where possible from the 'common form' or use the changetitle javascript to make it appear regular.

My main concern is the colon where the part before the colon forms a valid namespace or interwiki prefix. We currently have a couple of these, and there is the potential for more. I'd suggest that we A) replace the colon with a similar appearing character, B) condone a cross-namespace redirect from wherever the 'common form' happens to be, and C) use the changetitle trick to make it look regular. I think this minimises the disruption caused and allows us to have a consistent approach. We have a few choices for the colon alternative: the most similar character that renders correctly in IE is the "Hebrew punctuation sof pasuq" ׃, which will never have any legitimate use on en.wiki (only appearance is at ׃, as a redirect to Hebrew alphabet. However, aside from the unavoidable syntactic difference (it's, astonishingly enough, not a colon!) it's also a right-to-left character, which means it sometimes behaves a bit wierdly. Perhaps a safer alternative is a simple semicolon, although this is more noticeably different to the colon character. Thought? Happy‑melon 22:59, 17 October 2008 (UTC)