Archives

1, 2, 3, 4, 5, 6, 7, 8, 9, 10 11, 12, 13, 14, 15, 16, 17, 18, 19, 20 21, 22, 23, 24, 25, 26, 27, 28, 29, 30 31, 32, 33, 34, 35, 36, 37, 38, 39, 40 41, 42, 43, 44, 45, 46, 47, 48, 49, 50 51, 52, 53, 54, 55, 56, 57, 58, 59, 60 61, 62

Archives by topic: Common names 1, 2, 3 Naming conflict 1, 2, 3 Precision and accuracy

This page has archives. Topics inactive for 60 days are automatically archived by Lowercase sigmabot III if there are more than 5.

This is absolutely a terrible decision. It looks far cleaner with the clarity of saying it is UK Parliament constituency. What a horrendous decision and it appears every person seems to agree with it. No idea why. Why would you not want clarity?!?! — Preceding unsigned comment added by RyanPLB (talk • contribs) 10:34, 1 December 2025 (UTC)[reply]

Should Wikipedia:Naming conventions (U.S. state and territory highways) be revised with regard to the naming conventions for state routes in Kansas and Michigan so that the parenthetical disambiguators "(Kansas highway)" and "(Michigan highway)" are only used when disambiguation is necessary, or another format entirely is used instead? 23:05, 17 November 2025 (UTC) Mdewman6 (talk) 22:25, 18 October 2025 (UTC)[reply]

Currently, the naming convention calls for articles about state highways in Kansas and Michigan to be titled K-X (Kansas highway) and M-X (Michigan highway), respectively, where "X" is the route number. These are unique among the states and territories, as all others include the state or territory name in the article title. Indeed, even North Carolina and Puerto Rico, where official route names use the format "NC X" and "PR-X", respectively, nevertheless call for article titles to be North Carolina highway X and Puerto Rico highway X, respectively.

I am not completely familiar with the history regarding consensus for these naming conventions, but do know they arose many years ago after much contentiousness, to the point that there was an ArbCom case in 2006. Nevertheless, the Michigan highway convention became an example of local consensus for unnecessary disambiguation at WP:PRECISION, calling for inclusion of the parenthetical qualifier even if the base name of "M-X" does not have other meanings covered in Wikipedia. Given the recent RfC regarding the naming convention for parliamentary constituencies, which was the other such example at WP:PRECISION, overwhelmingly rejected this call for unnecessary disambiguation, it seems timely to revisit the highway naming convention.

The most straightforward option would be revise the naming convention to call for titles along the lines of Kansas highway X or Michigan highway X (Option 1), thus utilizing WP:NATURAL disambiguation as is done for all other states and territories. Kansas state highway X or Michigan state highway X are also possibilities that offer more precision, given the existence of other classes of highways (county highways, U.S. routes, interstates) in these states.

Alternatively, if there remains consensus that the best format for Kansas and Michigan highways per WP:CRITERIA and particularly WP:COMMONNAME is the existing "K-X" and "M-X" format, then the naming convention should be amened to clarify that the "(Kansas highway)" and "(Michigan highway)" qualifiers should only be added if there are other uses of "K-X" or "M-X" covered in Wikipedia, per WP:QUALIFIER (Option 2). If the "K-X" and "M-X" names are really the common names, then the qualifiers shouldn't be needed just for recognizability. Calling for inclusion of the qualifier in all cases regardless of whether it is needed conflicts with WP:CONSISTENT, which makes clear that parenthetical qualifiers shouldn't be used for all articles within a particular topic just because some require them for disambiguation.

In many cases, there are multiple uses of "K-X" or "M-X" that would make the current disambiguation valid, particularly at lower numbers of X, often ships in the case of K and weapon systems in the case of M (though many of these are in my view should be disambiguated per WP:SMALLDETAILS instead). But there are dozens of cases where the "K-X" or "M-X" base names are WP:MISPLACED redirects to the "K-X (Kansas highway)" or "M-X (Michigan highway)" pages hosting the article, e.g. K-145, K-179, M-154, M-179.

To summarize, I feel the naming conventions should be revised in some form to address this longstanding issue and bring them in compliance with WP:Article titles policy. Mdewman6 (talk) 22:30, 18 October 2025 (UTC)[reply]

• The "Pennsylvania Quadrant" entry is another; e.g., State Route 1002 redirects to State Route 1002 (Lehigh County, Pennsylvania). Extraordinary Writ (talk) 22:31, 18 October 2025 (UTC)[reply]

Yes, I'm not sure what to do about that. It's unclear to me why we have "Pennsylvania Route X" but others are just "State Route XXXX", or why the disambiguator can't just be "(Pennsylvania)"- for the latter I assume there can be multiple uses of "XXXX" in the state in different counties? Mdewman6 (talk) 22:40, 18 October 2025 (UTC)[reply]

• I suspect the reason for the "always disambiguated" titles is to make script and bot updates easier. While that may sound like a non-issue, there's a lot of intricate code in the infoboxes and junctions list for roads (probably the most complicated next to rail line infoboxes, those things are insane) and when those infoboxes need to be updated or patched or whatever, and said patch requires a bulk parameter change in the articles, the ability to have a script and/or bot do it is most helpful. A benefit of having a uniform name for the entire set of articles is to minimize the number of "Special case" article titles the script or bot has to deal with. Dave (talk) 22:53, 18 October 2025 (UTC)[reply]

I wonder if that so long as a consistent version like "M-X (Michigan highway)" exists as a redirect, then scripts and bots can be run with minimal disruption depsite page moves? I do not know, I have little experience with that side of WP. Mdewman6 (talk) 23:02, 18 October 2025 (UTC)[reply]

At a minimum the script/bot would have to recognize the db response was a redirect, and then parse the "real article". However, I only know enough about the template and lua coding to be dangerous. I don't know if that's easy or difficult to do, and the people I used to rely on to help me with such coding have since left Wikipedia. Dave (talk) 23:21, 18 October 2025 (UTC)[reply]

Modules (like Module:Pagetype) can recognize redirects (using isRedirect attribute of the title object, and so can templates (like {{is redirect}}). I assume that means a bot could as well, but don't take my word for it. Mathglot (talk) 00:03, 19 October 2025 (UTC)[reply]

• Oppose—there are several factors to consider in article titles. Outside of this discussion, would anyone know what "M-185" referenced on its own? A reader might assume it's a Messier number for a galaxy, a motorway in a country that follows that numbering convention, a military equipment number, or a variety of other topics. One can make article titles too short and deprive others of the context.
  We need to balance all of the factors: "Recognizability", "Naturalness", "Precision", "Concision", and "Consistency". Having some of Michigan's highway article omit the "Michigan highway" portion would be concise for those specific examples, but it wouldn't be consistent with the remainder of the article set. Removing it would harm recognizability as noted above.
  My last point is that Michigan's highway articles have had stable titles ever since WP:SRNC and the ArbCom case in 2006. That's a long time (19 years this month), and it would be strange to disturb such a stable precedent and convention. All of my comments here should be equally applied to Kansas mutatis mutandis. Imzadi 1979 → 04:31, 31 October 2025 (UTC)[reply]

@Imzadi1979: so what would be the drawback to option 1 above, i.e. changing the titles to "Michigan Highway X" or "Kansas Highway X"? North Carolina highways use this format rather than "NC X", so why are these two states the only exceptions?

Either "M-185" is the common name of the highway and is recognizable on its own, or per WP:ACROTITLE, it's not and abbreviations shouldn't be used as the title. We can't have things both ways by using an abbreviation and a parenthetical qualifier, even when the abbreviation isn't ambiguous. MOS:ACROTITLE advises against using abbreviations with parenthetical disambiguation- instead, the title should just be the unabbreviated form.

And I strongly disagree with the argument that these conventions were settled on 19 years ago and therefore shouldn't be changed. Just because these were the outcome of a contentious debate long ago doesn't mean we should be stuck with them and they can't be revised as needed, especially when they conflict with article title policy. And I see no distinction between this call for unnecessary parenthetical disambiguation and that for the parliamentary constituencies that was just unanimously stuck down in the last RfC. Mdewman6 (talk) 21:37, 1 November 2025 (UTC)[reply]

The “M-” is not an abbreviation. Ditto the “K-”. Your option 1 uses a falsehood and cannot be implemented on that basis. The letter is an integral part of the designation and does not expand to another word. Option 2 fails the consistency and recognizability criteria.

Any change to the naming convention should go through ArbCom as they imposed the process to settle the various naming conventions as part of the Highways 1 case in 2006. Discussions about changing these conventions have been considered a third rail ever since, and any changes to the conventions really need to go to ArbCom based on the decisions of that case. I would strongly advise you that nothing here is broke and needs to be fixed in the strongest possible terms. Seriously, please leave this all alone. Imzadi 1979 → 22:43, 1 November 2025 (UTC)[reply]

How is "M" in "M-185" not an abbreviation for Michigan? Mdewman6 (talk) 21:59, 2 November 2025 (UTC)[reply]

It is not an abbreviation and never has been. It may match the first letter of the state's name, but neither the Michigan State Highway Department nor Michigan Department of Transportation have ever said it is an abbreviation for anything in the 106 years the naming scheme has been in use. Never. Imzadi 1979 → 23:36, 2 November 2025 (UTC)[reply]

I don't have any strong opinion regarding how these articles should be titled, but I do disagree that it's necessary (or even beneficial) for people to go to ArbCom if they want to change this titling convention.

• First off, I reviewed the final decision at WP:RFAR/HWY and ArbCom didn't impose the current guideline in the first place—they encourage[d] the community to adopt a formal policy on the naming of state highways, and placed a restriction on moving highway articles [u]ntil a formal naming convention policy regarding state highways is reached. That is to say, while ArbCom may have encouraged the creation of the existing guideline, they explicitly left the actual shaping of the guideline in the community's hands, and any content restrictions that they placed have elapsed now that that guidance exists.
• Second, while I wasn't active in 2006 and can't attest to what arbitrators thought then, current-day arbitrators consistently take the stance that ArbCom should not be in the business of ruling on article content (see the proposed decision subpages at WP:HJP or WP:ARBTRANS for recent high-profile cases where arbs expressed that view). If this debate were to be brought before ArbCom, it's almost certain that they would (rightly) decline it as outside of their remit.

In short, this is exactly the kind of debate that should be hashed out within the general community, and in that respect I think that—however the discussion ultimately resolves—the venue chosen for it was exactly correct. ModernDayTrilobite (talk • contribs) 23:44, 2 November 2025 (UTC)[reply]

• Support for the same reason NCUKPARL was recently changed. Crouch, Swale (talk) 23:37, 2 November 2025 (UTC)[reply]
• Support any option that brings that guideline into compliance with the WP:AT policy (including with regard to titles of "Pennsylvania Quadrant" articles). The titles that option 1 proposes seem to be descriptive, so they do not inherently imply that the shorter formal names of the relevant highways are acronyms, and they are consistent with those of other articles that describe U.S. state highways as outlined in the guideline. If the base titles of the highway articles are more recognizable on their own, option 2 may also work. –Gluonz ^{talk contribs} 14:26, 11 November 2025 (UTC)[reply]

  Except that as I've tried to explain apparently to no avail that Option 1 is improper and unacceptable to those few topic editors left remaining here. I would say that it isn't come across as "descriptive"; instead it expands a letter incorrectly into a phrase, and the lowercase letter isn't enough of a distinction to correct the error. The nomenclature suggested does imply a convention that doesn't exist. Imzadi 1979 → 05:40, 12 November 2025 (UTC)[reply]

• Oppose. For Option 1, those aren't the designations of the highways, as Imzadi1979 pointed out. For Option 2, recognizability and consistency are just as valid as concision. In this case, keeping a consistent naming convention for a clearly-defined set of articles is more helpful than deleting a handful of characters from the titles of certain pages. There is no benefit to the encyclopedia (and plenty of opportunity for unproductive arguments over what the primary topic may be where some other thing has a similar nomenclature). --Sable232 (talk) 22:32, 16 November 2025 (UTC)[reply]
• Oppose both options, as neither satisfies WP:AT. While I am not a great fan of parenthetical disambiguation in this manner, it is still preferable to have an article title that is accurate (which Option 1 is not) and consistent (which Option 2 fails). If another option that can resolve these issues is proposed, I would be inclined to change my !vote accordingly. SounderBruce 06:12, 18 November 2025 (UTC)[reply]
• Oppose both options per Imzadi1979.--~2025-35594-96 (talk) 00:23, 23 November 2025 (UTC)[reply]

Should Wikipedia:Naming conventions (UK Parliament constituencies) be further modified to only require "(UK Parliament constituency)" or "(Scottish Parliament constituency)" when there are multiple constituencies such as North East Fife (UK Parliament constituency) and North East Fife (Scottish Parliament constituency) and otherwise use Clacton (constituency) instead of Clacton (UK Parliament constituency) and Orkney (constituency) instead of Orkney (Scottish Parliament constituency). At #RfC on pre-emptive disambiguation in constituency article titles there was consensus to move unambiguous articles to the base name such as Bury St Edmunds and Stowmarket (UK Parliament constituency) to Bury St Edmunds and Stowmarket but this RFC deals with removing extra disambiguation when the topic does need disambiguation because of a different use such as a settlement or district. Crouch, Swale (talk) 22:03, 9 November 2025 (UTC)[reply]

• Pinging people who participated in the previous RfC and have recently been involved @162 etc., Amakuru, Andrew Gray, DankJae, DimensionalFusion, Doktorbuk, Elli, Extraordinary Writ, JHunterJ, GothicGolem29, Graham11, Mdewman6, ModernDayTrilobite, PamD, Surtsicna, Thryduulf, and Yoblyblob: as well as significantly involved in the 2014 discussion.
• Support it makes no sense to have a title like Clacton (UK Parliament constituency) or Leeds North West (UK Parliament constituency). While it could be argued that Leeds North West (constituency) would be helpful as it shows its not about the north west part of Leeds the RFC was clearly against that (of which I agree) but I can see no reason why "UK Parliament" is helpful and at least in England few are ambiguous (as opposed to in Scotland) so few would actually need the longer title anyway so consistency doesn't seem a problem here anyway so Georgia (U.S. state) would be the exception while New York (state) and Washington (state) would be more common. In terms of common usage apart from people saying "MP for Clacton" people do refer to "my constituency" by not "my UK Parliament constituency" of which the latter only seems to get 2 results while the former gets lots of results so I don't see how this is even commonly used extra disambiguation when people need to specify them in real life. Crouch, Swale (talk) 22:03, 9 November 2025 (UTC)[reply]
• Support. This policy says: "Titles should unambiguously define the topical scope of the article, but should be no more precise than that." Surtsicna (talk) 22:05, 9 November 2025 (UTC)[reply]
• Support. No need for unnecessary disambiguation Yoblyblob (Talk) :) 22:25, 9 November 2025 (UTC)[reply]
• Support, the disambiguation tag does not need to be more specific than it needs to, especially in England where there is only one constituency type. Accidentally already did it in Wales twice when NCUKPARL was at first fully retired, happy to move those back pending this discussion. I assume this discussion will basically fully retire the convention? If the constituency name is the only article (or noteworthy redirect) with that name then it doesn't need the disambiguator tag. The full dab made some sense when it was applied 100% consistently until that discussion, so now no real reason to keep the full disambiguator when it is not needed. Follow standard disambiguation rules. DankJae 22:42, 9 November 2025 (UTC)[reply]

  I think we would just modify the guideline again to say to only use "constituency" is disambiguation is needed but there is only 1 constituency with the name. Crouch, Swale (talk) 19:17, 10 November 2025 (UTC)[reply]

• Support. This is really a no-brainer. Personally, I would also like to go further and omit the UK Parliament part of the disambiguator, unless there's actually another constituency of a different type with the same name. So we'd retain Cardiff Central (UK Parliament constituency) and Cardiff Central (Senedd constituency), but for unambiguous ones like Rugby (UK Parliament constituency) we'd just move this to the shorter Rugby (constituency). I guess that's a separate proposal though.  — Amakuru (talk) 23:14, 9 November 2025 (UTC)[reply]

  @Amakuru: Moving Rugby (UK Parliament constituency) to Rugby (constituency) is what is being proposed in this proposal, that is to say omitting the "UK Parliament" part when not necessary. Cardiff Central (UK Parliament constituency) and Cardiff Central (Senedd constituency) are ambiguous so would be kept as is. Crouch, Swale (talk) 19:17, 10 November 2025 (UTC)[reply]

  @Crouch, Swale: Oh, right, that's me not reading the proposal properly! I thought we were still at the Rugby and Kenilworth (UK Parliament constituency) vs Rugby and Kenilworth stage, but now I see that that one has already been settled and I guess Rugby and Kenilworth just hasn't been moved yet. Well great. Definite support then.  — Amakuru (talk) 20:14, 10 November 2025 (UTC)[reply]

• I don't particularly mind either way, but a plea again (as with the old discussion) to leave the consistent "(UK Parliament constituency)" redirects in place whatever we do - it'll be a real headache for future editing otherwise. Andrew Gray (talk) 23:26, 9 November 2025 (UTC)[reply]
• Supoort to be logically consistent with disambiguation across other topics- the qualifier is only as long and detailed as is necessary to distinguish it from other topics. Mdewman6 (talk) 00:17, 10 November 2025 (UTC)[reply]
• Support(Thanks for the ping). There is no reason to have Uk parliament noted in the title if it is not necessary and if there is only one constituency full stop then it is not necessary so we should remove that from the titles and so I support this proposal.GothicGolem29 (Talk) 02:51, 10 November 2025 (UTC)[reply]
• Comment I am a man of simple means. When Wikipedia had no constituency articles at all, editors came together to formulate what would become the UK politics project, and using the Wikipedia culture of the time, chose the disambiguation technique because it was the only tool we thought would be accepted by the wider community. As the project expanded we thought consistency mattered so extended the format to Scotland, Wales (Assembly and Senedd) etc. I'm fully aware that the tide has turned and I won't try to protest too much against what I consider a dismantling of the consistency model. All I ask is that the new naming fformat, and crucially the redirects, don't cause confusion or misunderstanding. Use (UK Parliament constituency) unless you absolutely cannot; use (Scottish Parliament constituency) unless you absolutely cannot. As the next wholesale boundary review could be a decade away if it happens at all, we might not have to look at the wider consequences of our decision here for some time doktorb _words^deeds 15:30, 10 November 2025 (UTC)[reply]
• Support (Summoned by bot) Correctly calibrating disambiguation is tough but I think this change makes sense and fits the policy. Smallangryplanet (talk) 20:24, 10 November 2025 (UTC)[reply]
• Support, provided that there is no conflicting name in another country that even sometimes uses the term constituency for their electoral districts. In Canada, for example, the term electoral district is used in legal contexts at the federal level, and at the provincial level, terms like electoral district or electoral division are used for legal purposes; however, outside of legal contexts, constituency (or riding) is commonly used. Graham11 (talk) 00:36, 11 November 2025 (UTC)[reply]

But preferably mark NCUKPARL as historical per Extraordinary Writ. Graham11 (talk) 02:41, 12 November 2025 (UTC)[reply]

• Just get rid of NCUKPARL, as the closer of the previous RfC originally interpreted the consensus. In practice that's no different than this proposal (so I'll stick in a bolded support as a second choice), but if we all want to treat UK constituencies the same way we treat any other kind of constituency, we don't need the clutter of a separate guideline for them. Extraordinary Writ (talk) 00:55, 11 November 2025 (UTC)[reply]
• Support per unnecessary disambiguation. I also Support Extraordinary Writ’s astute proposal to remove the guideline in question entirely, since this proposal obviates the only content the guideline has. В²C ☎ 05:08, 11 November 2025 (UTC)[reply]

WP:TITLESPECIALCHARACTERS says to use redirects when characters not on a standard keyboard appear in titles. I wrote a script to make sure this is happening, but for some characters it's unclear what the standard-keyboard equivalent should be, or if the character should be removed from the title and replaced with a word or letters (for example by Anglicizing). This happens in a lot of proper nouns, including people's names, place names, and titles of musical works. The most common cases include these characters:

• Currency symbols not on my keyboard: ¢ ¥ £ €
• þ - Thorn (letter)
• ǀ - Dental click
• ǁ - Lateral click
• ǂ - Palatal click
• ʔ - Glottal stop
• ° - Degree symbol
• Ə ə - Schwa, used in a lot of Azerbaijan place names
• Should ǃ (Alveolar click) be changed to ASCII ! in the title, or should I make redirects from ASCII !?
• Should ß be converted to ss in the title, or should I make redirects with ss?

Any thoughts about how to align these titles with the guideline? -- Beland (talk) 01:26, 23 November 2025 (UTC)[reply]

My thoughts at this time are that: (1) "th" is probably the best standard-keyboard equivalent to the thorn; (2) the apostrophe is probably a good standard-keyboard equivalent for the glottal stop character; (3) the alveolar click should be in the title, with the ASCII ! as a redirect, so that the title most precisely captures the character that's used; (4) for the same reason, ß shouldn't be converted to ss in title, assuming there aren't other considerations (e.g. COMMONNAME) that would direct us otherwise. The handling of currency symbols is probably going to vary on a case-by-case basis. For the points I haven't addressed, I don't have immediate opinions at this time, but I'll think on it some more and see if any opinions come to me. ModernDayTrilobite (talk • contribs) 04:58, 23 November 2025 (UTC)[reply]

OK, I put those recommendations into my code. I realized I can check for multiple inbound redirects, so for ʔ I put both ' and ?, the latter just based on visual confusion. Azerbaijani seems to mostly transliterate ə as a, so I put that in as well as e based on visual confusion. ¢ gets transliterated as "cents" pretty much uniformly in redirects, so that's taken care of. I was able to move €STR to an expansion of that acronym. That leaves:

• ¥$
• ¥€$
• A bunch of articles with clicks
• A bunch of articles with °
  • A lot have geographic coordinates disambiguating them, like: Gholamabad (32°29′ N 50°15′ E), Kuhrang
  • Some are just weird proper nouns like Anderson Cooper 360°
• A bunch of articles with £, e.g.:
  • £sd - could rename "Pound-shilling-pence"?
  • The Royal Bank of Scotland £100 note - could change to "100-pound note"?
  • The £20,000 Kiss

British pounds are a bit weird because I'm sure lots of English speakers have a button for that symbol on their keyboards, but American English keyboards don't. But I guess that's "not on a standard keyboard" for enough English speakers to qualify as needing redirection? -- Beland (talk) 09:25, 25 November 2025 (UTC)[reply]

I don't know, would it be seen as amerocentric if the dollar sign $ were to be considered a key that is "on the standard keyboard" but the pound sign £ were not? The $ also being used in CAN, AUS and NZ notwithstanding, I still think it could be seen that way, but I'm not sure. FWIW, my typewriter's keyboard has both $ and £; not sure why computer keyboard's seemingly can't.

Most mobile keyboards nowadays also come with all of the above currency symbols, and even with þ and ß. And inferior though it might be, mobile editing is bound to become more prevalent as time goes on.

Also, ModernDayTrilobite, your suggestions on which chars to substitute and which ones not to substitute seen somewhat arbitrary, but I'm sure there's likely some reasoning that I'm missing. Why swap out the glottal stop letter for an apostrophe but not the dental click with an exclamation point, while the latter two look identical and the former two look nothing alike? Or why allow ß but not þ when neither are on any English desktop keyboards (and both are now typically on English mobile keyboards? ~2025-35317-03 (talk) 21:10, 28 November 2025 (UTC)[reply]

According to QWERTY and List of QWERTY keyboard language variants, UK keyboards do have both $ and £. It's arguable whether or not keyboard manufacturers are Americentric or not. Either way, it appears there are no standard English-language keyboards where "$" is missing, and £ is not found on "most" English keyboards, if we're counting by users (since most of them are American).

For clarity, I think it would make sense to change "most English-language keyboards" to "the ANSI standard US keyboard" which is this:

The standard UK keyboard seems to be this one:

It adds a bunch of letters with diacritics for which we actually still want redirects from the ASCII base letter. It also adds € and £. Would it be OK to add an exception for £, and assume that Americans will figure out how to type it? The only reasonable redirect replacement I can think of would be the appropriate currency code like "GBP".

For "¥$", there is a link from YS and for ¥€$ there is a link from Yes, so I think those are taken care of (leaving no cases remaining for the Euro sign). For clicks, I'll add "I" for dental, "II" for lateral, and the empty string for palatal. Any objections? -- Beland (talk) 22:58, 28 November 2025 (UTC)[reply]

Oh, and I understood the above as keeping both þ and ß in article titles, but adding redirects from "th" and "ss", respectively. -- Beland (talk) 23:03, 28 November 2025 (UTC)[reply]

@~2025-35317-03: To clarify a few points about my previous answer—when I suggested alternatives to þ and ʔ, I didn't mean to suggesting that those characters be disallowed from appearing in article titles. Rather, I was just proposing standard-keyboard alternatives that could redirect to titles that incorporate those characters. Generally speaking, my inclination is that the "true" title should be as orthographically accurate as possible and that standard-keyboard alternatives should just be redirects to make those articles easier to navigate to. (As for why I chose the apostrophe as an alternative to the glottal stop, it's mainly to parallel the languages that use apostrophes (or similar-looking characters like the 'okina) to represent glottal stops in Latin text.) ModernDayTrilobite (talk • contribs) 02:21, 30 November 2025 (UTC)[reply]

In June, the technical possibility of displaying quotation marks in titles (without changing the page name) popped out, and since then I and others have applied the {{Verbatim title}} template to a few pages, like “The enemy of my enemy is my friend”. I am not talking about using page names containing quotation marks (these should remain forbidden, with few exceptions), but about displaying quotation marks.

I believe that whoever wrote this policy long ago was referring to how the page is named (internally), not about how the title is displayed. I am not even sure they knew at that time that {{DISPLAYTITLE:}} allowed the insertion of the <q>...</q> tag—and I am not even sure whether it did actually allow that, back then. Therefore, I interpret the current policy as being permissive concerning the displaying of quotation marks in titles—after all, what is the difference if we display them also in the title, when we already display them in the first paragraph?

Recently, however, this possibility has been contested, and so we would need to find consensus if we want the policy to state explicitly that displaying quotes in page titles (without actually changing the page name) is possible.

Hence the final question: How should we deal with displaying quotation marks in titles? --Grufo (talk) 02:06, 25 November 2025 (UTC)[reply]

The templates you have created - minor detail you failed to tell - add absolutely nothing and are superfluous. There is no problem to fix. The Banner talk 02:42, 25 November 2025 (UTC)[reply]

@The Banner: Thank you for your opinion on the templates I create. But now back to the original question: What do you think we should do when a page is named after a verbatim quotation? And why? --Grufo (talk) 02:54, 25 November 2025 (UTC)[reply]

There is no issue that needs to be solved. The Banner talk 03:07, 25 November 2025 (UTC)[reply]

Not sure why you are here for then? --Grufo (talk) 03:15, 25 November 2025 (UTC)[reply]

Because I object against your actions. The Banner talk 17:04, 25 November 2025 (UTC)[reply]

Solution without a problem. Oppose any chance to current policy. Zackmann (^{Talk to me}/_{What I been doing}) 03:17, 25 November 2025 (UTC)[reply]

There is no oppose/support here. The policy is not clear, because it is safe to assume that it did not know about the possibilities that {{DISPLAYTITLE:}} offers. Hence the question is not whether we should amend the policy, but what we actually want to do with with pages whose titles contain verbatim quotations, whether we should display the quotation marks (via {{DISPLAYTITLE:}} and the <q>...</q> tag) or not, and why. --Grufo (talk) 03:26, 25 November 2025 (UTC)[reply]

I oppose any change to current policy. The fact that you don't like my stance doesn't make it invalid, Let it go and quit BLUDGEONING the process. Zackmann (^{Talk to me}/_{What I been doing}) 03:30, 25 November 2025 (UTC)[reply]

I will currently oppose the proposal here on technical grounds. I believe this change requires an RfC as this changes fundamentally how our pages look, so this needs a project-wide consensus and not a minor quorum. I would like to challenge this: In June, the technical possibility of displaying quotation marks in titles (without changing the page name) popped out, did we not have the technical capabilities before June to do this? Could you please link to whatever place I can read where it shows where the MediaWiki software was updated? Gonnym (talk) 12:11, 25 November 2025 (UTC)[reply]

You got me digging. This is all I found (which is actually quite a lot):

1. Wikipedia talk:Article titles/Archive 50#Quotation marks in article titles using <q> tag, redux (January 2015)
2. Wikipedia talk:WikiProject Doctor Who/Archive 30#Quotation marks in article titles (January 2015)
3. Wikipedia talk:WikiProject Tree of Life#Candidatus discussion (August 2025)

Strangely enough, I was already agreeing with you that this discussion cannot be solved on a random talk page without an RfC, when I saw that this is the very same place in which the topic has already been discussed once (#1) via RfC. That discussion however ended with mixed positions and no consensus. Some of the “oppose” arguments however no longer apply (“inconsistent browser support”), other instead seem circular: they invoked the policy that stated that titles should not be enclosed in quotes, although that discussion was eventually supposed to edit that very policy. A good read in general. Interestingly enough, it leaves open the question whether {{DISPLAYTITLE:}} supported quotes when the policy was created – so that we can finally understand whether the policy contemplates {{DISPLAYTITLE:}} at all. --Grufo (talk) 15:10, 25 November 2025 (UTC)[reply]

You fail over and over again to understand what I write. I was almost agreeing with you that this discussion cannot be solved on a random talk page. I did not write that it can't be on a random talk page but I said this change requires an RfC as this changes fundamentally how our pages look, so this needs a project-wide consensus and not a minor quorum. Before jumping to change policies, maybe familiar yourself with how en.wiki works? For reference, I was talking about WP:RFC.

Secondly, That discussion however ended with mixed positions and no consensus is a horrible reading of a very plain text. Wikipedia_talk:Article_titles/Archive_50#RFC: Quotation marks in displayed article titles clearly says: Clear consensus is against this. Not mixed positions or no consensus, but a Clear consensus is against this.

Finally, the above links you provided showed that In June, the technical possibility of displaying quotation marks in titles (without changing the page name) popped out was incorrect. We had this method since 2014.

So if you want to continue with this path, you should start an RfC, show in your arguments what has changed since the last RfC and why you think this is better. Remember that any change to this page impacts countless articles. Gonnym (talk) 15:24, 25 November 2025 (UTC)[reply]

“Finally, the above links you provided showed that "In June, the technical possibility of displaying quotation marks in titles (without changing the page name) popped out" was incorrect. We had this method since 2014.”: Quite a movie you are staging in your head alone. You first assume I said that we did not have this possibility before June (which I didn't say), and then you conclude that I was wrong at saying that. The only thing I said is that in June this possibility popped out. Honestly, my guess was that {{DISPLAYTITLE:}} has been supporting this for quite a while. Yet, as I often mentioned, I also wondered (and I still do) whether that was the case also when the policy page was written. I also happened to know about the August 2025 discussion already, because it backlinked to my template—and so it always seemed plausible to me that someone had wondered about the same thing before. I did not know however there had been an RfC about it in 2015.

P.S. Your quoting of my words might not be up to date – I apologize, my message got through several rearrangements as I was digging through the past. You should always make sure though that your quoting is up to date before publishing, especially if you are going to use a harsh tone. --Grufo (talk) 16:43, 25 November 2025 (UTC)[reply]

Focusing on substance rather than formalism, history, or user conduct: I'm inclined to think that things which look on-screen just like ordinary selectable text should be ordinary selectable text. The use of <q>...</q> produces quotation marks that are visible but not highlightable with the desktop mouse or mobile web long-press. Example. This is not the behavior people are accustomed to. Furthermore, the behavior is subtly inconsistent between browsers, in that Chrome copy-paste does not pick up the quotation marks, while Firefox copy-paste can pick up the quotation marks despite not being highlighted during selection.

It could be argued that this is only a minor downside. On the other hand, what are the upsides, and why are they greater? Why and when is DISPLAYTITLE <q>...</q> not merely possible but preferable to the longstanding absence of it? That's what a proposal should argue. Until such an argument is articulated, or if at bottom it eventually comes down to subjective aesthetic preference on either side, then I won't be surprised to see more "solution looking for a problem"-type votes. Adumbrativus (talk) 03:28, 26 November 2025 (UTC)[reply]

Thank you for bringing the discussion back to the topic. The question you pose about whether it is preferable, not just possible, for me has a clear answer: Definitely yes. Without it, there will always be a mismatch between the page lead ("The enemy of my enemy is my friend" is an ancient proverb which suggests …) and the page title. You could argue that if we introduce the change there will then be a mismatch between the displayed title and the page name, however people are used to that already, at least for what concerns italicization (see page names like IPhone, EBay, and others). Pages with mismatch between page lead and the page title will still continue to exist (see for instance DK King of Swing); however these cases can be motivated with the fact that there is no technical solution for them, and if there were, they would implement it too. As for the fact that the quotes are not selectable, I would say that part belongs to personal taste. However it is not unheard of on Wikipedia: the |quote= parameter of the {{Cite book}} template, for instance, does the same. --Grufo (talk) 04:24, 26 November 2025 (UTC)[reply]

There is a large volume of AfD's at Wikipedia:WikiProject Deletion sorting/Disambiguations regarding non-Latin names such as 大田 and 강동호, which are not always romanized consistently. I think there is confusion over the applicability of WP:ENGLISHTITLE, since disambiguation pages are outside of the scope of this policy, but this is not clear as written. It is also inconsistent to allow foreign-language redirects but not foreign-language disambiguation pages. –LaundryPizza03 (dc̄) 05:13, 25 November 2025 (UTC)[reply]

I see what you mean about redirects and disambiguation pages being similar, in that both can try to help readers who have input text in a non-Latin writing system to navigate to an English-title article. They are slightly different in that a redirect immediately brings the reader to a page with a Latin-character title, giving them something they can pronounce and type in to come back later.

One solution that would make it easier for editors to navigate to these disambiguation pages from Latin-character input (which is presumably what English speakers are most capable of) would be to redirect them to the most common transliteration, and note additional transliterations in the text introducing the list.

Given how many millions of topics we cover, it seems in nearly all cases we have already found some way to not use titles in an untypeable (for English speakers) writing system. I only see 18 more unnominated article-space pages with Hangul, and only a couple with kana. I don't see any remaining untransliterated disambiguations in other major writing systems like Greek, Hebrew, Arabic, or Cyrillic. There are many articles on surnames and disambiguation pages with Chinese characters in the name, but it seems if there's a long list of things that could be looked up with sequences of Chinese characters, at some point the Chinese Wikipedia is supposed to be handling that. If English Wikipedia isn't going to try to allow readers to look up any English-language article with words in any writing system, a line needs to be drawn somewhere, and only going as far as redirects from languages that have strong ties to a topic seems not unreasonable.

Long story short, I think we can get English-speaking readers where they need to go without using non-Latin characters to title disambiguation pages. But if we decide to allow them explicitly, it should also be made explicit that non-Latin characters are also allowed in redirect titles but not the titles of lists, outlines, and indexes, even though those are also not articles. (And I assume not allowed for portals and categories, even though those are not in the article namespace?) -- Beland (talk) 09:00, 25 November 2025 (UTC)[reply]

Non-Latin disambiguation pages are appropriate in circumstances as I once articulated at Wikipedia:Articles for deletion/神戸駅 (2025): "The non-English term is closely connected with the targets, as it is the name in the native language. When there is only topic, or a single primary topic, such a redirect is proper and at RFD would be kept; when there is no clear primary topic, a disambiguation page is similarly proper for navigation. When possible we would redirect to a disambiguation page with a Roman alphabet title, but here no such title is adequate because the same characters have multiple dissimilar readings (Godo (Gunma), Kambe, and Kobe Station)."

In practice, these circumstances are much more likely to occur for Chinese characters than any other common writing system. For native names in kana, the Greek alphabet, etc., I imagine the need for an unromanized disambiguation page title is unlikely to occur, if ever. The difference is because of the non-alphabetic multilingual nature of Chinese characters, creating dissimilar readings across (or within) Chinese, Japanese, and Korean. For another example: 板橋 = Banqiao = Itabashi = Pangyo (Wikipedia:Articles for deletion/板橋 (2023)). Discussion about Chinese character disambiguation page titles has repeated over the years (e.g.: Wikipedia:Articles for deletion/江南 (2020) and other discussions linked from there; Wikipedia:Articles for deletion/松山 (2013)) and has shown lasting support for the principles behind keeping them. Adumbrativus (talk) 12:03, 25 November 2025 (UTC)[reply]

It looks like making an exception for Category:Disambiguation pages with Chinese character titles makes sense, as there are incompatible romanizations for different readings, and AFDs for those are trending toward keep. But hangul are alphabetic, and the AFDs for those are trending toward delete. -- Beland (talk) 00:01, 29 November 2025 (UTC)[reply]

There is no agreement on how Korean should be romanized, there are multiple different competing systems and even on English Wikipedia we use all of them. One name might be the primary topic for one romanization, one another, meanwhile they are all identical in Korean. It is untenable to not have disambs while allowing foreign language redirects. PARAKANYAA (talk) 01:54, 2 December 2025 (UTC)[reply]

For further information, see MOS:KO-ROMAN. PARAKANYAA (talk) 01:57, 2 December 2025 (UTC)[reply]

Other languages also have multiple romanizations, and seem to have gotten by without non-Latin disambiguation pages.

One solution based on MOS:KO-ROMAN would be to use Revised Romanization as the title, and redirect other romanizations to that disambiguation page. Many disambiguation pages have incoming redirects that don't match the title, and have a mix of articles with overlapping confusion. For example, aa and Double A, among others, both redirect to AA, which lists articles with a mixture of capitalizations and additional characters, for example: ʻAʻā, A∴A∴, and Van der Aa.

We actually already do this with some Korean strings. For example, GIM includes both Gim (food) and Kim (Korean surname). This is helpful because readers will be looking up the wrong romanization for any given article in both directions, so there might as be one list. It would be feasible to merge and redirect 김 to GIM. I think that would be an improvement because "김" is currently not mentioned there. -- Beland (talk) 03:30, 2 December 2025 (UTC)[reply]

For my own future reference, it's Wikipedia:Articles for deletion/大田 that closed as keep. -- Beland (talk) 03:37, 2 December 2025 (UTC)[reply]

I personally disagree with the outcome of some of these AFDs. Under policy we should not have any pages (other than redirects) that don't use the Roman alphabet. Period.4meter4 (talk) 05:39, 10 December 2025 (UTC)[reply]

How many times do I have to explain that there is no such policy? Toadspike [Talk] 08:50, 10 December 2025 (UTC)[reply]

The relevant policy, as far as I can tell, is WP:TRANSLITERATE. It did say "articles" and not "pages in article namespace", so it was a bit unclear whether it had consensus to apply to all non-redirect pages in article namespace. Sometimes policy is made in a bottom-up manner; I added clarifications based on recent AFDs and another discussion about exceptions for disambiguation pages and single letters with no dominant name. Policy can also be made in a top-down manner. If there is desire to establish a site-wide consensus that overrides these local consensuses, my recommendation would be to start an RFC on this talk page. -- Beland (talk) 11:09, 10 December 2025 (UTC)[reply]

The example of Rhode Island for WP:CONCISE is outdated. A potential new example is Hamburg and Free and Hanseatic City of Hamburg. John Smith Ri (talk) 14:57, 14 December 2025 (UTC)[reply]

I don't think that would be a good example as the shorter name appears to be for the settlement and the longer name the administrative unit. Crouch, Swale (talk) 23:44, 17 December 2025 (UTC)[reply]

I was hoping this would not be controversial, but I do not think it is appropriate to use Bill Clinton and J.K. Rowling as examples in this section. I made a BOLD change to mostly arbitrary but still famous examples of the same issues, Bill Hader and N.K. Jemisin. This change was reverted because Bill Clinton and J.K. Rowling are pages with higher daily page views and "it's better to stick with the higher-pageview ones that are likely more familiar to readers". While I concede Bill Clinton and J.K. Rowling are highly-visited pages (so much so that it is much less feasible to seek out alternatives with that additional criteria), I do not think Wikipedia should use them as examples in a policy document because they are both highly controversial figures. Bill Clinton is tied to the Epstein Files in a serious way, to say nothing of the (ongoing, really) controversies of his presidency related to his restrictive reforms to criminal law and welfare. J.K. Rowling is as famous now for her transphobia as for Harry Potter. Because the examples on this page are practical, I do not think curation based on page views is a good enough reason for the page to stay as it is. The reader of this policy understands what is meant by "Bill, not William" and "author initials, not full author name." The reader would understand this even if they had never heard of the example before. Reminding the reader of these controversies in the context of this page is entirely unnecessary, and alternatives should be chosen. Courtesy ping for @Extraordinary Writ:. lethargilistic (talk) 19:37, 24 December 2025 (UTC)[reply]