The project page associated with this talk page is an officialpolicy on Wikipedia. Policies have wide acceptance among editors and are considered a standard for all users to follow. Please reviewpolicy editing recommendations before making any substantive change to this page. Always remember tokeep cool when editing, anddon't panic.
I have been informed byRoyiswariii onTalk:Ronald dela Rosa# Requested move 7 September 2025 thatWP:RMs have been closed on arguments that what was used was how the subject was named on the sources' title vs. how it was actually referred to in the prose. This can be an issue if the names used on the sources' headline/title is different from how it is written in the prose; usually the names on headlines/titles are shorter or abbreviated. Is this the correct interpretation?Howard the Duck (talk)12:28, 15 September 2025 (UTC)[reply]
The following discussion is an archived record of arequest for comment.Please do not modify it. No further edits should be made to this discussion.A summary of the conclusions reached follows.
After nearly two weeks of discussion, I think it's safe to say that it'sWP:SNOWing unseasonably early in Essex this year. There is a clearconsensus in favour of the proposed change to remove unncessary disambiguators from articles on parliamentary constituencies, per our main guidelines on article titles and disambiguation.There is thus consensus to overturnWP:NCUKPARL, which I will mark historical. After discussion on my talk, I have restored NCUCKPARL, modified to be in line with this consensus.(non-admin closure)Cremastra (talk·contribs)22:50, 14 October 2025 (UTC)[reply]
Should the titles of articles about parliament constituencies (e.g.in Essex) always contain the parenthetical "(UK Parliament constituency)" or only when one is needed for disambiguation?Surtsicna (talk)00:27, 2 October 2025 (UTC)[reply]
Only when needed, i.e., overturnWikipedia:Naming conventions (UK Parliament constituencies). PerWP:PRECISION,titles should unambiguously define the topical scope of the article, but should be no more precise than that. I've seen no good justification for departing from this baseline:WP:CONSISTENT is fairly clear it doesn't call for this, and I don't agree that recognizability is such a major concern here as to require such an unusual step. This rule has always been a dubious one built on what I would consider local consensus (as JHunterJ valiantly arguedback in 2014), and I'm glad that the community has been moving away from it recently, for instance bydeclining to extend it outside the UK context. We should get rid of it altogether.Extraordinary Writ (talk)01:21, 2 October 2025 (UTC)[reply]
Only when needed. I can see the utility of preemptive disambiguation for some cases, such as when the disambiguation is sufficiently short or natural (e.g., I have no problem withToyota Prius being the article title overPrius). But I don't see any particular advantage to taking that approach here; parenthetical disambiguation is one of the least natural DAB options, and this particular disambiguator is close to twenty-five characters long. In cases where it's not actually needed for understanding, we should go ahead and jettison it.ModernDayTrilobite (talk •contribs)13:38, 2 October 2025 (UTC)[reply]
Only when needed. I view any naming convention or other guideline that calls for an article title to be "X (Y)" when there are no other uses of X to conflict withWP:AT policy, specificallyWP:QUALIFIER, which states that only topicscovered in Wikipedia should be disambiguated with parenthetical disambiguation (and then, only when other forms of disambiguation aren't appropriate). In such a case, there is no appropriate place for thebase name to go. It can't be a disambiguation page, because such a page would have only one blue link, and it shouldn't redirect to the disambiguated title for reasons discussed atWP:MISPLACED. Note that the other classic example cited atWP:PRECISION regading Michigan state highways still exists atWikipedia:Naming_conventions_(U.S._state_and_territory_highways), andWP:NCEPISODE was recently revised to allow for including the TV show in parentheses for numbered episodes even when there is no other use of the base name, allowing the base name to be MISPLACED or even not exist at all, which is counterintuitive to how parenthetical disambiguation works. I believe all of these naming conventions should be changed as they currently conflict with AT policy.Mdewman6 (talk)22:29, 2 October 2025 (UTC)[reply]
Only when needed. I've always found the UK method of constantly, unceasingly adding the disambiguation to be very off, and rather out of step with other naming conventions. Having the disambiguation would beWP:CONSISTENT, yes, but it's equally important that they beWP:NATURAL, which this is not. In lots of cases, the article title can only be referring to a parliamentary constituency and the name can just be the name. Disambiguation should obviously be kept for things likeGrampound (UK Parliament constituency) andGrampound.DimensionalFusion (talk · she/her)23:16, 2 October 2025 (UTC)[reply]
Only when needed; not convinced that it's necessary to break our general guidelines around disambiguation here (especially as it's not natural disambiguation).Elli (talk |contribs)23:56, 2 October 2025 (UTC)[reply]
Only when needed – There is no reason why parliamentary constituencies would be an exception from our general titling rules. We don't include parenthetical disambiguators when no disambiguation is required.Graham11 (talk)03:07, 6 October 2025 (UTC)[reply]
Only when needed, I wondered why it was like this when I saw some pages like this a while ago but did not look into it. If it is the only thing with that name then there is no need for parenthetical disambiguationYoblyblob (Talk) :)14:35, 8 October 2025 (UTC)[reply]
As long as the disambiguated titles are always blue links I don't have a strong opinion about whether they're articles or redirects.Thryduulf (talk)17:36, 8 October 2025 (UTC)[reply]
I would agree with @Thryduulf I think, no strong opinion, but keep the redirects if we do change.
In practice I think we've found having a consistent disambiguation has been very useful for editors working in this area (myself included), as well as those linking to our content from outside, since it avoids having to constantly check what form is being used for a given seat. However, that shouldn't be a blocker to moving pages - redirects and piped links mean that as long as we can rely on the old style (UK parliament constituency) titles existing as redirects then it doesn't matter so much what title the pages actually live at.Andrew Gray (talk)12:17, 11 October 2025 (UTC)[reply]
The discussion above is closed.Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
Currently, the naming convention calls for articles about state highways in Kansas and Michigan to be titledK-X (Kansas highway) andM-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 beNorth Carolina highway X andPuerto 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 wasan ArbCom case in 2006. Nevertheless, the Michigan highway convention became an example of local consensus for unnecessary disambiguation atWP:PRECISION, calling for inclusion of the parenthetical qualifier even if thebase name of "M-X" does not have other meanings covered in Wikipedia. Giventhe recent RfC regarding the naming convention for parliamentary constituencies, which was the other such example atWP: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 ofKansas highway X orMichigan highway X (Option 1), thus utilizingWP:NATURAL disambiguation as is done for all other states and territories.Kansas state highway X orMichigan 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 perWP:CRITERIA and particularlyWP: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, perWP: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 withWP: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 perWP:SMALLDETAILS instead). But there are dozens of cases where the "K-X" or "M-X" base names areWP: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.
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]
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 sinceWP: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 Kansasmutatis 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 perWP: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]
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 Ido 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 atWP:RFAR/HWY and ArbCom didn't impose the current guideline in the first place—theyencourage[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 haveencouraged 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 atWP:HJP orWP: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 any option that brings that guideline into compliance with theWP: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 thebase titles of the highway articles are more recognizable on their own, option 2 may also work. –Gluonztalkcontribs14: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 suggesteddoes 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.SounderBruce06:12, 18 November 2025 (UTC)[reply]
That was a guideline, not a policy; and it was a guideline that contradicted policy.The RfC has overturned it; the consensus was unanimous. I would ask fellow editors to help with moving more pages to titles that conform to WP:AT policy.Surtsicna (talk)23:32, 23 October 2025 (UTC)[reply]
I refute that decision which was not made by wide enough discussion (did you consult the UK politics project group members?). I'm trying to revert changes nowdoktorbwordsdeeds23:34, 23 October 2025 (UTC)[reply]
It feels like every single decision we made, in good faith, are now reversed by future editors who don't know or don't understand the project, or the reasons we made those decisions. We put in so much effort to standardise constituency articles across Wikipedia. This isn't the first time I've wondered why we put in such effort. I'm very deflated, again, by a decision which ends a long standing period of standardisation.doktorbwordsdeeds23:46, 23 October 2025 (UTC)[reply]
Support it makes no sense to have a title likeClacton (UK Parliament constituency) orLeeds North West (UK Parliament constituency). While it could be argued thatLeeds 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 soGeorgia (U.S. state) would be the exception whileNew York (state) andWashington (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, 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.DankJae22: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]
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 timedoktorbwordsdeeds15:30, 10 November 2025 (UTC)[reply]
Support, provided that there is no conflicting name in another country that even sometimes uses the termconstituency for their electoral districts. In Canada, for example, the termelectoral district is used in legal contexts at the federal level, and at the provincial level, terms likeelectoral district orelectoral division are used for legal purposes; however, outside of legal contexts,constituency (orriding) is commonly used.Graham11 (talk)00:36, 11 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 boldedsupport 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 alsoSupportExtraordinary 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:COMMONNAME and article traffic as a factor to consider
Should or does which article name actually sees the most usage by readers factor? Discussion related to a proposed merger, and which direction to merge to, or whether we should merge to a new name. —Very Polite Person (talk/contribs)17:59, 13 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:
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 toss 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ə asa, so I put that in as well ase 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:
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]
In June, thetechnical 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 toa few pages, like “The enemy of my enemy is my friend”. I am not talking about using pagenames containing quotation marks (these should remain forbidden, with few exceptions), but aboutdisplaying quotation marks.
I believe that whoever wrotethis policy long ago was referring to how the page isnamed (internally), not about how the title isdisplayed. 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 concerningthe 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 possibilityhas been contested, and so we would need to find consensus if we want the policy to state explicitly thatdisplaying quotes in page titles (without actually changing the page name) is possible.
@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 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 will currentlyoppose 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):
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 quoteswhen 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 beon a random talk page but I saidthis 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 aboutWP:RFC.
Finally, the above links you provided showed thatIn 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 possibilitypopped 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 casealso 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 merelypossible butpreferable 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 ispreferable, not justpossible, 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 ancientproverb which suggests …) and the page title. You could argue that if we introduce the change there will then be a mismatch between thedisplayed title and thepage name, however people are used to that already, at least for what concerns italicization (see page names likeIPhone,EBay, and others). Pages with mismatch between page lead and the page title will still continue to exist (see for instanceDK 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 atWikipedia: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 ofWP: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. Thereare 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 drawnsomewhere, 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 atWikipedia: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 inkana, theGreek 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]
You are invited to join the discussion atTalk:Violations of non-combatant airspaces during the Russo-Ukrainian war (2022–present) § Requested move 26 October 2025. –Gluonztalkcontribs01:00, 27 October 2025 (UTC)[reply]
