Jump to content

Wikipedia:Village pump (proposals)/Archive 198

Add links
From Wikipedia, the free encyclopedia
Village pump (proposals) archive  

This page contains discussions that have been archived from Village pump (proposals). Please do not edit the contents of this page. If you wish to revive any of these discussions, either start a new thread or use the talk page associated with that topic.

< Older discussions · Archives: A, B, C, D, E, F, G, H, I, J, K, L, M, N, O, P, Q, R, S, T, U, V, W, X, Y, Z, AA, AB, AC, AD, AE, AF, AG, AH, AI, AJ, AK, AL, AM, AN, AO, AP, AQ, AR · 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, 63, 64, 65, 66, 67, 68, 69, 70, 71, 72, 73, 74, 75, 76, 77, 78, 79, 80, 81, 82, 83, 84, 85, 86, 87, 88, 89, 90, 91, 92, 93, 94, 95, 96, 97, 98, 99, 100, 101, 102, 103, 104, 105, 106, 107, 108, 109, 110, 111, 112, 113, 114, 115, 116, 117, 118, 119, 120, 121, 122, 123, 124, 125, 126, 127, 128, 129, 130, 131, 132, 133, 134, 135, 136, 137, 138, 139, 140, 141, 142, 143, 144, 145, 146, 147, 148, 149, 150, 151, 152, 153, 154, 155, 156, 157, 158, 159, 160, 161, 162, 163, 164, 165, 166, 167, 168, 169, 170, 171, 172, 173, 174, 175, 176, 177, 178, 179, 180, 181, 182, 183, 184, 185, 186, 187, 188, 189, 190, 191, 192, 193, 194, 195, 196, 197, 198, 199, 200, 201, 202, 203, 204, 205, 206, 207, 208, 209, 210, 211, 212, 213, 214, 215

Project-independent quality assessments

APPROVED
Strong support and no objections, so the project to implement it will proceed. Discussion on technical implementation has started at Template talk:WikiProject banner shell/Archive 6#Move article quality rating into banner shell. Thank you to all participants in this discussion. Aymatth2 (talk) 14:18, 13 February 2023 (UTC)

The following discussion 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.

See Wikipedia:Village pump (idea lab)#Project-independent quality assessments for discussion on this concept.

Quality assessments define how close we are to a distribution-quality article in terms of completeness, organization, prose quality, sourcing, wikilinks etc. Most projects follow the general guidelines at Wikipedia:Content assessment, but some large projects have specialized assessment guidelines. This is to propose adding a |class= parameter to {{WikiProject banner shell}}, which can display a general quality assessment, and letting project banner templates "inherit" this assessment. {{WPBannerMeta}} will look after the details, so the project banner templates will not have to change.

Projects with specialized quality assessment approaches, which will be recognized by {{WPBannerMeta}} using a new |QUALITY_CRITERIA=custom parameter, can continue to record these assessments on their project banners and link to their specialized quality assessment scales.

Importance assessments are project-specific, showing how important the article is in providing complete coverage of the project subject area. An article may be high importance for one project, low importance for another, and irrelevant to most projects. This proposal does not affect importance assessments.

Banners using article-level general quality assessment are illustrated below:

  • {{WikiProject banner shell}} may now accept, validate and display an optional |class= parameter as shown above.
  • {{WikiProject banner shell}} may be added to an article talk page with no wikiproject banners, in which case it will populate a general category like Category:C-Class articles
  • If a new {{WPBannerMeta}} parameter |QUALITY_CRITERIA= has the value "custom", the project class will be displayed and used to create categories as at present. The project class will be displayed even if it is the same as the article class. Projects will be canvassed to set this parameter if they want to use custom quality assessment criteria.
  • Otherwise, the project is assumed to follow the general assessment approach, which is true of most projects today
    • {{WPBannerMeta}} will retrieve the article-level |class= value (if present) using:
      {{Template parameter value|{{FULLPAGENAME}}|WikiProject banner shell||class}}}}
    • If no article-level class value is found, the wikiproject banner will be processed as at present
    • If the wikiproject banner does not supply a |class= value to {{WPBannerMeta}}, or if it supplies a value the same as the (non-blank) article-level class, the class will not be shown in the project template, since that would be redundant. The article class will be used to form categories like Category:C-Class Linguistics articles
    • If the wikiproject banner supplies a class value that differs from the (non-blank) article class value, the talk page will be placed in a tracking category and the project class will be used to form categories like Category:C-Class Linguistics articles
  • A future project may consider bulk change to remove |class= values from wikiproject banners where the value is the same as the article level class, and where the wikiproject uses the general Wikipedia:Content assessment approach. That is outside the scope of this proposal.

Project-independent quality assessments comments

Comments? Aymatth2 (talk) 17:58, 6 February 2023 (UTC)

  • @Aymatth2, it might be worth notifying major WikiProjects, especially ones with non-standard assessment criteria. — Qwerfjkltalk 18:08, 6 February 2023 (UTC)
    Not sure how to find active WikiProjects - perhaps the top 50 from Wikipedia:Database reports/WikiProject watchers? — Martin (MSGJ · talk) 18:24, 6 February 2023 (UTC)
    The first on the watchers list is inactive! But I will start working through the active projects on the list. Aymatth2 (talk) 18:33, 6 February 2023 (UTC)
    I'm a bit confused as to what this is proposing. ― Blaze WolfTalkBlaze Wolf#6545 20:29, 6 February 2023 (UTC)
    It is a way to put a general assessment of an article quality at the top of the article talk page, and let the project banners "inherit" that assessment. It saves space on the page, and makes it easier to update the general assessment. Projects can opt out and use specialized ways of assessing articles if they prefer. Aymatth2 (talk) 16:06, 7 February 2023 (UTC)
    Oh ok. Thanks for clarifying. ― Blaze WolfTalkBlaze Wolf#6545 20:42, 7 February 2023 (UTC)
  • Strongly support. This is a long-overdue simplification. There's no need for article-class to be project specific, when the assessment criteria are overwhelmingly not project specific (with a handful of notable exceptions). I especially like the fact that MILHIST can continue using its own assessment standards. I'll also note that this approach has been done on French Wikipedia for more than a decade, and always felt more "modern" to me. DFlhb (talk) 18:21, 6 February 2023 (UTC)
  • Very strong support from me too. This will simplify talk pages and reduce redundancy. — Martin (MSGJ · talk) 18:25, 6 February 2023 (UTC)
  • Strong support. The current quality assessment structure is an overly-complicated mess; the fact that there are individual assessments given for each project is just one of many ways. The vast majority of projects just copy-paste the generic criteria into their project space, which adds no value. Those with legitimate reason to continue to maintain their own criteria (for example: Wikipedia:WikiProject Highways/Assessment specifies A list of the road's junctions and landmarks, if appropriate), can still do that. -- RoySmith (talk) 18:35, 6 February 2023 (UTC)
  • Strong support. I think this is a great improvement. Updating assessments will be quicker for editors (change once, rather than for each project). The banner looks good and communicates clearly. Schazjmd (talk) 18:39, 6 February 2023 (UTC)
  • Support. Seems like an obvious change to centralize something that's almost universally the same across WikiProjects. Practical considerations: It might also be worth considering how this would affect the WP:RATER tool and whether this should affect Template:Vital article. Thebiguglyalien (talk) 19:06, 6 February 2023 (UTC)
  • Support iff the ability of certain WikiProjects to choose their own assessment is retained if they so desire. But there are many that don't seem to care and there's no need to make those projects assess everything. --Rschen7754 19:09, 6 February 2023 (UTC)
  • Support as the best of both worlds: a default which should pool resources well, with the facility to opt out when necessary. Certes (talk) 20:08, 6 February 2023 (UTC)
  • Support, right now there's generally no difference between different project's ratings, so it's superfluous to mark it in each template. I hope, though, that the technical implementation allows for easy per-project overrides; the video games project, for example, stopped using A-class 8 years ago, so it would be convenient if the template would put those articles into the GA-class video games articles category automatically instead of the deleted A-class one if another project wants to mark an article as A-class. --PresN 21:00, 6 February 2023 (UTC)
    The categorisation should not be affected by this proposal at all — Martin (MSGJ · talk) 21:05, 6 February 2023 (UTC)
  • Support with an opt-out for projects that have their own criteria. I also propose integrating things better with tools like Rater.js, which makes assessment and proper tagging much easier. SounderBruce 21:25, 6 February 2023 (UTC)
  • Support, strongly. Fundamentally, having each project evaluate an article independently is a fork, generating significant additional work for essentially no benefit. I would further support an opt-out implementation, in which projects are assumed to be okay with the project-independent assessment unless they specifically request to have their own system. I have mixed feelings about whether any projects should be allowed to have their own system. But this is unquestionably a good step along the path to unification. {{u|Sdkb}} talk 21:27, 6 February 2023 (UTC)
  • Support: this aligns with common practice, where an article is rated the same class across each project banner, even if the editor who makes this assessment is only a member of a proper subset of those WikiProjects. I think things like Milhist's BL-class are reasons for allowing projects to have custom assessments, not because this is how you'd design a system from scratch but because there are active communities that find these ratings helpful. — Bilorv (talk) 21:36, 6 February 2023 (UTC)
  • Support - I think this is a good idea as long as WikiProjects with their own more specific assessment scales are allowed to retain them, such as WP:USRD/A and WP:HWY/A. Dough4872 21:55, 6 February 2023 (UTC)
  • Support – This seems like a sensible simplification, and a reflection of how (in my experience) assessments work. I don't think any project I'm involved in uses project-specific criteria, but it's good to keep the opt-out (which, as I read it, is there in the proposal) for projects that do. Robminchin (talk) 22:02, 6 February 2023 (UTC)
  • Support – I think this is a good change per above, and WikiProject-specific ratings could still be kept. Additionally, it solves the issue of topics that do not fall under the scope of any WikiProject not having a class assessment. DecafPotato (talk) 23:54, 6 February 2023 (UTC)
  • Support I don't see how article quality would vary like importance does, so this seems like a pure upgrade to me. I've never really seen an instance of quality differing across projects. ᴢxᴄᴠʙɴᴍ (ᴛ) 00:47, 7 February 2023 (UTC)
  • Strongly Support – This proposal does a lot in an elegant way! I firmly believe this consolidation opens up an easier learning curve for newer editors: We can get comfortable with "the standard" in an incremental way, without always being pulled by multiple (competing? hard to understand?) WikiProjects. Further, as a mobile view reader and editor, I appreciate anything that 1) means less code overall for my thumbs to screw up and 2) clears up space on my tiny screen. Happy, happy all around. — LumonRedacts 01:18, 7 February 2023 (UTC)
  • Support with an opt-out if a project wants it as mentioned above. –Fredddie™ 01:20, 7 February 2023 (UTC)
  • Strong support, long overdue. CMD (talk) 01:30, 7 February 2023 (UTC)
  • support--Ozzie10aaaa (talk) 02:33, 7 February 2023 (UTC)
  • Support, definitely. Abductive (reasoning) 04:15, 7 February 2023 (UTC)
  • Support, standardization is good. EpicPupper (talk) 04:42, 7 February 2023 (UTC)
  • Comment I can see the advantages on this, with articles rated B or better being the minimum acceptable standard for DYK and ITN. The criteria do differ slightly from those that the MilHist Project is currently using. The main differences are criterion 5, where we require an infobox or images (not hard to do), and 6, which we rejected years ago. I trust that everyone understands that classification up to B is handled by our MilHistBot, so that if this proposal passes, then the MilHistBot will assign a global assessment whenever the article falls under WP:MILHIST (with criterion 6 being always assessed as true). Hawkeye7 (discuss) 05:48, 7 February 2023 (UTC)
    @Hawkeye7 I don't know what they do at ITN, but I can assure you, having a B rating or better is not a DYK requirement. All we require in the way of quality assessment is that the article isn't a stub. -- RoySmith (talk) 14:52, 7 February 2023 (UTC)
    @RoySmith: DYK Supplementary Rule D2 requires that the article be fully sourced, which is required of a B class article or better. Hawkeye7 (discuss) 18:59, 7 February 2023 (UTC)
    All articles that rate B or better will meet D2, but there's a lot of other things that B requires which DYK doesn't. -- RoySmith (talk) 20:05, 7 February 2023 (UTC)
    True, but note that DYK already has certain requirements: A1 requires a 1,500 character minimum, and D7 requires and article "to be complete and not some sort of work in progress". It is likely that if this proposal for project-wide classification is accepted, there will be a proposal to set the bar for DYK articles at B class. It is pretty much the minimum acceptable standard now anyway. Hawkeye7 (discuss) 00:26, 8 February 2023 (UTC)
    While I've for a while been a member of the "assessments don't matter" school of philosophy, I feel compelled to point out that an article can be fully sourced without meeting other B class requirements such as comprehensiveness, and that doesn't disqualify an article from DYK eligibility. Trying to require all DYK submissions to be B class is also a non-starter when different projects have very different requirements for what B class means. Trainsandotherthings (talk) 16:14, 8 February 2023 (UTC)
    Start-class articles that are fully sourced but not broad enough in their content coverage are allowed to run at DYK. I think this is a good thing; DYK isn't a mini-GA review, nor should it be. People who produce a good number of well-referenced C-class articles that fail B-class only for their breadth of coverage provide substantial value to the encyclopedia, and we need some system to reward creators while evaluating that sort of work (which is what DYK functionally is). — Red-tailed hawk (nest) 16:56, 8 February 2023 (UTC)
    Theoretically yes, but in practice articles that are fully referenced but fail one of the other B-class criteria are quite rare. Hawkeye7 (discuss) 22:49, 8 February 2023 (UTC)
    Agree (with everyone except Hawkeye7); this will never fly. Except for the GA ones, very very few DYK articles are assessed as B (although I think we have a general problem of under-rating in assessments). I'm appalled that Milhist seem (per Hawkeye7) to insist on an infobox for B-class. This should never be done. There's no chance of this being accepted at DYK. Johnbod (talk) 19:05, 8 February 2023 (UTC)
    I may have misled you. Our B5 criterion requires that an article "contains appropriate supporting materials, such as an infobox, images, or diagrams." My own article on Singapore strategy (for example) does not contain an infobox. Hawkeye7 (discuss) 22:49, 8 February 2023 (UTC)
    Phew! Glad to hear it. Johnbod (talk) 05:18, 9 February 2023 (UTC)
    From the Wikipedia:Content assessment/B-Class criteria, I can say that B1 is enforced at DYK (DYK's rules are possibly a bit more strict). The similarities do kind of end there, though: bolded articles regularly fail B2 and B5. B3, B4, and B6 are... not requirements per se, but there are a lot of cases where a reviewer rightfully wants the nominator to take the article vaguely in that direction if it's too far away, and DYK will generally uphold those requests. I mean, you could make the case that all DYK articles are B-class if you stretch them broadly enough, just because of how much hedging this guideline does. theleekycauldron (talk • contribs) (she/her) 10:09, 9 February 2023 (UTC)
  • Support – While |importance= can vary by project, |class= is one parameter that should be universal across the board. InfiniteNexus (talk) 06:22, 7 February 2023 (UTC)
  • Comment French Wikipedia does this, project independent quality setting with project dependent importance, I support this. I think this should be done as a general quality assessment, while each project should have a separate topic specific quality assessment for the topic area of each wikiproject, which generally would not be the same until it reaches A-class or FA-class, where all assessments would need to reach A-class or FA-class to meet that level. -- 64.229.90.199 (talk) 06:25, 7 February 2023 (UTC)
  • Support, yes please. Some projects will probably also want to simplify their criteria (WikiProject Germany has a B-Class checklist but doesn't have the manpower to use it properly); I guess projects should explicitly opt out of using the standard rating scale. —Kusma (talk) 09:12, 7 February 2023 (UTC)
  • I wouldn't shy from opposing this if I felt it deserved it just because 20-odd users all voted 'support' before me, but there's a good reason for that; this is a very sensible improvement, and it does deserve it. It's got my Support, too. I'll have to go find some other Rfc where I can buck the trend, but this is not the one. Mathglot (talk) 10:10, 7 February 2023 (UTC)
  • Support Absolutely. I've same reply InfiniteNexus as above. Articles and individual projects can have their own requirements if need be, but a general guideline would suffice — DaxServer (t · m · c) 15:16, 7 February 2023 (UTC)
  • Support Almost all articles I see have the same assessment for all wikiprojects anyway so this makes sense Terasail[✉️] 17:01, 7 February 2023 (UTC)
    • Some editors just unify the quality assessments across wikiprojects... so that isn't a proper indication of individual topic-area-specific quality (as opposed to general article quality) on Wikipedia right now; unless it's a few missing classes (ie bottom/low/C/A) that some projects have that others don't -- 64.229.90.199 (talk) 03:26, 8 February 2023 (UTC)
  • Strong support May we also standardise the "This article has been checked against the following criteria for B-Class status" from Template:WikiProject Film?--LaukkuTheGreit (Talk•Contribs) 18:45, 7 February 2023 (UTC)
    Can we save that discussion for later please? Baby steps ... — Martin (MSGJ · talk) 20:20, 7 February 2023 (UTC)
  • Support - Crying tears of joy. This will save untold hours of manpower. Support per User:DFlhb. Schierbecker (talk) 19:13, 7 February 2023 (UTC)
  • Strongest support possible This will make things so much easier. And some wikiprojects seem to not have some levels of criteria, leading to articles being rated as, for example, Start Class and C class at the same time. ― Blaze WolfTalkBlaze Wolf#6545 20:46, 7 February 2023 (UTC)
    A better example is that some projects still don't have Redirect-class or Disambig-class, which are shockingly still considered "Non-standard grades" (I'll propose standardization posthaste on WT:Content assessment). But newbies who don't use the Rater tool would never know it, and would be confused why 3 projects say "Redirect", and one project says "NA". DFlhb (talk) 21:22, 7 February 2023 (UTC)
  • Question How will this affect the unassessed article categories? eg. Category:Unassessed military history articles Will they still be correctly populated? Hawkeye7 (discuss) 00:15, 8 February 2023 (UTC)
    An interesting question, including the issue of what is "correct". I think the default should probably be that articles are in the "unassessed" categories if the main banner doesn't have an assessment. It shouldn't be too hard to code a category for articles that have a global assessment but not a local one (if the banner says B-Class but the checklist hasn't been filled out, perhaps you would prefer to be in an "unassessed" (or perhaps "half-assed" or something) category for MILHIST). —Kusma (talk) 09:28, 8 February 2023 (UTC)
    For projects that opt out, presumably including military history, the article will be categorized as unassessed if the project banner does not have an assessment. For other projects, if there is also no article-level assessment. Aymatth2 (talk) 14:43, 8 February 2023 (UTC)
    Speaking now as the project's lead coordinator, I am not presuming that at all; discussion is ongoing, and if the proposal passes, I will put it to the project for a vote. But this is a make-or-break criterion. We are not talking about merely changing {{WikiProject banner shell}} ! Every project that opts in will require changes to {{WikiProject banner shell}} and to its own project banner template in order for this proposal to work. We must know how many and what articles are covered by the project and what their classifications are. Unless we have a volunteer to preform a great deal of work, I strongly recommend that this be "opt-in" and not "opt-out", as someone from each project will have to work on the template. Start with {{WPBannerMeta}}. But {{WikiProject Military history}} does not use it (maybe it should) and I don't know how many projects do or do not. Hawkeye7 (discuss) 22:49, 8 February 2023 (UTC)
    Opt-in poses a problem since so many WikiProjects are inactive. Couldn't a bot deal with this effectively, avoiding the need for manual intervention? I also agree that Category:Unassessed military history articles should only show articles that have been unassessed by MILHIST (even if the WPBannerShell contains an assessment).
    BTW, I'd strongly support WP:Content assessment being replaced by the MILHIST criteria, rather than the opposite, but would support MILHIST opting-out if that isn't done. Perhaps a discussion on the enWiki-wide criteria should precede the MILHIST vote? DFlhb (talk) 10:28, 9 February 2023 (UTC)
    The opt-in projects do not have to do anything. As pointed out above, a bot could at some point run through the articles taking out the |class= value for opt-in projects when the same as the article-level |class= value. The opt-in projects could also change their banner templates to stop passing the |class= value to {{WPBannerMeta}}, or this could also be done by a bot, but there is no urgency for such a change. Aymatth2 (talk) 14:58, 9 February 2023 (UTC)
    The change can be coded within {{WPBannerMeta}} without requiring changes to individual banners templates afaik, except if a project opts-out. Ofcourse, there's no rush. If/when the proposal succeeds, every WikiProject should be given ample time to discuss (de)merits of opting-out and making a decision. I have a proposal on how to move forward, but of course necessary adjustments may need to be made as per the wishes of the stakeholders:
    • If a WikiProject decides to opt out: All of its quality ratings, including unassessed remain independent.
    • If a WikiProject does not decide to opt out:
      • If all banners (of the WPs that didn't opt-out) show same quality rating, run a bot to introduce it directly at the article-level.
      • If some banner(s) are unassessed, but all else(WPs that didn't opt-out) have same quality rating, run a bot to introduce that quality rating directly at the article-level, so the unassessed are no longer unassessed.
      • If banners(of the WPs that didn't opt-out) differ between their quality ratings, categorise them for human review, and assign them a proper class at the article-level.
      • If all banners(of the WPs that didn't opt-out) are unassessed, it remains so, even at the article-level.
    [Slightly unrelated]: I have also seen WP:WikiProject India to have a parameter for last assessment date, which in my opinion should be introduced more globally at the article-level, to have a rough idea of what articles among the millions may have improved/degraded in quality over periods of time. This one probably requires separate discussion, but if it gains support, it would be easier to implement both proposals together. —CX Zoom[he/him] (let's talk • {C•X}) 16:56, 9 February 2023 (UTC)
    @Hawkeye7, re {{WikiProject Military history}} does not use it (maybe it should) and I don't know how many projects do or do not. see Category:WikiProject banner templates not based on WPBannerMeta. Only 3 WikiProjects don't use it. These should probably all be converted. — Qwerfjkltalk 18:58, 9 February 2023 (UTC)
    I don't think WP Vital Articles needs to switch, since it's always outside the WPBannerShell, so that leaves two. I'm only decent at template editing, but I'll try to help for the MilHist banner if Hawkeye7 agrees on the change. DFlhb (talk) 19:08, 9 February 2023 (UTC)
  • That is a generous offer. This would need to be carefully tested in the sandbox; the number of articles is large, and the template is complicated. A Bot run may be needed to aid the conversion. Hawkeye7 (discuss) 20:04, 9 February 2023 (UTC)
  • Support long overdue. HouseBlastertalk 01:13, 8 February 2023 (UTC)
  • weak support as it will make it easier for project assessors. But it is not that important to get right. Graeme Bartlett (talk) 11:35, 8 February 2023 (UTC)
  • Support and hopefully this would include a new tracking category for globally unassessed articles, whether they have a Wikiproject attached or not. Pinguinn 🐧 12:35, 8 February 2023 (UTC)
  • Support Ajpolino (talk) 15:20, 8 February 2023 (UTC)
  • Support This will eliminate a massive "backlog" which attempting to clear manually would be a massive waste of time. Trainsandotherthings (talk) 16:09, 8 February 2023 (UTC)
  • Weak support. So long as there is some ability for individual WikiProjects to maintain individual quality assessments that are uncommon but nonetheless useful (such as A-Class), then I would support this. I do not support giving MilHistBot a veto power over global quality assessments; global quality assessments should be given by the global criteria, and MilHist should be free to separately list its own rating if the WikiProject dissents from the quality assessment performed by the community. That being said, this will save editor time, and I look forward to the implementation of this across EnWiki. — Red-tailed hawk (nest) 16:36, 8 February 2023 (UTC)
    I want to assure you that I have no intention of that. This proposal is on that basis of Wikipedia:Content assessment and any project that opts in will need to accept that. Hawkeye7 (discuss) 22:49, 8 February 2023 (UTC)
  • Weak support echoing almost entirely the comment above, it's fine as long as Wikiprojects such as Military History can still set their own classes for only their WP where they disagree e.g. they want A-class, which isn't commonly used, and therefore the general rating should never be A-class. It will benefit articles with many WPs listed, and only half of the WPs have been assessed for quality rating, even though generally it should be the same for all WPs. Joseph2302 (talk) 16:48, 8 February 2023 (UTC)
    I don't understand why there's a dozen or so comments which assume that there's any doubt as to whether MILHIST can keep its own grading criteria, when that's a fundamental part of this proposal. The WP:VPI discussion that preceded this proposal extensively discussed ways to let WikiProjects retain their own criteria. DFlhb (talk) 16:54, 8 February 2023 (UTC)
    It may make wikiprojects with their own quality assessment criteria a bit more visible, so an editor making a change to the general assessment may leave it to a project member to change the project assessment. Not sure if that is good or bad. A bot could perhaps be developed to flag articles with wide variants in assessment values such as "stub" in general and "B" for milhist, or vice-versa.. Aymatth2 (talk) 18:06, 8 February 2023 (UTC)
  • Support Looks good, no real concerns with the proposed set-up. 74.73.224.126 (talk) 21:36, 8 February 2023 (UTC)

I think you can go ahead and implement this; I have removed it from WP:CENT as it's clear enough at this point. ~ ToBeFree (talk) 22:18, 8 February 2023 (UTC)

@ToBeFree: I think the discussion should be allowed to run a bit longer. Don't want anyone saying it was rushed through. Aymatth2 (talk) 14:58, 9 February 2023 (UTC)
Would you think the same if all support had been opposition instead? ~ ToBeFree (talk) 18:24, 9 February 2023 (UTC)
No. If there had been solid opposition there would be no point wasting time. But a weekend editor may identify a roadblock. I would be surprised, but this has waited more than 15 years so a few more days will not hurt. Aymatth2 (talk) 00:00, 10 February 2023 (UTC)
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.

Collapse hide certain notification boxes at the top of an article

Some boxes like notifications that an article may be merged or split might not be something a passing user would want to know. Perhaps having those contained within a pre collapsed box would be better. Or maybe a generic notification that there are administrative (or something) things to be aware of and going to the article talk page gives more information.

2600:6C4E:1200:1E85:B409:AC04:8255:CFA1 (talk) 16:26, 15 February 2023 (UTC)

Every reader is a potential editor, and if they don't know what might need fixing in an article, they can't do it. 331dot (talk) 16:38, 15 February 2023 (UTC)
Also, this would be in violation of MOS:COLLAPSE. Collapsed content can often be harder to access for readers on mobile devices and particularly on screen readers. Joseph2302 (talk) 16:43, 15 February 2023 (UTC)

Strip Draft prefix from 'Possible backlinks'

Moved to user talk page.

The following discussion 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.

The 'Possible backlinks' link (left sidebar under 'Tools') is very useful for helping to integrate new articles into the encyclopedia, as is recommended by the lead sentence at MOS:LINK and at WP:Orphan, but it doesn't work while an article is still in Draft space. I often develop in Draft space, and one part of my launch plan is the preparation of a set of articles from which backlinks should be added. I still use the tool anyway, but the default result set is always zero results, and I have to manually delete the 'Draft' prefix in two places. That shouldn't be necessary, and may leave some editors persuaded that there really are no useful article backlink candidates. Can we get this useful tool updated to drop the prefix, so users can more easily prepare their backlink article set? Thanks, Mathglot (talk) 21:56, 15 February 2023 (UTC)

I assume you're referring to User:Lourdes/Backlinks. You should ask Lourdes directly. Nardog (talk) 22:03, 15 February 2023 (UTC)
Oh my gosh, you're right; I've had that script installed for so long, I completely forgot, and thought it was part of the standard mw installation (it ought to be!). I'll move this request to her TP; thanks for the heads-up! Mathglot (talk) 22:13, 15 February 2023 (UTC)
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.

Adding 'Use ... English' maintenance templates

Hello all. Myself and User:Ser Amantio di Nicolao have been adding 'Use ... English' maintenance templates (e.g. Template:Use British English) to articles that deserve them en masse utilising AutoWikiBrowser, however another admin has suggested that we gain consensus before continuing doing this. I believe the argument against was that it's [neither] necessary or desirable to place that tag on tens of thousands of articles (see this short discussion). A bot was suggested to carry out this purpose, however I believe that the nature of these tags, i.e. garnering context from the article itself, requires a human edit. Neither of us see anything undesirable about adding this maintenance template per se, however we both paused our efforts until some sort of discussion had been had. Any comments on this would be most welcome. Thank you and best wishes. SɱαɾƚყPαɳƚʂ22 (Ⓣⓐⓛⓚ) 19:58, 6 February 2023 (UTC)

I would tend to agree that these edits are unnecessary, and making thousands of unnecessary edits is undesirable. Unless there has been some kind of editing history on a particular article that would suggest this template is needed, then it is probably better not to add it. PS, I note that it seems to be classified as a maintenance template, but it really is not a maintenance template because no maintenance is required on these articles. — Martin (MSGJ · talk) 20:24, 6 February 2023 (UTC)
To be frank, I think the problem is with the template. What purpose does the template serve? Perhaps the idea is so discrepancies like a {{Use British English}} article containing "color" (not "colour") are automatically identified, but I'm not convinced that this is worth the wikitext it takes up at the top of the page. There must be a better way to do this. I can't really fault the editors here for adding a tag to applicable articles, but I don't think their actions are useful. — Bilorv (talk) 21:41, 6 February 2023 (UTC)
I see the value in having an explicit statement that a given variety of English is used on an article when it is not obvious which should be used (Seattle and Tony Blair are obvious, Acre isn't), especially if the article has had to be actively cleaned up from multiple varieties. I think bots can (or at least would have the capability to) standardise in some cases, e.g. adding or removing the spell=us parameter from {{convert}}. Thryduulf (talk) 22:42, 6 February 2023 (UTC)
Over half the audience won’t care either way, as they are neither British nor American….. ;) —TheDJ (talk • contribs) 00:02, 7 February 2023 (UTC)
If only there were a way to make everyone happy. There could be a setting in your preferences asking what your preferred ENGVAR is and words like col(o|ou)r, defen(se|ce), etc. were templated to conform to your ENGVAR regardless of the topic's ENGVAR. Number templates could default to lakh and crore instead of thousands and millions for our Indian readers. To me, that is more useful than slapping {{Use British English}} on top of a page. –Fredddie™ 01:13, 7 February 2023 (UTC)
Not a bad idea, but only if it could be done via some widget or script in your browser, and not if it's visible in the Wikicode, which would pollute the code in a way making it harder to maintain, and likely would have other knock-on effects. Mathglot (talk) 02:02, 7 February 2023 (UTC)
Because of things like torch/flaming torch/flashlight, or truck/bogie, it's difficult to do an automated straight substitution without additional markup in the source text in some fashion. Variations like "licence/license" are tricky too, since the spelling depends on whether or not the word is a noun or verb. isaacl (talk) 17:40, 7 February 2023 (UTC)
Years ago we had a system (date preferences) in which you could set the format in which dates would be shown in your preferences. It required that all dates be wikilinked in a specific pattern. It was deprecated because it was clumsy, and only worked if you were logged in. Remember, users who are not logged in (most of our readers) do not have preferences available. Donald Albury 02:08, 7 February 2023 (UTC)
If the only downside is that "it doesn't work for IP users", then I think that's not a major problem. IP users already miss out on all sorts of benefits, and it's by their own choice. If they are "forced" to view articles in whatever the default English is, I would say that is extremely minor inconvenience. Specifically: implementing Fred's idea would not make any IP user's viewing experience worse than it is now; it would only improve the experience of other users. I don't see a downside to this. Mathglot (talk) 02:15, 7 February 2023 (UTC)
It works perfectly on the Chinese Wikipedia, where you do not need to log in to switch between simplified and traditional Chinese (and a few sub-varieties). —Kusma (talk) 09:10, 7 February 2023 (UTC)
I thought it was deprecated because of MOS:OL and, on the developer side, concerns over cache-splitting. Anomie⚔ 14:29, 7 February 2023 (UTC)
  • Disagree A number of articles have popped up on my Watchlist, with edit summaries saying, "Use Ghanaian English". Now, I'm not surprised that Ghana has its own variety of English, but honestly, that notice on the page does only one thing wrt my editing at the article: it discourages it, and waves me off, since I haven't a clue about Ghanian English, and even if it's pretty close to Commonwealth or some other English, as soon as I have it under my belt, then the next article that hits my list is going to say, "Use Liberian English", and now I'm going to have to start using that? I've got about all I can handle dealing with US, UK, OZ, NZ, Canadian, and Oxford English, and I'm willing to go out on a limb once in a while for a worthy article in Caribbean or maybe Nigerian English. But as for articles in Ghanaian English and Liberian English and Pitcairn English and all the rest, count me out; someone else can go edit those articles in that case; it's more effort than I'm willing to offer. Mathglot (talk) 01:54, 7 February 2023 (UTC) Clarifying: agreeing with the STOP sign from the admin; disagreeing with placing any more of these. Place the bot in reverse, and have it undo all the ones it did. Mathglot (talk) 01:57, 7 February 2023 (UTC)
    Lol, I thought that was a joke but {{Use Ghanaian English}} is real and is used in 2402 pages, for example Accra added on 29 January 2023. That is beyond crazy. I would like the wikitext to tell me whether to use color or colour (or whether to revert an edit that changed that spelling), but adding stuff like Use Ghanaian English has no point beyond increasing one's edit count. Johnuniq (talk) 02:30, 7 February 2023 (UTC)
    Not a joke. Most of them have scrolled off my Watchlist but I found this recent one at Kwame Nkrumah. Worse, are these two recent examples:
    rev. 1136291731 at Accra, with the edit summary, "Use Nigerian English" (Accra is the capital of Ghana), and
    rev. 1136292968 at Cape Coast, with the edit summary, "Use Nigerian English" (Cape Coast is a major port in Ghana).
    That's just carelessness. Can someone help me set up an AWB run, so I can place one Trout on Ser Amantio's Talk page for each incorrect edit summary, and a big, golden mega-trout for starting this without consensus? That could be eight thousand trouts, but it's healthy protein, and could help the global supply. Mathglot (talk) 02:45, 7 February 2023 (UTC)
    I've long wished that the people who have the idea that every country in the world needs to be flagged for its own variety of English would include in these templates' documentation an explanation as to how exactly those varieties actually do vary from American or Commonwealth English when written in an encyclopedic register. I see no need to care about varieties that differ only in slang, or in colloquial registers, or in spoken pronunciation (at least until "SpeakGPT" exists to make natural-sounding spoken versions of articles in an appropriate accent), or the like. Anomie⚔ 14:38, 7 February 2023 (UTC)
    The issue is that documenting all of the differences would be tedious and no one is interested in doing the work (true for documentation in general). Most of the time this probably isn't a big deal if someone puts "color" or "lorry" into an Australian article there are enough Australian editors that they will be converted to "colour" and "truck" with no documentation needed; there's probably also enough Kiwis around that instances fjord will be converted to fiord without us needing to document that peculiarity of NZ English anywhere. On the other hand I'd be surprised if we had even a handful of regular Ghanian editors so without documentation changes will happen only slowly.
    It's also best to remember that some national varieties of English are tagged separately solely to be polite. There's no functional difference between British and Irish English when written in an encyclopedic register; Likewise for Indian and Pakistani English, but the shitstorm that would ensue from trying to replace all transclsuions of the Irish template with the British one, or the Pakistani one with the Indian one far outweighs any benefit. As a practical matter tools can be instructed to treat the two identically, and it's actually easier for new editors to manually tag correctly per TIES when tag names directly match country names anyway. 74.73.224.126 (talk) 16:14, 9 February 2023 (UTC)
    I'm not sure that even that isn't a solution in search of a problem. Surely it's better to have sourced content with Us and Zs in incongruous places than to not have the content at all? HJ Mitchell | Penny for your thoughts? 17:46, 9 February 2023 (UTC)
    Agree, in fact I suspect most pages are not fully MoS compliant, and in general MoS issues are pretty far down the priority list of editorial standards. 74.73.224.126 (talk) 17:56, 9 February 2023 (UTC)
    I like my articles to look pretty and be neatly formatted and consistent throughout. But most of all I like them to be informative. HJ Mitchell | Penny for your thoughts? 17:59, 9 February 2023 (UTC)
  • Disagree, not seeing what the value of these templates is. The dmy and mdy templates actually have purpose, interacting with the citation templates. The documentation of Template:Use British English says that all it does is add a category, in which case all it does is duplicate the talkpage notices (themselves not always a great use of screen space). CMD (talk) 06:29, 7 February 2023 (UTC)
    Playing Devil's advocate here a bit: there is a legit value, imho, in having some of them, some of the time: for cases where MOS:TIES doesn't apply but MOS:RETAIN does apply, it's useful to have had someone else go through the article history before me and figure out what the stable usage was at the beginning or has been up till now, so I don't have to figure it out for myself for every article. I wonder if those templates, in articles where there's consensus that they really do help, would work better in an WP:EDITNOTICE, than as a inline template in the article? We don't really need to know what version of English it is, unless we decide to edit it. Mathglot (talk) 10:05, 7 February 2023 (UTC)
    There is some value some of the time, but that is already provided for by the talkpage templates (which are indeed sometimes put in edit notices). CMD (talk) 15:41, 7 February 2023 (UTC)
  • I think these are mostly make-work edits and aren't helping editors. Unless a page has had a recurring issue that has since been resolved about dialects this isn't helping editors - and may actively discourage casual editors who should be most concerned with adding relevant verifiable content, not which spelling their prose used. Further, most any massive templating shouldn't be done except by a bot - it just annoys watchers and recent change patrollers. — xaosflux Talk 14:45, 7 February 2023 (UTC)
  • Deciding on a variant of English to use, and harmonizing a whole article onto it, is good practice when you're trying to bring an article to GA or FA class, but I don't see the point of doing it en-masse. As a side note, while I have no interest in telling anyone what to do, I just don't understand why so much of Wikipedia has turned into menial busywork. Why is it that the vast majority of articles I come across are substantially unchanged from ~2010-2013, save from Wikignoming? Surely article expansion is more rewarding? DFlhb (talk) 19:30, 7 February 2023 (UTC)
    Exactly. Ppl seem very busy 'standardizing' things to a level that is never achievable (for long) in a public editing model by thousands of (imperfect and untrained) people. It is better to accept certain imperfections and mistakes of the users. It is part of what makes it a wiki. —TheDJ (talk • contribs) 21:58, 7 February 2023 (UTC)
  • Disagree, per Xaosflux. I can sympathise with the intent, but mass changes can very easily become disruptive and there's no pressing need that justifies it in this circumstance. XAM2175 (T) 12:33, 8 February 2023 (UTC)
  • No mass addition, although the templates can be useful on a case-by-case basis. Like Mathglot above, if I see "Ghanaian English" I would be quite reticent about touching the article. And FWIW, our Indian articles are generally dreadful, not just for lack of sourcing, but because of the abysmal strings of characters which I understand are supposed to pass for "Indian English". I think the weird capitalisations are mistakes, but they're so predominantly "wrong" (to my USian eyes), that I wonder if there's not actually a system. The grammar, meanwhile, just seems sloppy. Summary: templates are useful, added individually and selectively, but would be even more useful if, as above, there were some clue about what they mean. Stop adding these by bot. — JohnFromPinckney (talk / edits) 14:36, 8 February 2023 (UTC)
    • We have a long article on Indian English, which in most cases is like British English, but this is a second language to most users, and exists in several registers. Academic Indian prose is virtually the same as British, or intended to be so, but most of our Indian editors aren't academics, and lean towards the colourful Indian form of journalese, just as huge numbers of American editors do towards their local version. Johnbod (talk) 15:49, 8 February 2023 (UTC)
  • No mass addition. Whilst I did appreciate {{Use British English}} being added to 5-10 articles I started (as I usually add them myself), I don't see a general need to add them, particularly when it's not clear to the majority of people what the differences between some of these are. E.g. Despite being English, I'm not really sure what the differences between British, Indian, South African English would be (other than Indian articles might use lakh/crore). Joseph2302 (talk) 16:32, 8 February 2023 (UTC)
    @Joseph2302: a tiny point but I believe that you shouldn't use lakh/crore per MOS:COMMONALITY, the idea being (correct me if I'm wrong) that an Indian reader will still understand "100 million" but a non-Indian reader is unlikely to be familiar with "10 crore". — Bilorv (talk) 11:08, 16 February 2023 (UTC)
  • No mass addition, especially for the more specific variants. I agree with Xaosflux's comments about these are mostly make-work edits and aren't helping editors and may actively discourage casual editors who should be most concerned with adding relevant verifiable content, not which spelling their prose used. Among other things, some of these templates such as {{Use Trinidad and Tobago English}} strike me as not helpful - our article on Trinidadian and Tobagonian English seems to be describing it as essentially a dialect more than a standard variety. I don't think anyone would consider {{Use Southern American English}} to be useful, and several of these strike me as a similar level of over categorization. Hog Farm Talk 19:41, 8 February 2023 (UTC)
  • Oppose Far too nuanced a matter to use any mass addition method. --Jayron32 14:14, 10 February 2023 (UTC)
  • Insufficient data How is the decision made as to which language template is added?? · · · Peter Southwood (talk): 15:13, 11 February 2023 (UTC)
  • No mass addition because as per Mathglot the templates run a risk of deterring editors who feel they can't write Pakistani English, so their use should be kept to an absolute minimum. They should only be used to relay the result of discussion where there has been disagreement and it's been resolved. Elemimele (talk) 15:57, 13 February 2023 (UTC)

Make some car manufacturer logos available for use on different Wiki languages when creating articles

Hi dear Wikipedians!

I am a car fanatic and I have a request. Please can you make some car manufacturer logos available for use on different Wiki languages when creating articles:

Lancia_logo_2022.png

  • Land Rover:

LandRover.svg

Since these logos are the best logos for each of these companies and are with the highest quality and when an user of a different Wiki wants to create an article about these car manufacturers, which is missing on that Wiki and wants to use these logos, can't use them.

Thanks FLORIKRUJA (talk) 19:37, 15 February 2023 (UTC)

FLORIKRUJA Non-free images cannot be used cross-wiki, but nothing is stopping you from uploading a local copy if the home wiki allows non-free media. Der Wohltemperierte Fuchs talk 19:39, 15 February 2023 (UTC)
What you are proposing would be a violation of copyright laws. We are not about to leave ourselves open to lawsuits like that for cross-platform convenience. As Der Fuchs points out, different language Wikipedias have different rules about non-free media use in certain limited circumstances. --Orange Mike | Talk 21:33, 15 February 2023 (UTC)
Also, WP is not for advertising. YTKJ (talk) 21:55, 16 February 2023 (UTC)
The reason copyrighted media cannot be uploaded cross-wiki, is that their use is subject to local laws, not American law. For example, "fair-use" provisions don't exist in many countries. On the French Wikipedia, copyrighted logos can be used, but copyrighted screenshots are illegal with no exception (even low-resolution). There may be jurisdictions where the use of copyrighted logos is illegal too. That's why these files are local to each language-specific Wikipedia. DFlhb (talk) 22:12, 16 February 2023 (UTC)
I think that’s just covered by fair use Dronebogus (talk) 01:13, 17 February 2023 (UTC)

Make quality ratings of list pages in Wikipedia more specific

I wonder whether it is worth making a proposal for WikiProjects to make their assessments of list articles more specific? If one goes to the article "List of pastries", one can see it was rated "List class" by WikiProject Food and Drink. This tells us WHAT this article is, but does not tell us its quality. My proposal is to introduce the following ranking for Wikipedia lists: 

        Q. Contains Questionable Entries
        Start class. Needs to be more comprehensive
        C. Reasonably comprehensive and accurate, but still requires more work
        B. A very good list
        A. Contains accurate information, covers a good range of entries and 
        provides parameters for information that would not normally be accessible 
        from categories or articles.

I shall look forward to hearing thoughts on this proposal. YTKJ (talk) 21:02, 14 February 2023 (UTC)

WP:MHA#SCALE has something like this already. The reason it's not more widely adopted is probably because other WikiProjects don't see the need and/or there's not enough interest. —pythoncoder (talk | contribs) 02:30, 15 February 2023 (UTC)
I'd strongly support adopting the MILHIST List ratings wholesale (and frankly, that's more likely to obtain consensus than this proposal; I wish this had been brought up at WP:VPI first, to obtain consensus on which list-ratings to propose).
MILHIST's approach just makes far more sense: lists and articles are both subject to the same flaws (sourcing, completeness, comprehensiveness, writing quality), so there's little reason to only have two assessment grades for lists. DFlhb (talk) 22:20, 16 February 2023 (UTC)
I can second this proposal. Now that we are working on globalising ratings, we should definitely consider ways to standardise as many quality ratings as possible. —CX Zoom[he/him] (let's talk • {C•X}) 11:26, 19 February 2023 (UTC)

Thank you User:pythoncoder. I see that there are some lists, such as List of songs recorded by Adele or List of works by Dorothy L. Sayers that have been give the distinction of being "Featured Lists". This is a step in the direction of what I am proposing, but I wondered whether other lists should also be ranked. This might help WikiProjects see which lists require more work. YTKJ (talk) 18:08, 15 February 2023 (UTC)

Creating a preference for skipping to the top/bottom buttons

Earlier this year, I opened up a discussion at the Idea Lab to create buttons that would automatically skip to the top or bottom of a page if you pressed them. It seemed that it should be made into a preference based on the discussion, and I think that this should now be made into a formal proposal, and that is to create a preference for skipping to the top/bottom buttons. Should this be made into a preference? ‍ ‍ Helloheart ‍ ‍ 01:37, 23 February 2023 (UTC)

@Helloheart we can't just "create a preference". We can make an opt-in gadget, but step one is writing it. Good news: you (or anyone) can start on that now as a userscript. Once it is ready, we can look in to making a test gadget run with it. — xaosflux Talk 01:55, 23 February 2023 (UTC)
Note, there are several "to top" and "to bottom" scripts you can try already listed at Wikipedia:User scripts/List. — xaosflux Talk 15:09, 23 February 2023 (UTC)

RFC - restore "talk" from drop down

Ok, so for me, there's a lot not to like about the new layout.

But someone else can start that eventual RfC : )

I just want to focus on one very specific thing: the talk link being moved to a drop down.

Hiding the talk link is a very very bad idea.

We operate on the consensus model here.

Hiding the talk link just reinforces that edit-warring is the way to go.

And no, I really don't care what some off-site discussion was - so I don't need to hear an WMF employee breezily tell me that a talk page link was determined to not be important on Wikipedia. I'm happy to engage in discussion, but don't blow us off by referring elsewhere as if this project does not matter please. (As an aside, and this goes far beyond this simple RfC - But just thought I'd mention that while I respect the WMF in general - I think it's very important - but I'm really not happy about how things seem to be being pushed through, with fewer and fewer discussions being allowed to be "open" for anyone to participate.)

Anyway, if we weigh importance, I think it's easy to agree that the talk link is more important than the watchlist link. So if space really is the issue argued, then swap them. Or maybe combine "alerts" and "notices" to save space. Or whatever other ideas people may have.

Whatever the case, un-hide the talk link. - jc37 19:30, 19 January 2023 (UTC)

RfC Discussion

  • @Jc37, I'm not sure what you mean. The talk page link is just below the page title. — Qwerfjkltalk 20:37, 19 January 2023 (UTC)
    I think they mean the link to their own user talk page, which is indeed now in a dropdown (unless you have new talk page messages, in which case it's more prominent like before). Matma Rex talk 21:13, 19 January 2023 (UTC)
    @Matma Rex, I see. But people still get the big yellow notification that they have messages, so I don't see the problem. — Qwerfjkltalk 21:22, 19 January 2023 (UTC)
    anything - anything that reduces the visibility and/or ease of accessing the talk page is a bad idea. We want people to discuss. We want people to respond to talk page concerns about their editing. Not to get frustrated because they can't find the link, and thus not engage. There are innumerable reasons that hiding the talk page link is really bad. Even just from the optics of suggesting that talk pages are uninportant. I understand that this may seem an innocuous change for some, but when I consider years - decades - worth of dispute resolution, among many other things, this just really really seems an incredibly bad idea.- jc37 21:46, 19 January 2023 (UTC)
    @Jc37, so your problem is that people might get talk page message, dismiss that notification, and then not know how to find their user talk page and respond? — Qwerfjkltalk 21:59, 19 January 2023 (UTC)
    One, of several. Anything we can do to get people using talk pages, the better. We've repeatedly seen that initial talk page usage helps bridge the learning curve gap for people to turn into regular editors. It's part of why we encourage the community aspect of Wikipedia. Learning how to thread discussions on a talk page can lead to being confortable to add to lists, to add references, and just merely feeling comfortable to edit a paragraph on a page. These are called "gateways" for a reason. - jc37 22:14, 19 January 2023 (UTC)
    Most newcomers are using the Reply button, so they don't have to count colons any longer. The learning curve is essentially flat.
    The Editing team, as a result of mw:Talk pages consultation 2019, considered ways to make talk pages more visible, but it's tricky, and I don't think that they got very far. You don't want the "Talk" tab at the top to be more prominent than the article tab. You also don't want it to be more prominent than the Edit button. So at best, it's in third place. In terms of your own User_talk: page specifically, I think that Growth's Newcomer homepage work has made some difference there. Whatamidoing (WMF) (talk) 23:37, 19 January 2023 (UTC)
    I appreciate all that. I do. But all I need do is look at the default signature for editors to see that Wikipedia sees the value of a talk page link. (And yes, I'm aware that mine isn't there - user pages are important too : )
    But anyway, if it's in third place, then watchlists decidedly aren't. And while I may have done some looking around to find out the difference between notices and alerts, I doubt the average person would know, or care.
    tried and failed doesn't = push through anyway. I understand the idea of the perfect is the enemy of the good - Wikipedia is a work in progress after all. but something like this is different, we're being asked to swallow the watermelon whole, with no changebacks allwed due to fait accompli." what's done is done" and all that.
    I'm not merely complaining to the air, I've actually proposed some suggestions and welcome others. (not adding "support/oppose" sections was intentional). So if you have any ideas for a way forward, I'd be happy to hear them. - jc37 23:54, 19 January 2023 (UTC)
    I don't think that I want to get in the middle of whether the talk page or the watchlist is the more important thing to show. I imagine that most editors want both.
    But now I'm not sure that we're talking about the same thing. At the top of an article, volunteer-me sees these options:
    Article – Talk – Read – Edit – Edit source – View history – Watchlist star – More menu – Twinkle menu
    This is what I see in the new Vector 2022. Are you seeing something different? Are you not seeing the "Talk" item right next to "Article"? Whatamidoing (WMF) (talk) 21:45, 20 January 2023 (UTC)
    @Whatamidoing: I think Jc37 is referring to one's personal user talk page (), which is in the dropdown menu for , rather than a page's talk page (). —Tenryuu 🐲 ( 💬 • 📝 ) 22:30, 20 January 2023 (UTC)
    You also don't want it to be more prominent than the Edit button. Yes I do. Levivich (talk) 16:54, 21 January 2023 (UTC)
    I think that in the end, anything that improves or makes more efficient the talk page in a non-obnoxious manner should be implemented. In particular, I believe that the talk page is one of the biggest catalysts for recruiting new editors, and if they see a place where not only their voice matters but they can participate in a discussion with consequences they can see, I think we've done a good job at recruiting a new editor. Put another way, to know that the change you helped to support 10 years ago can still be found on the website is, for lack of a better term, a magical feeling. InvadingInvader (userpage, talk) 21:46, 31 January 2023 (UTC)
    Very few editors make their first edit on a talk page. Whatamidoing (WMF) (talk) 01:11, 1 February 2023 (UTC)
  • Let editors have the option to unhide the Contributions link, too. Some1 (talk) 01:32, 20 January 2023 (UTC)
    @Some1 and @Anarchyte - see Wikipedia:Village_pump_(technical)#Customizing_button_shortcuts_in_top-right_menu_area? for a userscript an editor can use to add contributions to the page top. — xaosflux Talk 01:03, 21 January 2023 (UTC)
    The userscript is better than nothing I guess, thanks xaosflux! Some1 (talk) 01:14, 21 January 2023 (UTC)
  • Support - adding the ability to choose which buttons appear outside of the user dropdown menu would be a drastic improvement. Anarchyte (talk) 08:08, 20 January 2023 (UTC)
  • This RFC is a bit misleading in the title, "Talk" in general is not in any menu, this is only about the link to someone's own usertalk page. This is also something that is skin-wide, so would really need to be changed upstream. I don't see this as severely breaking the consensus building model, as most consensus building discussions don't take place on personal user talks, but on article talks or project pages, both of which are already accessible. — xaosflux Talk 12:32, 21 January 2023 (UTC)
    The title is: "restore "talk" from drop down" - that is exactly what this is about. the talk link in the drop down. Nothing there misleading at all. - jc37 08:32, 22 January 2023 (UTC)
  • Support: There is a huge gap between search box and "CX Zoom" at the top, which could've been utilised in better ways. Talk pages should absolutely be visible on up there in order to assist new editors find a link to there. —CX Zoom[he/him] (let's talk • {C•X}) 16:17, 21 January 2023 (UTC)
    This is exactly what I was saying about the "log in" button for unregistered users. Whether logged in or not, the WMF seems intent on wasting that space and forcing us to live with it. —pythoncoder (talk | contribs) 17:56, 1 February 2023 (UTC)
  • Support, per CX Zoom. Also support restoring a link to an editors contributions. BilledMammal (talk) 07:38, 2 February 2023 (UTC)
  • As someone who has been using Timeless, I can say that having the user links in a dropdown does not cause me any issue today, and it's second nature to click these links through a dropdown. (I'll move to Vector22 on desktop probably Soon, just have to get off my preferences butt, and mobile Whenever it actually supports mobile.) Oppose accordingly. "Supports" and "opposes" aren't really valuable here. Discussing why you want a link in X or Y position might be, but is still squarely in the realm of design, especially (as I'm sure they will) as they start turning to making the skin friendly(er) for mobile. It might be valuable to decide on what the most valuable links are in the dropdown, rather than having RFCs for this that and the other thing, and see if there can't be some thought put into displaying certain links at certain widths (perhaps as icons, though I know the group that hates the dropdown is probably a concentric set with the group that hates icons). In general though, this dropdown is provided for the set of people who already do have access to scripts, so they always have a workaround to what is/isn't displayed. Izno (talk) 21:08, 4 February 2023 (UTC)

Approval of Enforcement Guidelines without first approving a Code of Conduct

The following discussion is an archived record of a request for comment. Please do not modify it. No further edits should be made to this discussion. A summary of the conclusions reached follows.
Let me start by saying there is recognition that this RFC is primarily advisory, as there has been a community ratification vote and the enforcement guidelines fall under WP:CONEXEMPT. As such I will be providing a summary of the discussion.
It is clear that the strong majority of users who took part in this RFC do not support the UCoC enforcement guidelines. There were many reasons for the opposition, and a few points that were raised in many of the responses. First and foremost, there was a strong resistance to ratifying enforcement guidelines for a code of conduct that has not been vetted by the community and does not enjoy explicit consensus. This has led many to many feeling this was foisted onto the community in a top-down manner. There are also serious concerns about the vague and overbroad language, as well as the poorly defined scope of the guidelines which could allow the application of the UCoC in almost any situation. Additionally, it was brought up that there are no protections for an accused party, or any provisions for evidentiary access. The combination of these issues gave some editors reservations, having seen WP:FRAMBAN and other actions taken by the foundation against community consensus. Lastly, and the most obviously true thing stated in the RFC, the first time the enforcement guidelines are invoked in a high profile situation to sanction an editor for a violation of the UCoC it will cause "a huge pissing contest," as the UCoC does not have explicit community consensus.
Other responses have said that ratification of the guidelines will likely not have that much of an effect, as en.wiki already has policies and processes in place that broadly cover the same area as the UCoC. It has also been brought up that these guidelines are WP:CONEXEMPT, and that the foundation has held multiple community ratification votes and responded to community concerns about the enforcement guidelines.
It looks like this closure is probably a few weeks too late, but I hope that some of those in the foundation have read and taken on board the criticism above. ScottishFinnishRadish (talk) 16:23, 24 February 2023 (UTC)


The Wikimedia Foundation has announced that January 17 begins voting on a second attempt to obtain approval of Enforcement Guidelines for the Universal Code of Conduct. There has been no such voting on the content of the Universal Code of Conduct itself.

Does the community Endorse or Oppose approval of Enforcement Guidelines prior to, or in the absence of, any community approval of a Code of Conduct itself?

This RFC is intended to determine and communicate a consensus position. Editors may consider this during current or future Enforcement Guideline votes, and the Wikimedia Foundation may consider it when evaluating how to proceed if the second Guideline vote turns out worse than the first vote. Alsee (talk) 07:53, 14 January 2023 (UTC)

Responses: Approval of Enforcement Guidelines

  • Oppose. I will never approve Enforcement without approval of a code itself. The current Code of Conduct is botched, and without consensus the Code has no legitimacy. Consensus is especially NECESSARY as the Code is almost entirely worthless and ineffectual without active community support for it. Repeated attempts by the WMF to "improve" and re-vote the Enforcement Guidelines can never fix those fatal flaws. The WMF needs to stop trying to steamroll forwards, it is necessary to back up and let the community develop a new Code which actually gets consensus approval. Alsee (talk) 08:07, 14 January 2023 (UTC)
  • This RfC seems founded on a rather narrow understanding of "approval". The UCoC was approved by the WMF Board of Trustees, the legal custodians of this project, who we play a part in selecting. Not all decisions are subject to consensus of editors and local policy specifically recognises acts of the WMF Board as one of those exceptions. The UCoC isn't the first policy to come via this route and we can enforce it with or without guidelines, just like we enforce the Terms of Use, for example. – Joe (talk) 10:12, 13 January 2023 (UTC)
  • Oppose I didn't participate in this before and I haven't really looked into it all in any depth but it seems to me that if the foundation position is that they must have the code whether community approved or not, then they can impose the enforcement as well and see what occurs. I would not personally approve the enforcement guidelines since by doing so that is in fact approving the code of conduct retrospectively. Selfstudier (talk) 08:18, 14 January 2023 (UTC)
  • Oppose. I agree with everything Barkeep49 said earlier, except the conclusion. If it was a mistake and you don't want the mistake repeated you have to speak up. Frederick Douglass expressed it like this: If there is no struggle there is no progress … Power concedes nothing without a demand. It never did and it never will. Find out just what any people will quietly submit to and you have found out the exact measure of injustice and wrong which will be imposed upon them. Following his crystal-clear logic, there is no choice but to oppose. There is another reason to oppose as well: subject the UCoC to community vetting, and it will become a more robust, less ambiguous document. It will become better, more fit for purpose. --Andreas JN466 09:21, 14 January 2023 (UTC)
    I see that an abolitionist's words on fighting against racial inequality are being compared and applied to a code of conduct that prohibits name calling, using slurs or stereotypes, and any attacks based on personal characteristics...like...race (m:Universal Code of Conduct § 3.1 – Harassment). 🐶 EpicPupper (he/him | talk) 00:57, 15 January 2023 (UTC)
  • Oppose. It would be grossly improper for the en.Wikipedia community to in any way endorse a 'code' being imposed without consensus by an outside body. AndyTheGrump (talk) 10:02, 14 January 2023 (UTC)
  • Oppose. The UCoC is well intentioned and contains many sensible rules. However, a similar and more tailored set of rules is already approved and enforced by the English Wikipedia community. The UCoC provides a model which smaller communities may choose to adopt, perhaps even by default, but neither the code nor the new police force that comes with it would be helpful to enwp. The WMF will impose UCoC anyway, but they need to understand that this is a power grab without consensus which conflicts with the community's needs rather than satisfying them. Certes (talk) 10:59, 14 January 2023 (UTC)
  • Oppose as it is inappropriate to enforce something that is not approved. Current codes and practice handles inappropriate behaviour here. Graeme Bartlett (talk) 21:41, 14 January 2023 (UTC)
  • Oppose Graeme Bartlett said it perfectly. it is inappropriate to enforce something that is not approved. Current codes and practice handles inappropriate behavior here. Adding to that, if WMF insists on pushing guidelines invented by them without community approval, its time to fire WMF and replace them with an organization that has not gone astray and revised the bylaws that allowed that to happen. North8000 (talk) 22:05, 14 January 2023 (UTC)
  • Oppose per all of the above (and more). Paul August ☎ 22:17, 14 January 2023 (UTC)
  • Alternative - drop the facade of this being something was in any way “approved” by the community, and admit that it is something imposed by the WMF. Let them figure out how to “enforce” it. Blueboar (talk) 22:38, 14 January 2023 (UTC)
  • I am not sure what this vote is about, but I am personally going to vote on Meta to adopt the enforcement. I opposed it last time and raised a specific concern. From what I see, the problematic part was eliminated, and I do not see any further issues with the enforcement.--Ymblanter (talk) 23:39, 14 January 2023 (UTC)
  • Oppose per Alsee. I'm confused how we enforce a thing that has not, itself, been approved. Somehow I misunderstand. Chris Troutman (talk) 03:53, 15 January 2023 (UTC)
  • I voted against the first enforcement guidelines as I thought there were enough flaws that nothing was better than those. I will be supporting the enforcement guidelines when they come up for a vote again, as enough has changed to tip me over. One concern noted above is something we don't have to worry about. No one is going to be compelled to enforce the UCoC, in the same way no one is compelled to enforce UPOL, BLP, Harassment, or any other policy (or guideline) now. In fact this removes a requirement for admin to agree to the UCoC at risk of losing their adminship and that change is one of the reasons I can support the revision. In the end this is a non-neutrally worded advisory RfC about a Wikimedia wide advisory vote to the Board who will make an actual vote. I suspect that this RfC will attract the people who are most opposed to the UCoC and I think it is important for their voices to be heard, in particular their frustration (which I share) about the lack of community ratification of the original guidelines. I also suspect this RfC will be less likely to attract the people who are mildly supportive of the guidelines but who might vote to approve them in the final vote. So I hope everyone takes note of whatever consensus is reached here - because if a consensus is reached it's worth taking very seriously - but at the same time those participating realize the limitations of what that consensus will mean. Best, Barkeep49 (talk) 05:16, 15 January 2023 (UTC)
  • Support - I might be the only editor on this project who voted for the enforcement guidelines last time and is looking forward to voting for it again. Yeah, it would have been better for the UCOC to be put to a community ratification vote, but that doesn't bother me so much because that decision was made by different WMF leadership than the one that is handling (well, IMO) the enforcement roll-out (cf. it passed with like 55% or so but they didn't implement it, sort of the opposite of how the UCOC itself was handled). The other reason it doesn't bother me is because the UCOC is such a vanilla document--like, it's beyond me what objections anyone could have to those provisions that aren't nitpicky--other than that it's way longer than it needs to be. But overall, put me down for being glad that there's a UCOC and hopeful that enforcement provisions will be put in place soon. That's been long overdue on this website, which has a terrible, terrible record of self-regulating user conduct over the past two decades. It's long past time for English Wikipedia to grow up and start behaving like the rest of the world and not like the wild west... which means a UCOC, and at least some method of UCOC enforcement by impartial professionals rather than volunteer members of the community. Cf. Twitter, which was improved significantly when they started being more serious about regulating user conduct on that website, and has backslid since those regulations were recently relaxed. Cf. all other social media. Levivich (talk) 20:19, 15 January 2023 (UTC)
    It's long past time for English Wikipedia to grow up and start behaving like the rest of the world and not like the wild west... which means a UCOC, and at least some method of UCOC enforcement by impartial professionals rather than volunteer members of the community. this is going to come off like snark, but I mean this sincerely: if you believe this you should vote against the UCoC Enforcement Guidelines. The Enforcement Guidelines have the Principle of subsidiarity as a major tenet which means that nearly all enforcement, including all new enforcement enabled on other projects that don't have policies and guidelines that already cover the tenets of the UCoC (unlike us), will continue to be done by volunteers (both in the sense that it's people willing to enforce the UCoC and that they are not impartial professionals). There's a path not taken where professional enforcement of the UCoC is what happens but that was not what either of the committees that drafted the UCoC Enforcement Guidelines chose. Best, Barkeep49 (talk) 02:21, 16 January 2023 (UTC)
    Oh I know, but I disagree that one should vote against the UCOC Enforcement Guidelines if one believes in professional enforcement... I see UCOC and the Enforcement Guidelines as incremental steps. My prediction: both the UCOC and the Enforcement Guidelines will work, and work well. I think we will perceive no change on enwiki (for the reasons you point out: it's set up to not 'mess' with our developed self-government), and that in and of itself will be a big deal, as the enwiki community will come to realize that this is not a "power grab" or anything like that. I think, give it a few years, but it will help develop trust between enwiki and the WMF, and I hope that trust makes enwiki more comfortable with the idea of professional enforcement, which, btw, I pitched today at the idea lab in case anyone is interested (don't forget to hit that like and subscribe button). Levivich (talk) 04:32, 16 January 2023 (UTC)
    My own expectation is that there will mostly be "no change" until someone decides to try for another WP:FRAMBAN. And then the UCoC will be used to counter the opposition that ultimately resulted in the WMF's attempted ban being overturned. They've got the overbroad language that can be selectively interpreted, they've got the "protect the victim" language to justify not giving any details, they've got the language allowing them to override local processes if they think local processes "refuse to enforce the UCoC" or "lack will to address issues", they've got language mandating the committee be "diverse" in a bunch of ways (but not viewpoints) that could allow for disqualifying troublesome candidates for not being "diverse" enough, etc. Anomie⚔ 00:05, 17 January 2023 (UTC)
    In the current proposed enforcement guidelines, there is no requirement that the Universal Code of Conduct Coordinating Committee be diverse. That being said, the process for electing this committee is still to be determined by a yet-to-be formed group. isaacl (talk) 00:40, 17 January 2023 (UTC)
    There is a requirement that the building committee reflect the diversity of the movement and there is a requirement that the work of the building committee be ratified by vote. So while it's true that there is no requirement for the U4C to be diverse, but I would be amazed if there isn't a requirement by the time the U4C comes into existence. To give a peek behind the scenes, the way that the U4C building committee came to be was because I proposed some diversity requirements for the U4C and the original Enforcement Guidelines drafting committee quickly realized just how much time it would take to hammer those and other fundamental U4C questions out. Best, Barkeep49 (talk) 00:45, 17 January 2023 (UTC)
    Yes, for brevity I omitted discussion of the building committee. If the entire coordinating committee membership is elected, I can only imagine mandated diversity that covers certain broad characteristics, like geographical region. We'll see what the building committee comes up with. isaacl (talk) 00:56, 17 January 2023 (UTC)
    It says The U4C’s membership shall be reflective of the global and diverse makeup of our global community. True, the current "such as but not limited to" list is only in connection with the building committee, but I'd be surprised if they didn't wind up with basically the same thing for the committee itself. Anomie⚔ 10:17, 17 January 2023 (UTC)
  • I don't broadly disagree with the intent of creating a UCoC, but I think that it's important to observe that the rest of the internet is (on the whole) even worse at this than Wikipedia, at least aside from smaller communities that are easier to moderate in a hands-on manner. Compared to eg. Facebook or Twitter we are vastly better at handling issues even on talk - I definitely don't agree that (even prior to their current issues) they were doing better than we are. Twitter and Facebook, for the most part, still allow, and have always allowed, things like the aggressive promotion of fringe theories or even "dogwhistle" racism, sexism, transphobia, blatant trolling and so on as long as it doesn't trip one of the few red lines they've set; similarly, aggressive harassment occurs on those platforms quite regularly as long as it doesn't cross one of their few red lines. Wikipedia isn't perfect but I feel that it has generally done better than those, and part of the reason is because of the limitations that come from trying to solve complex social issues via a set of rigid rules established from above with no input or buy-in from the community. I absolutely do not think we should be looking at Facebook or Twitter as the model for how to handle anything, ever, and I'm baffled that anyone would say otherwise - they are examples of what not to do. --Aquillion (talk) 04:24, 16 January 2023 (UTC)
    allow, and have always allowed, things like the aggressive promotion of fringe theories or even "dogwhistle" racism, sexism, transphobia, blatant trolling and so on as long as it doesn't trip one of the few red lines they've set is how I'd describe Wikipedia ¯\_(ツ)_/¯ I don't really think that Twitter or Facebook (or any other social media, or reddit, or 4chan, etc.) is any better or worse than Wikipedia, especially not Wikimedia as a whole. I don't have any statistics or way of measuring it, but in my admittedly anecdotal experience, I just don't perceive a difference between the people here, the people on any other social media I've used, and the people out there in "the real world". It's all filled with racism, sexism, -phobias, etc. If anything, I think we're a little bit worse, because we let people vote other people off the website, which gives Wikipedia more of a Lord of the Flies vibe than other sites, IMO...and I say that as a participant in many such votes. It's a YMMV situation I think. Levivich (talk) 04:36, 16 January 2023 (UTC)
    I suspect we're better than those other sites you name. One reason I suspect this is that none of them have published how many of its users feel safe, unlike us. Best, Barkeep49 (talk) 00:48, 17 January 2023 (UTC)
You're not the only one. One of the (many) problems of us only discussing the UCOC in negative RfCs like this one is that we tend not to hear from people who think the UCOC sounds like an okay idea and/or aren't into playing power games with the WMF. That in turn gives the impression that the UCOC is being imposed an an enwiki community that largely opposes it (seemingly taken as writ by many above), which we don't actually have any evidence of. The results of the last vote on the enforcement guidelines (57% in favour) would suggest that a majority are supportive – unless you think enwiki is out of step with the rest of the movement on this, which again we have no evidence of. – Joe (talk) 07:59, 16 January 2023 (UTC)
  • Oppose. I don't think that this sort of top-down approach is workable on a site as large as Wikipedia is. We function, to the extent that we do, because of our collaborative culture, and while a UCoC is something we could benefit from, it is completely unworkable to try and impose or enforce one from above without the consensus of the community. --Aquillion (talk) 04:24, 16 January 2023 (UTC)
  • Regardless of the provenance of the code of conduct, I agree with giving the community the opportunity to support or oppose the enforcement guidelines. Those who wish to oppose based on who approved the code of conduct are free to do so. Those who want to ensure that the enforcement guidelines defer to existing enforcement structures and existing guidelines (as per UCoC violations that happen on a single wiki: Handled by existing enforcement structures according to their existing guidelines..., from the revised enforcement guidelines) have a way to influence the process. isaacl (talk) 04:40, 16 January 2023 (UTC)
  • Oppose acting on them, neutral on actual voting on the EGs - I will join the gang in saying that I don't plan on ever (at least, in my role as an en-wiki admin - and I'm not planning on running for any other position in the next few years!) executing a sanction based on the UCOC here. I opposed the last set of enforcement guidelines, but am probably a weak support for the new set - although they *still* lack sufficient bits on the two aspects of right to be heard (evidentiary access and actually being heard). But while the EGs are much improved (and presumably passed by vote) the reasoning everyone else has given for the original UCOC holds true. I don't accept as a reasoning "you could always oppose the EGs if you don't like the UCOC", because that splits the reasoning with everyone who thinks it's already in place.
The base policy text is unacceptably vague at multiple aspects, unacceptably blurs necessary and desired actions, and imposes a scope that covers every action any of us will take on this planet. It also lacks a sufficiently codified amendment structure. Per Barkeep49 - this technically is a just a community position RfC, with the issues he raises. I suppose we could do another one that would prohibit any on-en-wiki UCOC-based action that doesn't have an underlying (overlying?) en-wiki PAG as well, which could reasonably be viewed as causing quite a lot of conflict for not much practical difference. Nosebagbear (talk) 14:30, 16 January 2023 (UTC)
  • Oppose per all the above. Just because the WMF is intent on imposing this, there is no reason we have to approve it. As has been pointed out, it's so vague anything we do could be an offence, or not, or it could be different based on how we identify, and they could call it anything they want and deal with it however they want. After all, they own the servers. It wasn't meant to be this way.--Wehwalt (talk) 16:46, 16 January 2023 (UTC)
  • I think Barkeep49 has put it in a much better way than I could (see above): In the end this is a non-neutrally worded advisory RfC about a Wikimedia wide advisory vote to the Board who will make an actual vote. Also I'm somewhat skeptic about how to interpret whatever result comes out of this RFC, given there is a community consultation about EG approval via vote, which I'd expect to have higher participation than this RFC. MarioGom (talk) 20:11, 16 January 2023 (UTC)
  • Oppose, per (all) the other opposes. Lectonar (talk) 12:10, 17 January 2023 (UTC)
  • Oppose I have to laugh at the WMF looking to take 'enforcement' action against ENWP users while simultaneously Rebecca MacKinnon (WMF VP, Global Advocacy) is deliberately attempting to interfere in UK legislation that would (potentially) hold tech executives liable for their organisation's misdeeds by mischaracterizing it as an attack on free speech. Only in death does duty end (talk) 13:15, 17 January 2023 (UTC)
  • Support I don't find anything strongly objectionable in the UCOC or the Enforcement Guidelines, nor do I think they will have a significant impact on the way the English Wikipedia is run. Their influence is likely to be stronger on smaller Wikis, giving the WMF more tools to fight institutional capture by bad faith actors. The process was and is imperfect. However, the WMF is holding multiple community-wide ratification votes on these guidelines and has given many clear opportunities for us to be heard over a period of years. They have responded seriously to feedback and made changes as a result. Simply put, I think this is a net benefit for the Wikipedia movement as a whole and probably largely irrelevant to the English Wikipedia specifically. I echo what Barkeep and Levivich have said. —Ganesha811 (talk) 13:32, 18 January 2023 (UTC)
  • Oppose I've seen little effort by the Foundation -- & especially the employees who were driving its adoption -- to discussing why their draft of the UCoC was a good thing. Instead, they engaged in patting themselves on the back for getting the board to adopt it (whom I doubt fully understood the document or how it would be implemented) & how it would be such a good thing. Considering the hostile acts the Foundation have taken against the volunteer communities in the past, I can't support this document without serious reservations & doubts about how it will be applied. One of the features about ruling by consensus is that one has to engage in dialogue with all parties so they know their concerns are heard, & hopefully addressed; there has been little effort by the Foundation to do exactly that. -- llywrch (talk) 21:24, 18 January 2023 (UTC)
  • Oppose even being on the Arbitration Committee and hearing WMF talk about the early parts of the UCOC, I still don't really understand how it is particularly an improvement on the English Wikipedia's current mechanisms, and beyond that the fact that it was foisted upon the community and we're doing all these quasi-democratic showpieces around the thing treated as a fait accompli is beyond insulting, and against the pillars Wikipedia is supposed to operate on. The reality is regardless of what "votes" say about the UCOC, the first high-profile time someone tries to actually sanction someone based on it, we're going to get into a huge pissing contest the likes of the Fram debacle or similar WMF overreach showdowns. If they're so confident in their product, how about the community gets to decide? Der Wohltemperierte Fuchs talk 20:06, 19 January 2023 (UTC)
  • Comment. I have very mixed feelings, and will make a "comment" instead of a support or oppose. It's very clear that the UCoC is going to be implemented and enforced regardless of what editors say here. The UCoC actually has been approved, just not by us. I will also say that I am actually pleased that the enforcement proposal being voted on now has removed, in response to community feedback, the implied requirement that all admins here would have to sign some sort of loyalty oath. So, on the one hand, I, like many other editors above, would like my opinion here to be heard as finding it offensive that the UCoC is being put into effect without clear community support, and that, as such, it feels wrong to ask us to approve its enforcement. But, on the other hand, I think that the proposed enforcement guidelines are as good as we are going to get, and could have been a lot worse. I'm going to say those two things, hope that both messages are heard, and accept that this RfC will be treated as advisory no matter what. And, more likely than not, en-wiki will adjudicate disputes as we choose to do, and when the day comes that we and the WMF disagree, we will have to fight that out regardless of what the WMF will have done with the input they are getting from us here. --Tryptofish (talk) 20:55, 19 January 2023 (UTC)
  • Oppose I think it is quite evident how little regard WMF has for the community, and pushing though the CoC without community vote and then trying to add the associated enforcement guideline only goes to continue the pattern of disregard. It is not clear to me how another layer of rules changes or improves the situation for the enwiki community. We already have plenty of policy, rules, ToS, consensus and enforcement mechanisms as it is, and the complexity of engaging with Wikipedia already drives people away. I have never seen a serious case of disregard for community standards from any established editor, and the community has plenty of ways to police itself. Melmann 20:37, 20 January 2023 (UTC)
  • Oppose This word might be used too often, but this is Orwellian. ~ HAL333 02:40, 21 January 2023 (UTC)
  • Oppose. Nonsensical to discuss how to enforce a policy without first deciding if the policy should be enforced. I plan to propose that we hold an enwiki-only securepoll vote or RfC to determine whether there is a consensus here for either the policy or the enforcement guidelines. BilledMammal (talk) 07:35, 2 February 2023 (UTC)

Discussion: Approval of Enforcement Guidelines

Note: There was a previous version of this RFC, above, with non-trivial discussion. Pinging previous participants: Joe Roe Certes Andrevan Barkeep49 Isaacl Andreas North8000 Red-tailed hawk FunIsOptional HouseBlaster Alsee (talk) 08:06, 14 January 2023 (UTC)

@Alsee you should have a single neutral RfC question followed by a signature. But right now this RfC has neither. You could after the question then have background and then responses. Best, Barkeep49 (talk) 15:57, 14 January 2023 (UTC)
I think it was poor form to simply discard the responses you received so far and start again. The question posed here is essentially the same as above. – Joe (talk) 07:32, 16 January 2023 (UTC)


I am going to copy my statement from above, given I feel it is still applicable despite the improved RfC format:

As of late, the relationship between the WMF and "the community" has improved drastically (see Wikipedia:Fundraising/2022 banners and Wikipedia:Page Curation/2023 Moderator Tools project). We had the first vote on the enforcement guidelines because we made a politely-worded request. This prompted a detailed response from the BoT, including a commitment that [b]oth the UCoC and the enforcement guidelines (after ratified), will also be open for review and voter-endorsed amendments annually. When we voted last year on the enforcement guidelines, it passed. The board responded by convening a revisions committee to address the concerns of the minority of people who opposed the guidelines, and they changed the UCoC itself based off of similar concerns. They have already shown plenty of good faith. I think an open letter requesting the promised amendment process on the UCoC itself followed by a ratification vote on the entire document is the most productive way forward. One final note: one of the recommendations from the Enforcement Guidelines Revisions Committee was that the UCoC be added to the Terms of Use. A consultation with legal about this (and some other modifications) is scheduled to begin on February 21.

HouseBlastertalk 23:31, 14 January 2023 (UTC)

I am not sure what this vote is about - Ymblanter. I'll try to clarify for anyone unsure what this is about. The issues are (1) the Code of Conduct itself has not been approved by the community, with the predictable result that (2) many people have issues with the contents of the Code of Conduct. It is impossible to "fix" either of those issues by revising the Enforcement Guidelines. The contents of the Enforcement Guidelines are irrelevant here. An "Oppose" vote here presumably indicates an intent to vote against any version of Enforcement Guidelines unless&until we have an approved Code of Conduct. That essentially says to the Foundation that it needs to back up and get an approvable and actually-approved Code first. Alsee (talk) 01:19, 15 January 2023 (UTC)

No. ToU has also never been approved by the community, so what? Ymblanter (talk) 08:30, 15 January 2023 (UTC)

Chris_troutman I suspect your confusion/misunderstanding may be sarcasm, but in case it wasn't: The WMF took charge of producing the Code, the Board accepted it, and neither the WMF nor Board felt there was any need for community approval. I believe(?) it was pressure from various ArbComs that persuaded the WMF to graciously grant us permission to vote on the Enforcement Guidelines. They weren't originally planning on that. Praised-be the WMF, for they have so vastly improved relations and respect for the community as a partner. Oops, I think I just sarcasmed. Alsee (talk) 04:17, 15 January 2023 (UTC)

this removes a requirement for admin to agree to the UCoC at risk of losing their adminship Again with the proviso that I have not looked at this in any real depth, that something like this was included to begin with is, I think, concerning, and makes me even less disposed to approve the guidelines. If anyone thinks that not approving them is misguided because of a lack of understanding/appreciation for the situation, I would appreciate a pointer to the relevant material.Selfstudier (talk) 13:58, 15 January 2023 (UTC)

The first version of the enforcement guidelines included a section stating that all advanced rights holders should be required to affirm [that] they will acknowledge and adhere to the Universal Code of Conduct. There's nothing in there about what would happen if someone refused to affirm it. – Joe (talk) 07:40, 16 January 2023 (UTC)
  • Houseblaster correctly notes that the WMF and the BOT has shown genuine, highly positive steps with their ultimate actions in the fundraising banner dispute. The UCOC issues however, rather significantly predate those. When the WMF finally started discussing ratification for EGs (and they at least were quite clear in those meetings it was the cross-arbcom letter that drove those), they seemed to feel that no-one had raised the desire for ratification on the policy text. When I provided the diff of I and another asking for it during the phase 1 consultations, that particular staffer seemed to ghost me for the remaining discussions - before the WMF just decided to opt for 50%+1 as a ratification margin. No adequate reason has ever been given for why, say, the policy text couldn't undergo ratification attempt alongside the EG's. Nosebagbear (talk) 14:37, 16 January 2023 (UTC)


@Levivich: - continuing this discussion on the effectiveness of Wikipedia's community-based moderation vs. Facebook and Twitter's from-above, since it seems central. Maybe we (or the WMF) should focus on producing those statistics, since we need to understand the problem we're trying to solve. But there's definitely massive volumes of studies on the problems Facebook and (even pre-Musk) Twitter have: [1][2][3] - in comparison, multiple studies have praised Wikipedia's community-based approach - caveat that many of them focus more on content, because that's what we're famous for, but: [4][5][6] Generally speaking, sources that discuss Wikipedia, Twitter, and Facebook's handling of content moderation together describe Wikipedia as a model for getting it right. I think the reason why it feels, anecdotally, like we don't is partially because our community-based system (the "Lord of the Flies" process you mentioned) tends to be loud, especially when dealing with longstanding editors - we just had that a massive incident with Athaenara, say. But that's partially because we do these things out in the open, which IMHO is necessary to catch things that more top-down systems don't and for the moderation system to scale in a way that keeps up with our size. I also think that, as "power-users" who are deep within Wikipedia, we're more familiar with the details of the places where it does fail. My concern is that if we shift to relying more on top-down rules, we'll have less big discussions like that, yes, but that will be because a lot of things slip through the cracks - I think that top-down approaches don't actually work at the scale we operate on. The sometimes riotous discussion is actually necessary for us to consider context and nuance and handle edge-cases that eg. a list of forbidden words wouldn't capture. It's also easier for a blunt top-down system to be abused - yes, sometimes we have issues here where someone is harassed and then snaps and gets in trouble themselves, but at least our processes give us some leeway to observe and understand that context; boomerangs are not uncommon. A more blunt and rigid code of conduct won't necessarily allow for that, leading to victims getting reported and banned by the very people abusing them (not uncommon on Facebook and Twitter.) --Aquillion (talk) 20:09, 16 January 2023 (UTC)

I don't feel that Facebook and Twitter are good comparisons to Wikipedia, because whereas they are explicitly for chatter about anything, Wikipedia discussions must be related to Wikipedia editing and thus ultimately to improve Wikipedia. This provides a central guiding purpose that can be used to filter unrelated discussion. De-centralized enforcement of process can allow for more consideration of context, and that is what the code of conduct enforcement guidelines are proposing: disruption on English Wikipedia will continue to be handled by English Wikipedia's policies and enforcement procedures.
On a side note, the problem with English Wikipedia's decision-making process is that it's a mass, unmoderated conversation amongst everyone, and that doesn't scale well to more than a small number of people. As a result, we don't necessarily get full consideration of context, as a small number of people can dominate discussion and drown out others, leading to attrition in participants. With no bar to participation, it's easy for anyone to chime in without taking time to become familiar with all aspects of the situation. It's also inefficient, taking up the time of a lot of people, and inconsistent, relying on whoever shows up on a given day. Without refinement, it's not a model for social networks to follow. isaacl (talk) 21:46, 16 January 2023 (UTC)
@Aquillion: Yeah, I think as you say because I'm a "power user", I'm more familiar with inner workings, and that's why I beleive "the last great place on the internet" media narrative is more myth than reality--plus, as you mention, they (the studies, the media) focus on content dispute resolution (where I agree we are better than social media), but I'm talking exclusively about conduct dispute resolution (subject of the enforcement guidelines). I don't think there have been many (any?) studies of how well ANI has worked (or AE, or Arbcom, etc.). I freely concede that much of this is very subjective. In the recent massive RFA incident you mention, whether one sees that as a failure or success depends very much on one viewpoint: a block, and an unblock, and a reblock, but not a siteban. It's a glass-half-full-or-half-empty situation.
The thing is, I don't see UCOC and UCOC enforcement as a "top-down" situation, mostly because I see us (the community) as being on top. I fully and always will support the community being the ultimate decider of policy, even though I think we should delegate some day-to-day stuff to paid professionals since we have the money. The enforcement guidleines are coming from the community: multiple votes, plus the drafting committee has community members on it, and the trustees who ultimately approve it are elected by the community. It's our document, written by our people, approved by our people. The UCOC was essentially the same except for the community ratification part. To me, neither document are "top-down" (imposed on us by the WMF).
While I believe professional first-line-of-enforcement would reduce abusive reporting, the UCOC/enforcement guidelines don't do that, and they leave first-line-of-enforcement to enwiki, so in that sense, it's not changing, which means I don't believe that it'll have an effect on abusive reporting. However, I think the possibility for appeal to the U4C (or whatever it's called) would reduce abusive reporting by allowing another level of review, one of the things I like about the enforcement guidelines. Levivich (talk) 22:14, 16 January 2023 (UTC)
References

References

  1. ^ Siapera, Eugenia; Viejo-Otero, Paloma (January 22, 2021). "Governing Hate: Facebook and Digital Racism". Television & New Media. 22 (2): 112–130. doi:10.1177/1527476420982232. ISSN 1527-4764.
  2. ^ Matamoros-Fernández, Ariadna (3 June 2017). "Platformed racism: the mediation and circulation of an Australian race-based controversy on Twitter, Facebook and YouTube". Information, Communication & Society. 20 (6): 930–946. doi:10.1080/1369118X.2017.1293130. ISSN 1369-118X.
  3. ^ Matamoros-Fernández, Ariadna; Farkas, Johan (January 22, 2021). "Racism, Hate Speech, and Social Media: A Systematic Review and Critique". Television & New Media. 22 (2): 205–224. doi:10.1177/1527476420982230. ISSN 1527-4764.
  4. ^ Yasseri, Taha; Menczer, Filippo (28 April 2021). "Can the Wikipedia moderation model rescue the social marketplace of ideas?". {{cite journal}}: Cite journal requires |journal= (help)
  5. ^ de Laat, Paul B. (1 June 2012). "Coercion or empowerment? Moderation of content in Wikipedia as 'essentially contested' bureaucratic rules". Ethics and Information Technology. 14 (2): 123–135. doi:10.1007/s10676-012-9289-7. ISSN 1572-8439.
  6. ^ Seidel, Niels (3 July 2019). "Democratic power structures in virtual communities". EuroPLop '19. New York, NY, USA: Association for Computing Machinery: 1–8. doi:10.1145/3361149.3361181. ISBN 978-1-4503-6206-1. {{cite journal}}: Cite journal requires |journal= (help)
  • Note, voting has opened on the UCOC-REG, I've added it to the Watchlist Notice per the precedent of the last notice. — xaosflux Talk 00:58, 17 January 2023 (UTC)
  • After 3 days this RfC has, at the time I write this, attracted 22 participants who've given a topline comment in "responses". After less than 1 day of voting, the official ratification has had 151 participants whose homewiki is English Wikipedia. It appears that there will be a consensus of some kind reached here and it should be respected for what it is. But what it is not is a consensus of people interested in the UCoC on English Wikipedia. Best, Barkeep49 (talk) 15:50, 17 January 2023 (UTC)
    I agree completely. I still tend to think this RfC was created to serve as a fait accompli, and struggle to see how this could be interpreted by WMF in any way other than "micro-consensus". 🌈WaltCip-(talk) 13:33, 19 January 2023 (UTC)
  • Quick question: Isn't there already a mechanism for users to vote on the enforcement guidelines? Why this second vote? Surely, anyone can go vote in the SecurePoll vote and have their voice heard that way. Why are we having a second vote here? --Jayron32 18:43, 19 January 2023 (UTC)
    If I understand correctly, the point of this RfC is to discuss whether the SecurePoll is about the right question. ~ ToBeFree (talk) 20:07, 20 January 2023 (UTC)

Enforcement guideline results posted

The results of the vote across all projects has been posted on meta. 76% of editors voted in favor with 3097 editors participating in this second vote. In terms of enwiki participation While 1007 voters had their homewiki registration set to English Wikipedia, only 803 voters had their most edits there. Best, Barkeep49 (talk) 19:32, 13 February 2023 (UTC)

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.

Desired... a commercial web hosting division of Wikimedia Foundation that allowed wikilinking to Wikipedia

Closing as the wrong forum. Questions about what services WMF is willing to provide are best asked at meta:Wikimedia Forum. Questions about what features a particular third-party hosting provider has are best directed to that provider, for example https://meta.miraheze.org/wiki/Help_center -- RoySmith (talk) 02:15, 26 February 2023 (UTC)

The following discussion 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.


While the Wikimedia Foundation does not offer web hosting services, it does provide free and open source software, including the MediaWiki platform, which powers Wikipedia and many other wikis. Anyone can download and install MediaWiki on their own web server or hosting provider, allowing them to create their own wiki.

Additionally, there are many web hosting companies that specialize in hosting MediaWiki and other wiki software. These hosting providers often offer one-click installs and other tools to make it easy to set up and manage a wiki.

It would be nice if Wikimedia Foundation had a commercial web hosting division that allowed one-way direct wikilinking to Wikipedia's articles. -- Valjean (talk) (PING me) 17:43, 25 February 2023 (UTC)

My understanding is that the default install of MediaWiki includes mw:Manual:Interwiki link support for English Wikipedia, and a language prefix can be also be specified which will allow for redirecting to any language (see meta:Help:Interwiki linking for details). This doesn't guarantee, of course, that any given MediaWiki installation will choose to keep this default enabled. isaacl (talk) 18:02, 25 February 2023 (UTC)
isaacl, if I understand you correctly, it sounds like there is already a wikilinking function that works from a private installation of the MediaWiki software. Is that correct?
It's many years since I had my own free website hosted at Yahoo! GeoCities (yes, I'm that old!). I'd like to start one up again, now that I'm retired. That would be an outward-facing effort visible to the public.
I also wonder if it's possible to download the MediaWiki software to one's own PC and just develop content there, then later copy it to one's own website or Wikipedia (if it's compatible with PAG). -- Valjean (talk) (PING me) 19:08, 25 February 2023 (UTC)
Yes, the same function that allows editors on Wikipedia to use prefixes such as commons:, meta:, and w: (for Wikipedia) is part of the default MediaWiki software, and there is a default interwiki link configuration. Not sure what policy and guidelines you are thinking of? No one can stop you from writing your own web pages, whether or not you are using MediaWiki software. (If you copy text from anywhere or are deriving your work from someone else's, of course, you are subject to copyright considerations and the licenses offered by the sources.) You can see mw:Manual:Installing MediaWiki for information on installing MediaWiki. isaacl (talk) 19:15, 25 February 2023 (UTC)
When I wrote "or Wikipedia (if it's compatible with PAG)", I was referring to content that would go into any article here. They are of course governed by PAG. Thanks so much for the good info. -- Valjean (talk) (PING me) 20:45, 25 February 2023 (UTC)
This is not a direct concern of the English Wikipedia. You would be better off suggesting this at meta:. Phil Bridger (talk) 19:24, 25 February 2023 (UTC)
That makes sense. Thanks. Is there a specific "village pump" type of place that would be best? -- Valjean (talk) (PING me) 20:45, 25 February 2023 (UTC)
See Comparison of wiki hosting services for some places which will host a wiki for you. I use Miraheze; it's free, no ads and uses MediaWiki.-gadfium 19:41, 25 February 2023 (UTC)
gadfium, does it allow wikilinks to work between your website and Wikipedia? If so, do red wikilinks work in the same way as here? -- Valjean (talk) (PING me) 20:48, 25 February 2023 (UTC)
There is no legitimate excuse for the Wikimedia Foundation, a not-for-profit educational corporation, to run such an operation. It has no relationship to the corporation's purpose for existence. --Orange Mike | Talk 01:02, 26 February 2023 (UTC)
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.

Make Wikipedia:Requested moves/Closing instructions a guideline

Moved to Wikipedia:Village pump (policy)#Make Wikipedia:Requested moves/Closing instructions a guideline
 – Levivich (talk) 17:56, 26 February 2023 (UTC)

Community-authorized sanctions for gender identity

Proposal: Apply extended-confirmed restriction and one revert restriction through general sanctions to all topics relating to gender identity, including transgender and non-binary gender

There are currently ARBCOM sanctions on topics related to gender and sexuality as described at WP:GENSEX. This allows uninvolved administrators to apply and enforce restrictions on related articles and editors in this topic area. Unfortunately, it seems that this is not sufficient to prevent widespread disruption in the topic area. Gender identity is highly contentious and causes significant disruption, and that's unlikely to change any time soon. Furthermore, this topic area is among those most capable of causing real world harm. For these reasons, I'm proposing the creation of community-authorized WP:ARBPIA-equivalent restrictions for this subject. This would entail:

It would not replace or change the ARBCOM GENSEX sanction, but it would supplement it in this specific area with ECR and 1RR. To my understanding, this is the highest level of restriction in use under general sanctions, and it currently applies to Palestine–Israel, the Syrian Civil War and ISIL, and cryptocurrency. Before any RfC is created, I'm posting this proposal here to determine:

  • Whether support for this exists
  • If so, at what scope; whether a more limited scope such as transgender BLPs, or more broadly into LGBT topics
  • If there are any stipulations or other considerations that would need to be addressed in a hypothetical RfC
  • That I didn't completely misinterpret how all of this works

If there is support for this proposal, then the next step would be to create an WP:AN RfC to formally authorize these sanctions. Thebiguglyalien (talk) 19:59, 22 February 2023 (UTC)

WP:WikiProject LGBT studies has been notified of this discussion. Thebiguglyalien (talk) 23:41, 22 February 2023 (UTC)
Note, saw this before the notification went out, though I am active in that WikiProject. I'm a pretty active editor across many GENSEX articles, if I'm not patrolling recent changes for any sort of vandalism or disruptive editing, you'll likely find me on a talk page somewhere hashing out content. I've some remarks on each of the three proposals:
  1. This seems largely redundant. GENSEX is already a CTOP area through the past ArbCom cases and motions listed on WP:GENSEX.
  2. On the surface this isn't a bad idea. As you've alluded to, it would prevent drive-by article space disruption by both IP editors and new accounts, which would certainly cut down on certain types of disruption like inserting deadnames or mass pronoun changes of BLPs, or spurious accusations based on typical anti-LGBT+ canards. However I'm not sure it would actually solve the current overall problems in the content area. From my perspective, one of the biggest problems is that we have a set of established behaviourally problematic editors in this content area, all of whom to my knowledge are extended confirmed, that this restriction would not directly affect.
  3. A blanket 1RR seems overly draconian to me. As a tool to prevent disruption, it has its uses on a targeted per-article basis, but as a blanket "all articles are now subject to 1RR". 1RR has by its nature a stabilising effect on articles sure, but that also has the effect of making rewrites, and major additions or removals significantly harder for all involved.
In terms of actually fixing what's currently broken in GENSEX, I don't think that this would have the desired effect. I'd also be concerned at the unintentional side effect of scaring off good faith new editors from this area. Maybe I'm wrong though, and I'd be interested to hear from editors in the other content areas you've identified that have these restrictions if they find that those restrictions have actually helped that content area, or if they've just moved the trouble spots elsewhere. Sideswipe9th (talk) 00:17, 23 February 2023 (UTC)
@Thebiguglyalien, here's how I'm understanding your proposal.
  • You believe that 99.75% of all registered editors should be banned from editing or writing articles about trans people.
  • 99.75% of all registered editors should be banned from joining this discussion, or any discussion like it, because it's not in the Talk: namespace.
  • If a celebrity reveals a different gender identity today, then only the top 0.25% of editors should be allowed to make our articles comply with MOS:GENDERID. The other 99.75% of editors should be warned and blocked if they try to help out.
  • Editors attending edit-a-thons (such as Art+Feminism) and students in organized classes (there are more 4000 students in more than 300 classes running right now) should be banned from editing anything even remotely related to gender. We should definitely cancel any groups that want to write about women's health or women's politics, because someone might have to decide whether to write "the woman's uterus" or "the uterus", and that's gender-related.
And the justification for this is: People who have already achieved not only ECR, but Wikipedia:Unblockable status, can and do perpetuate gender-related disputes for years, while an IP can be blocked out of hand and pages can be protected to prevent them from editing entirely. Right? WhatamIdoing (talk) 18:55, 27 February 2023 (UTC)
  • The OP has asserted that WP:GENSEX restrictions are inadequate to stop disruption, but there are no diffs or links to anything to back up that assertion. If we're going to supercede the existing ArbCom sanctions scheme, shouldn't we at least have evidence that the current sanctions are not working? --Jayron32 19:26, 27 February 2023 (UTC)
I'd support adding WP:ARBECR to WP:GENSEX. ARBECR has helped in the WP:PIA and WP:APL and the community recently authorized it for WP:RUSUKR, WP:KURDS, and WP:ARBAA. GENSEX has the same problem with socking/drive-by/inexperienced editors as the other topic areas. For examples of current sanctions not working, just look at the two ANI threads in the GENSEX topic areas right now (which, in my view, have been disrupted by non-ECR editors, on both "sides" of the issue). I think the "99.75%" figure is a lark; most registered accounts never edit; we have 40 million registered accounts; half of them (20 million) never made any edits; only 2 million made 10 edits; only 450k made 100 edits; only 100k hit ECR. And yes, I think it's a good idea to not allow new editors to edit in our most-contentious contentious topics. I'm much less sure about 1RR being effective or necessary; I think I'd only be in favor of that upon a showing that there is so much edit-warring in this topic area that the usual 3RR isn't working. Levivich (talk) 19:34, 27 February 2023 (UTC)
Looking at both discussions at ANI (One involving Newimpartial and one involving Tranarchist), and neither has significant disruption from anyone that wouldn't already qualify for ECR. Well over 90% (and possibly vanishingly close to 100%) of the text in those two ANI discussions, involve well experienced editors. I have spent 5+ minutes paging through them, and while I'm sure a small number of comments in those discussions may be from new or "drive-by" editors, I can't at first glance identify any obvious ones, the vast bulk of the text in those discussions is from very experienced Wikipedia editors. You're going to need better examples than that. If nothing else, your examples have served to show places where it isn't a problem; it's clear evidence against needing any ECR sanctions, since so little of those discussions is taken up with any such people. --Jayron32 20:22, 27 February 2023 (UTC)
@Jayron32: OK, look here (whole page, top to bottom), perhaps a better example of significant timesink from multiple non-XCs. Levivich (talk) 23:36, 27 February 2023 (UTC)
Here's a complete list of the edit counts for every person who's ever edited that talk page, in order by the number of edits made to that page (which, BTW, they would all still be allowed to do under this proposal):
  • 22K edits + 14 years
  • 350 edits + 6 years
  • 1300 edits + 1 year
  • 19K edits + 4 years
  • 7K edits + 15 years
  • 250 edits + 1.75 years
  • (sock)
  • 31K + 5 years
  • (IP) 1 edit
  • 300 edits + 2 years
  • 3800 edits, 7 years
  • 95K + 13 years
  • 5K edits + 1 year
That's 13 editors. Ignoring the sock, there are only three registered accounts and one IP that would be banned from editing, and all of them could reach extended-confirmed by spending a couple of hours doing some kind of trivial high-volume editing mindless, like removing dead links from ==External links== sections. Also, the IP and one registered account has made just one edit to the talk page, and another has made only three, so if your goal is to reduce the number of comments, I suggest that excluding the people who don't post much anyway is not going to make much difference. WhatamIdoing (talk) 23:55, 27 February 2023 (UTC)
That's missing the forest for the trees. The edits by the non-XC editors on your list prompted the edits by the XC editors on your list, and wasted their time. There are 8 threads on that talk page:
  1. Started by a sock with 14 edits who argues with several editors before getting blocked
  2. different non-XC 1AM with poor understanding of sourcing
  3. same
  4. same
  5. productive thread by XC editors
  6. different non-XC with poor understanding of sourcing
  7. IP general complaint about bias
  8. Third non-XC with poor understanding of sourcing
All but one thread wasted editor time. It was a lot of time wasted. Levivich (talk) 00:03, 28 February 2023 (UTC)
Unless I'm missing something, if ARBECR was applied to the GENSEX content area we'd still have to respond to those threads on article talk pages in some way. ARBECR would only prevent article space disruption, and to a lesser extent related discussions in the project namespace. Sideswipe9th (talk) 00:07, 28 February 2023 (UTC)
Yes, this is true. ARBECR would not actually prevent this particular type of disruption (unproductive talk page discussions). I'm just pointing to this as an example of disruption in the topic area by non-XC editors. But look at the article history and you see non-XC editors also having to be reverted there (even by you in some cases, lol), which seems like most of the last six months of edits to that page. I think they're wasting your time Sideswipe but I would take your word for it (and that of other regulars in the topic area) if you thought different. Levivich (talk) 00:13, 28 February 2023 (UTC)
I've already put forward my thoughts on the initial proposal above. ARBECR is not a bad suggestion per say, we do get a lot of disruptive drive-by article space edits that need some sort of cleanup and this would put an instant stop to that. But for actually fixing what I see as broken in the GENSEX content area, I don't think it would actually address any of the root problems. Sideswipe9th (talk) 00:20, 28 February 2023 (UTC)
You're right, that it doesn't stop all, maybe not even most, disruption. But I see the success of ARBECR in, for example, the Holocaust topic area right now. This controversial high-profile paper comes out, it's all over Twitter and such, it should be bringing in a bunch of new editors and IPs POV-pushing from all angles, but it's not, because all those pages are ECP'd. So if you look, for example, here, here, or here, you still see editors arguing about stuff, maybe disruptively maybe not, but it's experienced editors. What you don't see is the non-XC wasting people's time on talk pages, even though the talk pages aren't ECP'd, but the articles are, and that makes the difference. I think ARBECR is noticeably reducing the amount of disruption there otherwise would be in that topic area right now. Compare with Seymour Hersh or Killing of Tyre Nichols--both high profile but not ECP'd--and you see a lot more disruption there. Levivich (talk) 00:38, 28 February 2023 (UTC)
Maybe it's because I'm too tired right now, but it seems like you're saying that ECPing all of the mainspace pages in a contentious content area also has a measurable decrease in disruption in the related talk space? Is this something specific to the examples you've provided, or is it also reflected in other ARBECR areas? Sideswipe9th (talk) 00:44, 28 February 2023 (UTC)
Yeah you've got me right: mainspace ECP reduces talk page disruption. I've also seen it in WP:ARBPIA, like Israel. There you see the same thing as in the Holocaust articles: a long, often quite contentious, content dispute on the talk page amongst a number of experienced editors, but not really any disruption by non-XC editors. The article is protected, the talk page is not, and there has been a major escalation in violence in that conflict in the real world in the past month or two, and you'd expect this big influx of new editors, but it's just not there. Which lets the experience editors focus. To my eyes, when I look at Holocaust or Israel/Palestine talk pages, they look very different from gensex talk pages, it's a more focused and productive form of disruption :-D Levivich (talk) 00:48, 28 February 2023 (UTC)
Interesting! In that case, I would be open to at least trailing it for 6 to 12 months to see what sort of effect it has. If it does result in the same lessening of disruption on talk pages as well as in articles, I wonder if perhaps it might bring some of the other behavioural problems from other long term editors into sharper focus. As if it does, then it would also indirectly help solve what I see to be one of the root problems in the content area.
There's a few procedural niggles that I and probably a few other editors would need some clarification on. Because GENSEX deals with identities, the delineation between when an article is or is not covered under it is a bit more fluid than other content areas. For example how do we handle BLPs where notable person John/Jane Doe comes out as trans or non-binary and changes their name? Sure I can now slap a GENSEX alert onto the talk page, but would I also be able to go to RFPP and say "BLP subject, came out as trans, article now covered under GENSEX ARBECR" and straightforwardly get the page protected? And how would we handle articles that contain or could contain GENSEX content, but where GENSEX isn't the primary topic? For example man, woman, pregnancy, vaginoplasty, phalloplasty. Sideswipe9th (talk) 01:03, 28 February 2023 (UTC)
Articles that are in, or that enter, the topic area scope can be tagged. I don't think ECP is applied just as a matter of course, but if/when there is disruption, the RFPP request will get approved as a no-brainer, and often will be indef instead of temporary so you only have to ask once. For articles that aren't mostly in-scope but have some in-scope content, those I don't think usually get indef ECP'd, sometimes temporary ECP, but reverting a non-XC editor is a 3RRNO, so it's still very easy to enforce. Similarly, non-XCs can post "constructive comments and make edit requests" on article talk pages, but they can't vote in RFCs, RMs, AFD, RSN, BLPN or any other project discussion. It also stops non-XCs from creating new articles in scope (in theory, NPP catches it, but if not, it can be CSD'd). Levivich (talk) 01:14, 28 February 2023 (UTC)
In re "I think the "99.75%" figure is a lark; most registered accounts never edit" for @Levivich: If you want to count only registered editors who have successfully completed an edit (a number that is smaller than the number who tried), then extended-confirmed excludes about 99.2% of all registered editors. That still excludes a lot of editors. WhatamIdoing (talk) 00:00, 28 February 2023 (UTC)
That's no more convincing than pointing out the pool of XC editors is over 64,000. There are lots of editors. Most are not extended confirmed. Even more are not autoconfirmed. Even more have never made an edit. That doesn't mean anything, and portraying it in terms of "percentage of editors excluded" is rhetoric, not logic. The logic is to exclude inexperienced editors; that fact that 99% of registered accounts are inexperienced is besides the point, since 87% of registered accounts don't currently edit anyway. We have like 50k active editors out of 40+ million accounts, so that's 87.5% (I think) of editors do not currently edit. It's just an example of "lies, damned lies, and statistics." Levivich (talk) 00:16, 28 February 2023 (UTC)
  • I have to agree with Levivich… the proposal is overkill, and would result in many editors (who are not editing disruptively) being restricted from contributing. I see no evidence that our current restrictions and cautions are not working. Therefor, I must Oppose. Blueboar (talk) 20:16, 27 February 2023 (UTC)
  • Yup, overkill. What is actually needed is broader enforcement of Wikipedia policies (e.g. WP:NPOV, WP:RS etc) in BLPs generally, and firmer action against those who use such articles as political battlegrounds. Picking out specific topics to police such content over misses the point - we shouldn't be allowing it to happen anywhere. At some point, I suspect Wikipedia will be obliged to implement restrictions on editing biographies of living persons generally, but until that happens, we should be enforcing existing policy consistently, which this proposal clearly won't do. AndyTheGrump (talk) 01:18, 28 February 2023 (UTC)
  • Everything GENSEX-related reminds me of the hand-wringing that occurred around 2007 over intelligent design (which seemed to take over the entire 'pedia), and then a few years later, the hand-wringing that occurred over climate change, a content area brought well under control by the dedication of Femke and Co. The problematic editors make the headlines (ANI), but we have a bevy of very experienced editors holding down the fort. Editing in this area is no better and no worse than in any other areas. Deal with problematic editors as they come up; don't paint the entire topic area with too broad of a brush. No need to freak out because we happened to have two threads at once at ANI. SandyGeorgia (Talk) 01:46, 28 February 2023 (UTC)

Statistics

Within articles covered by WP:WikiProject LGBT studies:

  • 68.7% of edits are by extended-confirmed editors
    • 5.3% of edits by extended-confirmed editors are reverted
    • 32.3% of edits by non-extended-confirmed editors are reverted
  • 78.3% of edits are by auto-confirmed editors
    • 7% of edits by auto-confirmed editors are reverted
    • 18.5% of edits by auto-confirmed but not extended-confirmed editors are reverted
    • 38.4% of edits by non-auto-confirmed editors are reverted.

BilledMammal (talk) 01:26, 28 February 2023 (UTC)

How does that compare to BLPs, and to Wikipedia articles generally? AndyTheGrump (talk) 01:36, 28 February 2023 (UTC)
To compare it to BLP's I either need a template or category that marks them as those; unfortunately, I haven't been able to find one. If you know one then I can get those figures for you. For all Wikipedia articles, see this query. It hasn't returned yet, and note that it doesn't cover as long a period of time as the LGBT studies one in order to keep the run time reasonable. BilledMammal (talk) 01:58, 28 February 2023 (UTC)
Category:Living people? Levivich (talk) 02:07, 28 February 2023 (UTC)
Thank you, Quarry:query/71867. BilledMammal (talk) 03:01, 28 February 2023 (UTC)
BLPs
  • 69.5% of edits are by extended-confirmed editors
    • 3.7% of edits by extended-confirmed editors are reverted
    • 20.2% of edits by non-extended-confirmed editors are reverted
  • 78% of edits are by auto-confirmed editors
    • 5% of edits by auto-confirmed editors are reverted
    • 14.5% of edits by auto-confirmed but not extended-confirmed editors are reverted
    • 39.7% of edits by non-auto-confirmed editors are reverted.
All Articles
  • 69.3% of edits are by extended-confirmed editors
    • 3.6% of edits by extended-confirmed editors are reverted
    • 18.3% of edits by non-extended-confirmed editors are reverted
  • 78.9% of edits are by auto-confirmed editors
    • 4.8% of edits by auto-confirmed editors are reverted
    • 13.8% of edits by auto-confirmed but not extended-confirmed editors are reverted
    • 37.6% of edits by non-auto-confirmed editors are reverted.
BilledMammal (talk) 03:01, 28 February 2023 (UTC)
Are you still taking requests? Could I interest you in running that for articles that are tagged as specific CT topics, like maybe AP2? I'm curious how other CT topics look. Levivich (talk) 03:17, 28 February 2023 (UTC)
I don't know a category that would allow me to determine AP2, but I've done:
Table of results
Topic Edit count Revert Count % reverted (total) Extended-confirmed edit count Extended-confirmed revert count % reverts (extended-confirmed) non-extended-confirmed edit count non-extended-confirmed revert count % reverts (non-extended-confirmed) Auto-confirmed edit count Auto-confirmed revert count % reverts auto non-auto-confirmed edits non-auto-confirmed reverts % reverts (non-auto-confirmed) Auto-confirmed but not extended-confirmed edits Auto-confirmed but not extended-confirmed reverts % reverts (Auto-confirmed but not extended-confirmed) % edits by extended-confirmed editors % edits by auto-confirmed editors
The Troubles 65002 8493 0.1307 49940 2169 0.0434 4567 1438 0.3149 53433 2976 0.0557 1074 631 0.5875 3493 807 0.231 0.7683 0.822
Kashmir 33717 6637 0.1968 19881 1687 0.0849 6293 2299 0.3653 24938 3428 0.1375 1236 558 0.4515 5057 1741 0.3443 0.5896 0.7396
Kurds 49318 8724 0.1769 35348 2630 0.0744 5868 2091 0.3563 40097 4078 0.1017 1119 643 0.5746 4749 1448 0.3049 0.7167 0.813
Afghanistan 89855 15376 0.1711 59596 4202 0.0705 13538 4417 0.3263 71277 7727 0.1084 1857 892 0.4803 11681 3525 0.3018 0.6632 0.7932
Pakistan 349278 61605 0.1764 209837 13483 0.0643 52247 16838 0.3223 251952 25577 0.1015 10132 4744 0.4682 42115 12094 0.2872 0.6008 0.7214
India 2572663 386138 0.1501 1537016 82407 0.0536 397122 104057 0.262 1863695 157983 0.0848 70443 28481 0.4043 326679 75576 0.2313 0.5974 0.7244
Contentious topics 640276 99078 0.1547 488465 38296 0.0784 71486 22968 0.3213 550595 55775 0.1013 9356 5489 0.5867 62130 17479 0.2813 0.7629 0.8599
If there are any others you want me to run, or category that would be suitable for AP2, I can run those as well. BilledMammal (talk) 05:07, 28 February 2023 (UTC)
Thanks! I guess talk pages for all CTs are in Category:Wikipedia pages about contentious topics, but I don't see categories for specific topics, which is too bad, the template could subcategorize by topic. Levivich (talk) 05:22, 28 February 2023 (UTC)
I've run one for that category, but I wouldn't consider it a reliable baseline because that template isn't used consistently; it is more likely to be included on contentious articles within the topic than less contentious ones, and because of this the results will overestimate how contentious these topics as a whole are. BilledMammal (talk) 05:39, 28 February 2023 (UTC)
(60% of Pakistan edits reverted??) Thanks for this. If I'm summarizing all of the above correctly:
  • For all articles on Wikipedia, edits by WP:XC editors (>500 edits) are reverted ~4% of the time, editors between WP:AUTOC and WP:XC (10-500 edits) 14%, non-AUTOC (<10 edits) 38%
  • For WP:BLPs, that breakdown is XC 4%, AUTOC-XC 15%, non-AUTOC 40%
  • For (some but not all) WP:CTs, XC 8%, AUTOC-XC 28%, non-AUTOC 59%
  • For Kashmir, Kurds, Afghanistan, Pakistan, and India, XC 5-9%, AUTOC-XC 23-34%, non-AUTOC 40-57%
  • For WikiProject LGBT studies, XC 5%, AUTOC-XC 19%, non-AUTOC 38%
Does "non-AUTOC" include IP edits? Levivich (talk) 06:11, 28 February 2023 (UTC)
Oh, that was an error; 60% of edits are made by extended confirmed editors, 18% are reverted.
non-AUTOC includes IP edits, and your summary looks correct to me. BilledMammal (talk) 06:45, 28 February 2023 (UTC)
Be careful or they're gonna ban us again Levivich (talk) 07:07, 28 February 2023 (UTC)
And what dark magic are you using to conjure these statistics? Levivich (talk) 01:38, 28 February 2023 (UTC)
Quarry; the query for the above is here. BilledMammal (talk) 01:58, 28 February 2023 (UTC)

A better way for dealing spam

Hello everyone, I have dealt with spams on newly created pages for a while. I believe they are in the likely patterns,

  1. a new user registered
  2. shortly added spam links, email address and something like that on their user pages, user sandboxes or user talk pages.

Could we add a filter for tagging them with specific edit summary? For example, new users adding links contain their own usernames or new users adding links on their subpages. It will be better for us to deal with spams. -Lemonaka‎ 18:24, 3 March 2023 (UTC)

We already do this sort of stuff. Edit filter 80 is a spam throttle for adding the same link over and over, Edit filter 149 flags edits where the link matches the username. If you have a specific type of spamlink that a regex-based filter may catch that these aren't, Wikipedia:Edit filter/Requested is the place to go. --Jayron32 19:32, 3 March 2023 (UTC)
@Jayron32 Hi, thanks. I have checked logs of 149 and found they are focused on article namespace, however, most spams are coming from user namespace and subpages of that. Could we expand this filter? Or shall I request on Wikipedia:Edit filter/Requested -Lemonaka‎ 09:44, 4 March 2023 (UTC)
Oh, I found that, [[1]] -Lemonaka‎ 09:54, 4 March 2023 (UTC)

Requesting permission to engage in mass-creation

Per MASSCREATION and WP:SEMIAUTOMATED, I request permission to mass-create articles pertaining to villages and municipalities in Turkey, including templates and categories. After creating many articles, was advised to seek permission for such semi-automated creations. Discussion here here. Semsûrî (talk) 17:40, 28 February 2023 (UTC)

Table of articles created by Semsûrî on villages and municipalities in Turkey, between December 2022 and February 2023 (2010 articles)
Article Size (bytes) Creation date
100. Yıl, Adıyaman 1224 2023/01/27
Acar, Artuklu 1084 2023/01/03
Acıkköy, Nusaybin 1343 2023/01/01
Acırlı, Midyat 1373 2022/12/30
Adakale, Baykan 1212 2023/01/15
Adakent, Derik 1276 2023/01/07
Adaklı District 3628 2023/02/04
Adaklı, Midyat 1319 2022/12/29
Adaklı, Yüksekova 1852 2022/12/16
Adak, Derik 1273 2023/01/07
Adaköy, Ovacık 1451 2023/02/13
Adıgüzel, Şirvan 1136 2023/01/13
Ahmetli, Artuklu 1567 2023/01/02
Ahmetli, Derik 1097 2023/01/07
Akalın, Kızıltepe 1611 2023/01/05
Akalın, Yüksekova 1309 2022/12/17
Akarsu, Beytüşşebap 1460 2022/12/20
Akarsu, Nusaybin 1436 2023/01/01
Akağıl, Nusaybin 1353 2023/01/01
Akbağ, Artuklu 1563 2023/01/02
Akbinek, Adaklı 1298 2023/02/05
Akbulut, Hakkâri 2357 2022/12/18
Akdam, Kurtalan 1199 2023/01/17
Akdağ, İdil 1279 2022/12/26
Akdemir, Pertek 1381 2023/02/14
Akdiken, Eruh 1574 2023/01/08
Akdik, Pülümür 1454 2023/02/15
Akdizgin, Güçlükonak 1312 2022/12/24
Akdoğan, Kızıltepe 1362 2023/01/05
Akdoğmuş, Siirt 1598 2023/01/09
Akdüven, Mazgirt 1641 2023/02/12
Akgeçit, Şirvan 1246 2023/01/13
Akhisar, Adıyaman 1193 2023/01/27
Akkavak, Mazgirt 1635 2023/02/12
Akkaya, Çukurca 4844 2022/12/17
Akkoyunlu, İdil 1285 2022/12/27
Akkoç, Kızıltepe 1349 2023/01/05
Akkuş, Hakkâri 2231 2022/12/18
Akkuş, Kahta 1380 2023/01/22
Akmeşe, Eruh 1679 2023/02/15
Akocak, Yüksekova 1683 2022/12/17
Akpazar, Mazgirt 1747 2023/02/12
Akpınar, Hozat 1484 2023/02/15
Akpınar, Yüksekova 1762 2022/12/16
Aksoy, İdil 1323 2022/12/26
Aksu, Hakkâri 2203 2022/12/18
Aksu, Mazıdağı 1116 2023/01/05
Aksu, Silopi 2826 2022/12/20
Aksu, Yüksekova 1385 2022/12/17
Aksöğüt, Kurtalan 1140 2023/01/17
Aktarla, Mazgirt 1614 2023/02/13
Aktaş, Adaklı 1360 2023/02/05
Aktaş, Ovacık 1477 2023/02/13
Aktaş, Siirt 1225 2023/01/10
Aktepe, Kızıltepe 1623 2023/01/05
Aktepe, Silopi 1302 2022/12/21
Aktoprak, Genç 1470 2023/02/11
Aktulga, Kızıltepe 1350 2023/01/05
Akyamaç, Siirt 1273 2023/01/09
Akyayla, Tillo 1446 2023/01/12
Akyayık, Ovacık 1509 2023/02/13
Akyazı, Kızıltepe 1358 2023/01/05
Akyokuş, Ömerli 1339 2022/12/31
Akyokuş, Şirvan 1326 2023/01/12
Akyol, Dargeçit 1342 2022/12/27
Akyünlü, Mazgirt 1633 2023/02/13
Akyürek, Savur 1306 2023/01/04
Akyüz, Kızıltepe 1602 2023/01/05
Akyıldız, Kahta 1368 2023/01/22
Akyıldız, Silopi 1313 2022/12/21
Akziyaret, Kızıltepe 1358 2023/01/05
Akçakuşak, Güçlükonak 1358 2022/12/24
Akçaköy, Dargeçit 1320 2022/12/27
Akçalı, Hakkâri 2429 2022/12/18
Akçalı, Kurtalan 1139 2023/01/16
Akçalı, Yüksekova 1324 2022/12/17
Akçapınar, Kızıltepe 1358 2023/01/05
Akçapınar, Çemişgezek 1584 2023/02/15
Akçatarla, Nusaybin 1344 2023/01/01
Akçayar, Şirvan 1137 2023/01/13
Akçayol, Beytüşşebap 1247 2022/12/20
Akçayunt, Çemişgezek 1361 2023/02/15
Akçay, Derik 1103 2023/01/07
Akçay, Şırnak 1322 2022/12/22
Akça, Kızıltepe 1474 2023/01/05
Akçegedik, Kurtalan 1141 2023/01/17
Akımlı, Yedisu 1378 2023/02/04
Akıncılar, Derik 1413 2023/01/07
Akıncı, Artuklu 1326 2023/01/02
Alaaddin, Genç 1585 2023/02/11
Alagöz, Derik 1398 2023/01/07
Alagöz, Kiğı 1270 2023/02/04
Alakamış, İdil 1384 2022/12/26
Alakuş, Artuklu 1311 2023/01/02
Alakuş, Kızıltepe 1609 2023/01/05
Alakuş, Çemişgezek 1350 2023/02/15
Alancık, Hozat 1480 2023/02/15
Alanlı, Derik 1099 2023/01/07
Alanyazı, Mazgirt 1544 2023/02/13
Alatepe, Bingöl 1290 2023/02/10
Alayunt, Dargeçit 1320 2022/12/27
Alaçık, Tunceli 1594 2023/02/16
Alemdar, Kızıltepe 1615 2023/01/05
Alhan, Mazgirt 1600 2023/02/12
Alibey, Derik 1385 2023/01/07
Alibir, Bingöl 1307 2023/02/10
Alipaşa, Kızıltepe 1306 2023/01/05
Altınbaşak, Üzümlü 1337 2023/02/25
Altınevler, Adaklı 1309 2023/02/05
Altınhüseyin, Pülümür 1580 2023/02/15
Altınoluk, Dargeçit 1329 2022/12/28
Altınoluk, Yüksekova 1315 2022/12/17
Altınsu, Şemdinli 2247 2022/12/16
Altıntoprak, Kızıltepe 1362 2023/01/05
Altınyüzük, Tunceli 1481 2023/02/16
Altınçevre, Hozat 1416 2023/02/15
Altınışık, Bingöl 1513 2023/02/10
Altıyol, Dargeçit 1320 2022/12/28
Alımlı, Artuklu 1282 2023/01/03
Alınyazı, Yayladere 1413 2023/02/04
Alıçlı, Yeşilli 1308 2022/12/31
Alıçlı, Ömerli 1280 2022/12/31
Ambarlı, Derik 1279 2023/01/07
Ambar, Artuklu 1081 2023/01/03
Ambar, Tunceli 1433 2023/02/16
Anadağ, Derecik 2397 2022/12/15
Anıl, Çemişgezek 1473 2023/02/15
Anıtlı, Midyat 6507 2022/12/29
Anıttepe, Ömerli 1281 2022/12/31
Anıtçınar, Mazgirt 1635 2023/02/12
Arakapı, Kızıltepe 1306 2023/01/05
Araköy, Kızıltepe 1355 2023/01/05
Araköy, Şırnak 1318 2022/12/21
Aran, Artuklu 1304 2023/01/02
Ardıçdalı, Baykan 1414 2023/01/14
Ardıçdibi, Genç 1410 2023/02/11
Ardıçlı, Pülümür 1381 2023/02/15
Ardıçtepe, Bingöl 1403 2023/02/10
Ardıç, Pertek 1495 2023/02/14
Armutalan, Savur 1317 2023/01/04
Armutdüzü, Yüksekova 1902 2022/12/17
Arpaderen, Çemişgezek 1477 2023/02/15
Arpalı, Pertek 1357 2023/02/14
Arpatepe, Artuklu 1349 2023/01/03
Arslanbeyli, Solhan 1389 2023/02/08
Arıcılar, Bingöl 1460 2023/02/08
Arıklı, Kızıltepe 1362 2023/01/05
Arıköy, Mazıdağı 1130 2023/01/05
Arısu, Mazıdağı 1427 2023/01/05
Arıtepe, Kızıltepe 1609 2023/01/05
Aslanlı, Kızıltepe 1614 2023/01/05
Aslanyurdu, Mazgirt 1690 2023/02/13
Asmakaya, Solhan 1507 2023/02/06
Atabağı, Baykan 1358 2023/01/14
Atadoğdu, Tunceli 1480 2023/02/16
Ataköy, Adıyaman 1482 2023/01/25
Ataköy, Kızıltepe 1351 2023/01/05
Atalar, Mazıdağı 1418 2023/01/04
Atalay, Kurtalan 1131 2023/01/16
Ataçınarı, Mazgirt 1734 2023/02/12
Atbaşı, Şırnak 1320 2022/12/22
Atlantı, Tunceli 1534 2023/02/16
Atlıca, Mazıdağı 1145 2023/01/04
Atlı, Derik 1596 2023/01/07
Atmaca, Kızıltepe 1604 2023/01/06
Avcılar, Artuklu 1228 2023/01/03
Avcılar, Kurtalan 1324 2023/01/15
Avunca, Mazgirt 1609 2023/02/13
Ayanoğlu, Yedisu 1405 2023/02/04
Ayazpınar, Pertek 1365 2023/02/14
Ayaz, Kızıltepe 1344 2023/01/05
Aydemir, Kurtalan 1139 2023/01/16
Aydınlar, Derik 1101 2023/01/07
Aydınlar, Yayladere 1479 2023/02/04
Aydınlık, Mazgirt 1654 2023/02/13
Aykut, Mazıdağı 1355 2023/01/04
Ayranlı, Nazımiye 1458 2023/02/13
Ayranlı, Şemdinli 2620 2023/02/12
Aysaklı, Adaklı 1414 2023/02/04
Aytepe, Artuklu 1570 2023/01/02
Ayvadüzü, Adaklı 1435 2023/02/05
Ayvalıbağ, Pervari 1426 2023/01/11
Ayvalık, Beytüşşebap 1246 2022/12/20
Ayvatlı, Mazgirt 1538 2023/02/12
Azıklı, Kurtalan 1138 2023/01/17
Açma, İdil 1316 2022/12/26
Açıkgüney, Kiğı 1424 2023/02/04
Açıkyol, Nusaybin 1340 2023/01/01
Ağaçardı, Mazgirt 1533 2023/02/12
Ağaçdibi, Hakkâri 1959 2022/12/18
Ağaçeli, Bingöl 1298 2023/02/10
Ağaçlıpınar, Kurtalan 1153 2023/01/17
Ağaçpınar, Ovacık 1501 2023/02/13
Ağaçyolu, Bingöl 1299 2023/02/10
Ağaçyurdu, Güçlükonak 1323 2022/12/24
Ağaçöven, Kiğı 1413 2023/02/04
Ağaşenliği, Pülümür 1543 2023/02/15
Ağcin, Adıyaman 1204 2023/01/27
Ağikan, Adıyaman 1399 2023/01/25
Ağveren, Adıyaman 1200 2023/01/27
Aşağı Derecik, Hakkâri 2305 2022/12/18
Aşağıakpınar, Bingöl 1409 2023/02/09
Aşağıazıklı, Kızıltepe 1373 2023/01/05
Aşağıbalcılar, Pervari 1287 2023/01/11
Aşağıbudak, Çemişgezek 1373 2023/02/15
Aşağıdemirbük, Çemişgezek 1474 2023/02/15
Aşağıdere, Beytüşşebap 1644 2022/12/20
Aşağıdoluca, Nazımiye 1602 2023/02/13
Aşağıgülbahçe, Pertek 1408 2023/02/14
Aşağıkonak, Cizre 1303 2022/12/22
Aşağıköy, Bingöl 1313 2023/02/09
Aşağımezraa, Derik 1423 2023/01/07
Aşağıocak, Mazıdağı 1365 2023/01/04
Aşağıoyumca, Mazgirt 1635 2023/02/13
Aşağıtarlacık, Mazgirt 1685 2023/02/13
Aşağıtorunoba, Ovacık 1513 2023/02/13
Aşağıuluyol, Yüksekova 1735 2022/12/17
Aşağıyağmurlu, Karlıova 1344 2023/02/05
Aşağıyeniköy, Artuklu 1107 2023/01/03
Aşağıçeşme, Cizre 1342 2022/12/23
Aşlıca, Ovacık 1525 2023/02/13
Babaocağı, Tunceli 1484 2023/02/16
Babnir, Gercüş 1426 2023/01/29
Bahri, Besni 1519 2023/01/28
Bahçebaşı, Genç 1479 2023/02/11
Bahçebaşı, Nusaybin 1353 2023/01/01
Bahçecik, Mazıdağı 1303 2023/01/04
Bahçeköy, Karlıova 1367 2023/02/06
Bahçeli, Bingöl 1295 2023/02/10
Bakacık, Nusaybin 1623 2023/01/02
Baklalı, Kiğı 1296 2023/02/04
Bakırlı, Pertek 1476 2023/02/14
Balaban, Nusaybin 1878 2023/01/01
Baldan, Tunceli 1357 2023/02/16
Balgöze, Genç 1419 2023/02/11
Balkan, Mazgirt 1632 2023/02/13
Balkaynar, Hozat 1496 2023/02/15
Ballıca, Nazımiye 1501 2023/02/13
Ballıdut, Pertek 1473 2023/02/14
Ballıkavak, Eruh 1342 2023/01/08
Ballıkaya, Kurtalan 1227 2023/01/17
Ballı, Derik 1400 2023/01/07
Ballı, Uludere 1223 2022/12/19
Balova, Derik 1096 2023/01/07
Balpınar, Bingöl 1298 2023/02/09
Balpınar, Mazıdağı 1434 2023/01/05
Balveren, Şırnak 1341 2022/12/21
Balıklıçay, Bingöl 1526 2023/02/08
Bardakçı, Midyat 1390 2022/12/29
Bardakçı, Pülümür 1489 2023/02/15
Barıştepe, Midyat 1396 2022/12/29
Barış, Kızıltepe 1605 2023/01/05
Bataklık, Yüksekova 1365 2022/12/17
Batman District 4500 2023/01/29
Batman, Tunceli 1501 2023/02/16
Batur, Dargeçit 1312 2022/12/28
Batıayaz, Yayladere 1430 2023/02/04
Baykan District 3536 2023/01/14
Bayköy, Hakkâri 2105 2022/12/18
Baylık, Tunceli 1490 2023/02/16
Bayraklı, Derik 1390 2023/01/07
Bayraktepe, Siirt 1592 2023/01/09
Bayramlar, Sason 1636 2023/02/04
Bayramlı, Eruh 1687 2023/01/08
Baysun, Dargeçit 1315 2022/12/27
Bayındır, Şirvan 1136 2023/01/13
Bayırköy, Derik 1413 2023/01/07
Bayırlı, Genç 1440 2023/02/11
Bayırüzü, Eruh 1592 2023/01/08
Bağdaş, Yüksekova 1706 2022/12/17
Bağlarbaşı, Cizre 1371 2022/12/23
Bağlarbaşı, Midyat 1396 2022/12/30
Bağlarpınarı, Adaklı 1334 2023/02/05
Bağlar, Şemdinli 3376 2022/12/16
Bağlıca, Artuklu 1349 2023/01/02
Bağlıca, Kurtalan 1508 2023/01/16
Bağlıca, Siirt 1110 2023/01/10
Bağlıca, Uludere 1586 2022/12/19
Bağlıisa, Karlıova 1467 2023/02/05
Bağlı, Uludere 1269 2022/12/19
Bağpınar Kuyucak, Adıyaman 1277 2023/01/28
Bağpınar, Şırnak 1410 2022/12/22
Bağrıbütün, Kızıltepe 1388 2023/01/06
Bağsuyu, Çemişgezek 1356 2023/02/15
Bağyaka, Savur 1337 2023/01/03
Bağözü, Dargeçit 1323 2022/12/27
Bağözü, Kahta 1385 2023/01/21
Bağğöze, Eruh 1341 2023/01/08
Bağışlı, Hakkâri 2498 2022/12/18
Başakköy, İdil 1286 2022/12/26
Başak, Kızıltepe 1349 2023/01/06
Başak, Silopi 1299 2022/12/21
Başakçı, Tunceli 1478 2023/02/16
Başaran, Beytüşşebap 1629 2022/12/20
Başaran, Derik 1100 2023/01/07
Başağaç, Savur 1322 2023/01/04
Başağaç, Şırnak 1428 2022/12/22
Başdeğirmen, Kızıltepe 1369 2023/01/06
Başkalecik, Pülümür 1558 2023/02/15
Başkavak, Savur 1610 2023/01/04
Başverimli, Silopi 1357 2022/12/20
Başyurt, Midyat 1327 2022/12/28
Bektaş, Kızıltepe 1354 2023/01/06
Belenoluk, Pervari 1323 2023/01/11
Belen, Dargeçit 1324 2022/12/27
Belençay, Şirvan 1234 2023/01/13
Belli, Kızıltepe 1345 2023/01/06
Bengisu, Savur 1276 2023/01/04
Bentköy, Pervari 1293 2023/01/11
Bereketli, İdil 1280 2022/12/26
Beydamı, Pertek 1392 2023/02/14
Beykent, Kurtalan 1388 2023/01/16
Beylermezraası, Mazgirt 1558 2023/02/13
Beylik, Nusaybin 1336 2023/01/01
Beytaşı, Nazımiye 1425 2023/02/13
Beytüşşebap District 3503 2022/12/25
Beğendik, Pervari 1380 2023/01/11
Beğendi, Dargeçit 1318 2022/12/27
Beşatlı, Yüksekova 1640 2022/12/17
Beşağaç, Beytüşşebap 1595 2022/12/20
Beşbudak, Derik 1103 2023/01/07
Beşbulak, Yüksekova 1295 2022/12/17
Beşelma, Hozat 1463 2023/02/15
Beşevler, Kızıltepe 1608 2023/01/05
Beşikkaya, Ömerli 1337 2022/12/31
Beşik, Kızıltepe 1349 2023/01/06
Beşiri District 5775 2023/01/30
Beşler, Kurtalan 1140 2023/01/16
Beşoluk, Mazgirt 1527 2023/02/12
Beşyol, Siirt 1190 2023/01/10
Bilaloğlu, Bingöl 1490 2023/02/10
Bilekkaya, Yayladere 1314 2023/02/04
Bilekli, Hozat 1373 2023/02/15
Bilgeç, Ovacık 1523 2023/02/13
Bilgili, Eruh 1495 2023/01/08
Billice, Kiğı 1530 2023/02/04
Binekli, Genç 1422 2023/02/11
Bingöl, Eruh 1353 2023/01/08
Birlikköy, Silopi 1419 2022/12/21
Biçmekaya, Pertek 1452 2023/02/14
Bolağaç, Beytüşşebap 1605 2022/12/20
Boncukgöze, Karlıova 1497 2023/02/05
Bostancık, Siirt 1290 2023/01/09
Bostancık, Yüksekova 1830 2022/12/16
Bostancı, Silopi 1419 2022/12/20
Bostanlı, Dargeçit 1324 2022/12/27
Bostanlı, Nazımiye 1515 2023/02/13
Boyaklı, Derik 1420 2023/01/07
Boyalı, Adaklı 1297 2023/02/05
Boybeyi, Hakkâri 2699 2022/12/18
Boydaş, Hozat 1899 2023/02/15
Boylu, Şirvan 1429 2023/01/12
Boyuncuk, Güçlükonak 1344 2022/12/24
Bozalan, Cizre 1433 2022/12/22
Bozatlı, Adıyaman 1403 2023/01/24
Bozatlı, Eruh 1338 2023/01/08
Bozağakaraderbendi, Pülümür 1686 2023/02/15
Bozağaç, Çemişgezek 1430 2023/02/15
Bozbayır, Derik 1409 2023/01/07
Bozburun, İdil 1282 2022/12/26
Bozhüyük, Kurtalan 1141 2023/01/16
Bozhüyük, Kızıltepe 1364 2023/01/06
Bozkanat, Solhan 1525 2023/02/08
Bozkuş, Eruh 1337 2023/01/08
Bozkır, İdil 1279 2022/12/27
Bozok, Derik 1305 2023/01/07
Boztepe, Artuklu 1302 2023/01/03
Bozyamaç, Şemdinli 2236 2022/12/15
Boğalı, Pülümür 1477 2023/02/15
Boğazkapı, Sason 1538 2023/02/04
Boğazköy, Yayladere 1478 2023/02/04
Boğazköy, Şemdinli 2385 2022/12/16
Boğazören, Beytüşşebap 1632 2022/12/19
Budaklı, Midyat 1312 2022/12/29
Budamış, Eruh 1679 2023/01/08
Bulaklı, Yüksekova 1761 2022/12/17
Bulgurcular, Mazgirt 1631 2023/02/13
Bulgurluk, Genç 1493 2023/02/11
Bulgurtepe, Pertek 1492 2023/02/14
Burnak, Ovacık 1467 2023/02/13
Burçköy, Derik 1405 2023/01/07
Buzlupınar, Hozat 1498 2023/02/15
Buzlutepe, Ovacık 1480 2023/02/13
Buğdaylı, Silopi 1300 2022/12/20
Buğday, Artuklu 1317 2023/01/03
Buğulu, Tunceli 1586 2023/02/16
Bölücek, Beytüşşebap 1439 2022/12/20
Bölüklü, Eruh 1591 2023/01/08
Bölüktepe, Kurtalan 1251 2023/01/16
Bölük, Yüksekova 1622 2022/12/16
Böğrek, Derik 1299 2023/01/07
Böğürtlen, Tunceli 1478 2023/02/16
Bülbül, Yeşilli 1441 2022/12/31
Büyükayrık, Kızıltepe 1371 2023/01/06
Büyükbejyan, Kahta 1353 2023/01/22
Büyükboğaziye, Kızıltepe 1383 2023/01/06
Büyükdere, Kızıltepe 1616 2023/01/06
Büyükkardeş, Nusaybin 1366 2023/01/01
Büyükköy, Ovacık 1457 2023/02/13
Büyüktekören, Bingöl 1407 2023/02/10
Büyüktepe, Kızıltepe 1612 2023/01/05
Büyükyurt, Nazımiye 4302 2023/02/13
Büyükçağ, Genç 1489 2023/02/11
Büyükçiftlik, Yüksekova 2319 2022/12/16
Büyükörence, Çemişgezek 1466 2023/02/15
Cantaşı, Kızıltepe 1357 2023/01/06
Cebe, Çemişgezek 1486 2023/02/15
Cevizağacı, Beytüşşebap 3347 2022/12/20
Cevizdalı, Şirvan 1590 2023/01/13
Cevizdibi, Hakkâri 1724 2022/12/18
Cevizlidere, Ovacık 1470 2023/02/14
Cevizlik, Artuklu 1084 2023/01/03
Cevizlik, Şirvan 1137 2023/01/14
Cevizli, Adaklı 1394 2023/02/04
Cevizli, Gercüş 1314 2023/01/29
Cevizli, Çukurca 2099 2022/12/17
Cevizpınarı, Artuklu 1581 2023/01/02
Ceylanlı, Hakkâri 2250 2022/12/18
Cihangir, Çemişgezek 1363 2023/02/15
Cilligöl, Karlıova 1303 2023/02/05
Cintepe, Eruh 1587 2023/01/08
Cizre District 3291 2022/12/26
Cumhuriyet, Kahta 1261 2023/01/22
Cılga, Tunceli 1464 2023/02/16
Cınarik, Adıyaman 1422 2023/01/24
Dadaklı, Eruh 1573 2023/01/08
Dalbasan, Yayladere 1467 2023/02/04
Dalkorur, Eruh 1607 2023/01/08
Dallıağaç, Nusaybin 1602 2023/01/01
Dallıbahçe, Nazımiye 1618 2023/02/13
Dallıbel, Mazgirt 1665 2023/02/12
Dallıca, Kiğı 1406 2023/02/04
Dallıtepe, Bingöl 1315 2023/02/10
Daltepe, Şirvan 1131 2023/01/14
Dalören, Hozat 1485 2023/02/15
Damlabaşı, Güçlükonak 1400 2022/12/24
Damlaca, Silopi 1117 2022/12/20
Damlalı, Kızıltepe 1351 2023/01/06
Damlarca, Güçlükonak 1400 2022/12/24
Damlıca, Adıyaman 1199 2023/01/28
Damlı, Şirvan 1534 2023/01/12
Danaburan, Mazgirt 1544 2023/02/13
Danışman, Midyat 1318 2022/12/28
Dara, Artuklu 2216 2023/01/02
Dargeçit District 4442 2022/12/27
Darköprü, Kiğı 1381 2023/02/04
Dayılar, Mazgirt 1620 2023/02/12
Dazkaya, Mazgirt 1645 2023/02/13
Dağaltı, Beytüşşebap 1321 2022/12/20
Dağbek, Pülümür 1374 2023/02/15
Dağdibi, Uludere 1820 2022/12/19
Dağdüşü, Eruh 1334 2023/01/08
Dağiçi, Nusaybin 1468 2023/01/01
Dağkonak, Şırnak 1322 2022/12/22
Dağyeli, Güçlükonak 1417 2022/12/24
Dağyolu, Pülümür 1642 2023/02/15
Dedeağaç, Tunceli 1456 2023/02/16
Dedebakırı, Baykan 1344 2023/01/14
Dedebağı, Genç 1604 2023/02/11
Dedebeyli, Çemişgezek 1356 2023/02/15
Dedeler, Silopi 1085 2022/12/21
Dedeler, Yüksekova 3766 2022/12/17
Demet, Kızıltepe 1477 2023/01/06
Demirboğaz, Güçlükonak 1318 2022/12/24
Demirce, Nazımiye 1494 2023/02/13
Demirci, Kızıltepe 1353 2023/01/06
Demirci, Mazgirt 1622 2023/02/12
Demirdöş, Kiğı 1420 2023/02/04
Demiremek, Eruh 1474 2023/01/08
Demirkanat, Kiğı 1411 2023/02/04
Demirkapı, Kızıltepe 1612 2023/01/06
Demirkapı, Solhan 1388 2023/02/08
Demirkapı, Tunceli 1481 2023/02/16
Demirkapı, Şirvan 1139 2023/01/13
Demirkaya, Siirt 1677 2023/01/09
Demirkazık, Mazgirt 1646 2023/02/13
Demirkonak, Yüksekova 1417 2022/12/16
Demirkuyu, Kurtalan 1331 2023/01/15
Demirler, Kızıltepe 1625 2023/01/06
Demirli, Derik 1313 2023/01/07
Demirsaban, Pertek 1457 2023/02/14
Demirtaş, Hakkâri 2840 2022/12/18
Demirtepe, Nusaybin 1114 2023/01/02
Demirışık, Baykan 1138 2023/01/15
Denktaş, Derik 1101 2023/01/07
Dereboyu, Pülümür 1613 2023/02/15
Derecik District 4531 2022/12/21
Derecik, Mazıdağı 1340 2023/01/04
Dereköy, Genç 1232 2023/02/12
Dereköy, Pülümür 1525 2023/02/15
Dereli, Pertek 1799 2023/02/14
Dereova, Nazımiye 1486 2023/02/13
Dereyanı, Yeşilli 1320 2022/12/31
Dere, Pertek 1482 2023/02/14
Derik District 5952 2023/01/07
Derince, Baykan 1340 2023/01/15
Derince, Kurtalan 1138 2023/01/16
Derindere, Pülümür 1497 2023/02/15
Derinsu, Derik 1436 2023/01/07
Derinçay, Şirvan 1626 2023/01/12
Dervişcemal, Hozat 1392 2023/02/15
Değerli, Dargeçit 1317 2022/12/27
Değerli, Yüksekova 1576 2022/12/17
Değirmenköy, Erzincan 1396 2023/02/26
Dibekli, Yüksekova 1482 2022/12/17
Dibektaş, Artuklu 1313 2023/01/03
Dibek, Nusaybin 1928 2023/01/01
Dikboğaz, Eruh 1362 2023/01/08
Dikenli, Kahta 1329 2023/01/22
Dikenli, Tunceli 1495 2023/02/16
Dikköy, Bingöl 1306 2023/02/10
Dikmen, Derik 1372 2023/01/07
Dikme, Bingöl 1387 2023/02/10
Dikpınar, Genç 1468 2023/02/11
Dikyamaç, Mazıdağı 1303 2023/01/04
Dilekli, Yüksekova 2107 2022/12/16
Dilektaşı, Genç 1436 2023/02/11
Dilektaşı, Yüksekova 1706 2022/12/17
Dilektepe, Baykan 1130 2023/01/15
Dilektepe, Solhan 1403 2023/02/06
Dilek, Tunceli 1357 2023/02/16
Dinarbey, Yedisu 1404 2023/02/04
Direkli, Bingöl 1425 2023/02/10
Direkli, Genç 1588 2023/02/11
Dirim, Nusaybin 1343 2023/01/01
Dirsekli, Cizre 1685 2022/12/23
Dirsekli, İdil 1286 2022/12/26
Dişbudak, Bingöl 1276 2023/02/10
Dişlinar, Şirvan 1134 2023/01/13
Dokuzçavuş, Baykan 1136 2023/01/15
Doludere, Genç 1471 2023/02/12
Doludibek, Ovacık 1471 2023/02/13
Doludizgin, Tunceli 1626 2023/02/16
Doluharman, Siirt 1333 2023/01/09
Doluküp, Tunceli 1468 2023/02/16
Dolunay, Midyat 1310 2022/12/29
Dolusalkım, Pervari 1298 2023/01/11
Dolutekne, Adaklı 1303 2023/02/05
Doluçay, Adaklı 1411 2023/02/05
Doruklu, Silopi 1302 2022/12/20
Dorutay, Pertek 1446 2023/02/14
Doyuran, Kızıltepe 1351 2023/01/05
Doğanalan, Çemişgezek 1357 2023/02/15
Doğanca, Genç 1469 2023/02/11
Doğanca, Pervari 1743 2023/01/11
Doğancı, Derik 1305 2023/01/07
Doğanevler, Genç 1584 2023/02/12
Doğankaya, Adaklı 1403 2023/02/05
Doğanköy, Pervari 1528 2023/01/11
Doğanlı, Adıyaman 1513 2023/01/24
Doğanlı, Genç 1573 2023/02/11
Doğanlı, Kızıltepe 1357 2023/01/06
Doğanlı, Mazgirt 1526 2023/02/13
Doğanlı, Nusaybin 1350 2023/01/01
Doğanlı, Yüksekova 1273 2022/12/17
Doğanpınar, Pülümür 1471 2023/02/15
Doğantaş, Nazımiye 1461 2023/02/13
Doğanyazı, Midyat 1341 2022/12/29
Doğanyol, Beytüşşebap 1424 2022/12/20
Doğanyurt, Hakkâri 2748 2022/12/18
Doğan, Çemişgezek 1474 2023/02/15
Doğruca, Şirvan 1130 2023/01/13
Doğucak, Mazgirt 1622 2023/02/12
Doğuyeli, Solhan 1483 2023/02/08
Doğuş, Nusaybin 1591 2023/01/01
Dumanlı, Derik 1386 2023/01/07
Dumanlı, İdil 1281 2022/12/27
Dumluca, Derik 1403 2023/01/07
Durakbaşı, Nusaybin 1354 2023/01/01
Duraklı, Mazıdağı 1303 2023/01/04
Durankaya, Hakkâri 1404 2022/12/18
Durankaya, Şirvan 1245 2023/01/13
Duranlar, Kiğı 1279 2023/02/04
Dura, Kızıltepe 1345 2023/01/06
Duruca, Nusaybin 1374 2023/01/01
Duruköy, İdil 1373 2022/12/26
Durusu, Savur 1331 2023/01/03
Duygulu, Ömerli 1585 2022/12/31
Dönerdöver, Eruh 1355 2023/01/08
Dörtyol, Karlıova 1158 2023/02/06
Dörtyol, Kızıltepe 1354 2023/01/06
Döşekkaya, Genç 1583 2023/02/12
Dügernan, Bingöl 1326 2023/02/09
Düzağaç, Solhan 1383 2023/02/08
Düzce, Adıyaman 1190 2023/01/28
Düzce, Nusaybin 1592 2023/01/02
Düzgeçit, Midyat 1271 2022/12/30
Düzlük, Artuklu 1082 2023/01/03
Düzoba, Midyat 1483 2022/12/29
Düzova, Cizre 1275 2022/12/23
Düzpelit, Tunceli 1469 2023/02/16
Düztaş, Derik 1297 2023/01/07
Düzyayla, Bingöl 1302 2023/02/09
Düğüncüler, Pervari 1400 2023/01/11
Düğünyurdu, Güçlükonak 1343 2022/12/24
Düğürk, Kızıltepe 1357 2023/01/06
Efeağılı, Pülümür 1492 2023/02/15
Ekinciler, Mazıdağı 1304 2023/01/04
Ekinlik, Kızıltepe 1351 2023/01/05
Ekinlik, Sason 1616 2023/02/04
Ekinli, Kurtalan 1200 2023/01/17
Ekinyolu, Bingöl 1407 2023/02/10
Ekinyolu, Eruh 1440 2023/01/08
Ekmekçiler, Siirt 1686 2023/01/09
Elbaşı, Solhan 1378 2023/02/08
Elbeyli, Kızıltepe 1353 2023/01/05
Elgazi, Ovacık 1502 2023/02/13
Elmaağaç, Adaklı 1444 2023/02/05
Elmabahçe, Artuklu 1347 2023/01/02
Elmacık, Hakkâri 1986 2022/12/18
Elmadalı, Şirvan 1134 2023/01/14
Elmadüzü, Adaklı 1308 2023/02/05
Elmagünü, Genç 1427 2023/02/11
Elmakaşı, Pertek 1454 2023/02/14
Elmalı, Bingöl 1289 2023/02/10
Elmalı, Kızıltepe 1613 2023/01/05
Elmalı, Pülümür 1555 2023/02/15
Elmalı, Yedisu 1499 2023/02/04
Elmasırtı, Solhan 1508 2023/02/08
Emtağ, Bingöl 1444 2023/02/08
Enginköy, Mazıdağı 1304 2023/01/04
Engin, Baykan 1335 2023/01/15
Erbaşlar, Adaklı 1394 2023/02/05
Erdalı, Mazıdağı 1323 2023/01/04
Erdemli, Bingöl 1325 2023/02/09
Erdem, Cizre 1273 2022/12/23
Erdem, Kızıltepe 1344 2023/01/06
Erdoğdu, Tunceli 1480 2023/02/16
Erdurağı, Kurtalan 1269 2023/01/16
Erenkaya, Eruh 1358 2023/01/08
Erentepe, Bingöl 1301 2023/02/09
Ergan, Erzincan 1510 2023/02/26
Ericek, Genç 1580 2023/02/12
Erikli, Kızıltepe 1608 2023/01/05
Erişti, Midyat 1282 2022/12/29
Erkalkan, Çemişgezek 1469 2023/02/15
Erkent, Pervari 1111 2023/01/12
Erler, Adaklı 1389 2023/02/05
Eroğlu, Artuklu 1600 2023/01/02
Eroğlu, Kızıltepe 1129 2023/01/06
Eruh District 4341 2023/01/08
Eryeri, Artuklu 1352 2023/01/02
Esendere, Yüksekova 1693 2022/12/16
Esenli, Kızıltepe 1124 2023/01/06
Esenli, Silopi 1315 2022/12/21
Esentepe, Artuklu 1329 2023/01/02
Eskibalta, Yedisu 1401 2023/02/04
Eskibağ, Genç 1207 2023/02/12
Eskigedik, Ovacık 1519 2023/02/13
Eskihisar, Nusaybin 1410 2023/01/01
Eskikale, Artuklu 1392 2023/01/03
Eskikavak, Kiğı 1407 2023/02/04
Eskimağara, Nusaybin 1411 2023/01/01
Eskin, Kızıltepe 1625 2023/01/05
Eskitaş, Kahta 1606 2023/01/21
Eskiyol, Nusaybin 1343 2023/01/01
Evciler, Mazıdağı 1302 2023/01/05
Evkuran, Savur 1351 2023/01/04
Eymirli, Kızıltepe 1351 2023/01/05
Eğimli, Ovacık 1468 2023/02/13
Eğlence, Midyat 1932 2022/12/30
Eğlence, Siirt 1596 2023/01/09
Eğrikavak, Ovacık 1460 2023/02/14
Eğripınar, Ovacık 1436 2023/02/14
Eğriyamaç, Tunceli 1506 2023/02/16
Eşmetaş, Solhan 1415 2023/02/06
Eşme, Kiğı 1299 2023/02/04
Eşme, Kızıltepe 1353 2023/01/05
Fatih, Çelikhan 1134 2023/01/18
Fersaf, Tillo 1326 2023/01/12
Fındıktepe, Kızıltepe 1632 2023/01/05
Fındık, Güçlükonak 1511 2022/12/24
Fıstıklı, Ömerli 1354 2022/12/31
Garipuşağı, Ovacık 1478 2023/02/13
Garip, Bingöl 1170 2023/02/10
Gedikaşar, Eruh 1611 2023/01/08
Gedikler, Çemişgezek 1589 2023/02/15
Gedik, İdil 1254 2022/12/26
Gelenkardeş, Eruh 1687 2023/01/08
Gelincik, Mazgirt 1635 2023/02/12
Gelinpertek, Yedisu 1432 2023/02/04
Gelinpınar, Mazgirt 1635 2023/02/13
Gelintepe, Solhan 1383 2023/02/08
Gelişen, Derecik 2752 2022/12/15
Gençler, Sason 1552 2023/02/03
Gençtavuş, Solhan 1622 2023/02/06
Gercüş District 4595 2023/01/29
Geriş, Nazımiye 1528 2023/02/13
Gerçekli, Genç 1595 2023/02/12
Geyikdere, Genç 1524 2023/02/11
Geyiksuyu, Tunceli 1714 2023/02/16
Geçimli, Hakkâri 2323 2022/12/18
Geçimli, Hozat 1482 2023/02/15
Geçitboyu, Şırnak 1414 2022/12/21
Geçitköy, Gercüş 1411 2023/01/29
Geçitli, Hakkâri 2077 2022/12/17
Geçitli, Karlıova 1395 2023/02/05
Geçitveren, Mazgirt 1651 2023/02/12
Geçityaka, Pertek 1478 2023/02/14
Girmeli, Nusaybin 1882 2023/01/01
Göcenek, Pülümür 1519 2023/02/15
Gökbudak, Pervari 1295 2023/01/11
Gökdere, Bingöl 1297 2023/02/10
Gökdere, Tercan 1344 2023/02/19
Gökdoğan, Kurtalan 1229 2023/01/17
Göksu, Solhan 1377 2023/02/08
Göktaş, Derik 1411 2023/01/07
Göktepe, Mazgirt 1560 2023/02/13
Gökyurt, Yüksekova 1688 2022/12/17
Gökçebağ, Siirt 1115 2023/01/10
Gökçedal, Yayladere 1338 2023/02/04
Gökçekanat, Bingöl 1413 2023/02/10
Gökçekonak, Pülümür 1724 2023/02/15
Gökçekoru, Pervari 1386 2023/01/11
Gökçek, Tunceli 1363 2023/02/16
Gökçeli, Adaklı 1461 2023/02/05
Gökçeli, Bingöl 1366 2023/02/10
Gökçe, Artuklu 1303 2023/01/03
Gökçe, Beytüşşebap 1425 2022/12/20
Gölbaşı, Derik 1335 2023/01/07
Gölbaşı, Savur 1282 2023/01/04
Gölgelikonak, Eruh 1587 2023/01/08
Gölgeli, Pervari 1294 2023/01/11
Göllü, Artuklu 1913 2023/01/03
Göllü, Kızıltepe 1350 2023/01/06
Göllü, Ömerli 1331 2022/12/31
Göltepesi, Bingöl 1298 2023/02/10
Gömemiş, Tunceli 1512 2023/02/16
Gönülaldı, Eruh 1356 2023/01/08
Gönülaçan, Genç 1569 2023/02/12
Görendoruk, Eruh 1583 2023/01/08
Görentepe, Nusaybin 1351 2023/01/02
Görümlü, Silopi 1355 2022/12/20
Gövdeli, Pertek 1381 2023/02/14
Göynük, Karlıova 1325 2023/02/05
Gözeler, Bingöl 1399 2023/02/10
Gözeler, Ovacık 1484 2023/02/14
Gözen, Tunceli 1357 2023/02/16
Gözertepe, Genç 1474 2023/02/12
Gözer, Bingöl 1286 2023/02/10
Gözlüce, Kızıltepe 1357 2023/01/05
Gözlüce, Şirvan 1133 2023/01/14
Gözlüçayır, Çemişgezek 1505 2023/02/15
Gözpınar, Kurtalan 1334 2023/01/15
Göztepe, Adıyaman 1174 2023/01/28
Gözütok, Genç 1400 2023/02/11
Gülbahçe, Çemişgezek 1359 2023/02/15
Gülburnu, Eruh 1381 2023/01/08
Güldalı, Yüksekova 1096 2022/12/17
Güleçler, Pervari 1298 2023/01/11
Güleç, Mazgirt 1613 2023/02/12
Güleç, Tunceli 1361 2023/02/16
Güllüce, Yüksekova 1657 2022/12/16
Gülveren, Midyat 1313 2022/12/29
Gülyazı, Uludere 1131 2022/12/19
Gümüşdere, Kızıltepe 1621 2023/01/05
Gümüşgün, Mazgirt 1643 2023/02/12
Gümüşkaş, Baykan 1328 2023/01/14
Gümüşlü, Bingöl 1385 2023/02/10
Gümüşpınar, Mazıdağı 1313 2023/01/05
Gümüşyuva, Mazıdağı 1443 2023/01/05
Gümüş, Şirvan 1134 2023/01/13
Günboğazı, Pertek 1456 2023/02/14
Günbuldu, Baykan 1340 2023/01/14
Gündeş, Çukurca 3095 2022/12/17
Gündoğdu, Baykan 1343 2023/01/15
Günebakan, Nusaybin 1353 2023/01/01
Güneyağıl, Kiğı 1304 2023/02/04
Güneybaşı, Çemişgezek 1365 2023/02/15
Güneyce, Şırnak 1406 2022/12/22
Güneycik, Nazımiye 1419 2023/02/13
Güneykonak, Ovacık 1466 2023/02/14
Güneyli, Artuklu 1316 2023/01/02
Güneyyaka, Beytüşşebap 1891 2022/12/20
Güneyçam, Şırnak 1493 2022/12/22
Güneşlik, Yayladere 1424 2023/02/04
Güneşli, Hasankeyf 1322 2023/01/29
Güneştepe, Kızıltepe 1634 2023/01/05
Güngören, Bingöl 1382 2023/02/08
Güngören, Kızıltepe 1355 2023/01/06
Günkondu, Genç 1448 2023/02/11
Günlüce, Kızıltepe 1357 2023/01/05
Günlüce, Nazımiye 1460 2023/02/13
Günlük, Yayladere 1426 2023/02/04
Günyazı, Şemdinli 2057 2022/12/15
Günyurdu, Nusaybin 1936 2023/01/01
Günyüzü, Beytüşşebap 1317 2022/12/20
Gürağaç, Artuklu 1315 2023/01/02
Gürbüzler, Tunceli 1462 2023/02/16
Gürdere, Yüksekova 1380 2022/12/17
Gürgen, Dargeçit 1317 2022/12/28
Gürgöze, Kurtalan 1226 2023/01/17
Gürgöze, Mazıdağı 1309 2023/01/04
Gürkavak, Yüksekova 1863 2022/12/16
Gürmeşe, Kızıltepe 1356 2023/01/06
Gürpınar, Bingöl 1389 2023/02/09
Gürsü, Cizre 1291 2022/12/23
Gürün, Nusaybin 1339 2023/01/01
Gürışık, Dargeçit 1331 2022/12/28
Güvenli, Nusaybin 1348 2023/01/01
Güveçli, Bingöl 1517 2023/02/10
Güzelağaç, Ömerli 1344 2022/12/31
Güzeldere, Genç 1615 2023/02/12
Güzeldere, Kurtalan 1438 2023/01/15
Güzelova, İdil 1391 2022/12/27
Güzelpınar, Nazımiye 1462 2023/02/13
Güzgülü, Yedisu 1793 2023/02/04
Güçlükonak District 3346 2022/12/25
Güçlü, Cizre 1403 2022/12/23
Güçlü, Kızıltepe 1607 2023/01/05
Güçlü, Yüksekova 1941 2022/12/17
Haberli, İdil 2316 2022/12/27
Haceri, Tunceli 1508 2023/02/16
Hacıhasan, Kızıltepe 1367 2023/01/06
Hacılar, Karlıova 1493 2023/02/05
Hacılı, Pülümür 1377 2023/02/15
Hacıyusuf, Kızıltepe 1132 2023/01/06
Hakkâri District 4178 2022/12/22
Hakverdi, Kızıltepe 1355 2023/01/06
Halifan, Karlıova 1346 2023/02/05
Halitpınar, Ovacık 1456 2023/02/13
Halkalı, Kızıltepe 1609 2023/01/05
Hamzalar, Kahta 1429 2023/01/21
Hanlar, Midyat 1310 2022/12/29
Hanuşağı, Ovacık 1457 2023/02/13
Harmancık, Genç 1566 2023/02/12
Harmandüzü, Kızıltepe 1361 2023/01/05
Harmankaya, Ömerli 1349 2022/12/31
Harmanlı, Midyat 1314 2022/12/29
Harmantepe, Karlıova 1399 2023/02/05
Harmantepe, Savur 1325 2023/01/04
Hasandiğin, Kahta 1405 2023/01/22
Hasangazi, Pülümür 1488 2023/02/15
Hasankeyf District 3692 2023/01/29
Hasanova, Karlıova 1458 2023/02/05
Hasantepe, Nusaybin 1352 2023/01/01
Hasbağlar, Adaklı 1416 2023/02/04
Hatrant, Tillo 1407 2023/01/12
Hatunlu, Artuklu 1283 2023/01/03
Havuzbaşı, Ömerli 1337 2022/12/31
Havuzlu, Cizre 1273 2022/12/22
Havuzlu, Ovacık 1466 2023/02/14
Haydar, Artuklu 1086 2023/01/03
Hayırlı, Derik 1103 2023/01/07
Hazarşah, Solhan 1415 2023/02/06
Haziran, Bingöl 1399 2023/02/10
Haznedar, Kızıltepe 1354 2023/01/05
Hendekköy, İdil 1329 2022/12/26
Heybeli, Nusaybin 1348 2023/01/01
Hilal, Uludere 1356 2022/12/19
Hisaraltı, Derik 1396 2023/01/07
Hisarkaya, Savur 1606 2023/01/04
Hocaköy, Kızıltepe 1360 2023/01/06
Hozat District 2345 2023/02/14
Hürmüz, Şirvan 1324 2023/01/12
Hüyüklü, Artuklu 1577 2023/01/03
Ilkadım, Nusaybin 1350 2023/01/01
Ilıcak, Adıyaman 1779 2023/01/25
Ilıcak, Beytüşşebap 1310 2022/12/20
Ilıcak, Kızıltepe 1609 2023/01/05
Ilıca, Derik 1383 2023/01/07
Ilıpınar, Karlıova 1320 2023/02/05
Ilısu, Dargeçit 1318 2022/12/27
Issız, Derik 1096 2023/01/07
Isıtma, Ovacık 1356 2023/02/14
Işıkdere, Ömerli 1335 2022/12/31
Işıklar, Hakkâri 2502 2022/12/18
Işıklar, Kızıltepe 1615 2023/01/05
Işıklı, Adıyaman 1210 2023/01/28
Işıktepe, Kahta 1281 2023/01/22
Işıkveren, Uludere 1232 2022/12/19
Işıkvuran, Ovacık 1453 2023/02/13
Işıkyaka, Mazıdağı 1305 2023/01/04
Işık, Hakkâri 2344 2022/12/18
Işık, İdil 1275 2022/12/27
Işıkören, Kızıltepe 1358 2023/01/05
Kabadal, Pülümür 1486 2023/02/15
Kabala, Artuklu 1744 2023/01/02
Kabayel, Yedisu 1645 2023/02/04
Kabaçalı, Adaklı 1392 2023/02/05
Kacarlar, Pertek 1474 2023/02/14
Kadıköy, Kiğı 1297 2023/02/04
Kadıköy, Yüksekova 1771 2022/12/17
Kahraman, Kızıltepe 1414 2023/01/06
Kahveci, Kozluk 1376 2023/02/02
Kalaycık, Kızıltepe 1358 2023/01/06
Kalaycı, Mazgirt 1341 2023/02/13
Kalburcu, Adıyaman 1171 2023/01/28
Kalecik, Hozat 1492 2023/02/15
Kalecik, Nusaybin 1392 2023/01/01
Kaleköy, Mazgirt 1521 2023/02/12
Kaleköy, Solhan 1372 2023/02/06
Kalencik, Karlıova 1425 2023/02/05
Kalender, Siirt 1656 2023/01/09
Kalkancık, Şirvan 1136 2023/01/14
Kalkanlı, Yayladere 1494 2023/02/04
Kamışgölü, Adaklı 1292 2023/02/05
Kamışlı, Hakkâri 1750 2022/12/17
Kamışlı, Yüksekova 1493 2022/12/17
Kanatlı, Derik 1099 2023/01/07
Kangallı, Pülümür 1505 2023/02/16
Kanoğlu, Tunceli 1361 2023/02/16
Kantarkaya, Karlıova 1428 2023/02/05
Kantar, Nusaybin 1590 2023/01/02
Kapıbaşı, Nazımiye 1481 2023/02/13
Kapıkaya, Kurtalan 1142 2023/01/17
Kapılı, Silopi 1415 2022/12/21
Kapılı, Şirvan 1133 2023/01/13
Karaalanı, Mazıdağı 1310 2023/01/04
Karabakır, Hozat 1491 2023/02/15
Karabalçık, Karlıova 1378 2023/02/06
Karabayır, Dargeçit 1328 2022/12/27
Karabağ, Kurtalan 1137 2023/01/16
Karabent, Kızıltepe 1128 2023/01/06
Karabey, Yüksekova 1093 2022/12/17
Karaburun, Derik 1380 2023/01/07
Karacaköy, Hozat 1467 2023/02/15
Karacaköy, Nusaybin 1359 2023/01/01
Karaca, Şirvan 1212 2023/01/13
Karadayılar, Eruh 1108 2023/01/09
Karademir, Artuklu 1540 2023/01/03
Karagöz, Pülümür 1472 2023/02/16
Karagüney, Pertek 1489 2023/02/14
Karakaya, Baykan 1401 2023/01/14
Karakulak, Kızıltepe 1358 2023/01/06
Karakuyu, Kızıltepe 1610 2023/01/05
Karaköy, Savur 1339 2023/01/04
Karalar, İdil 1343 2022/12/24
Karaman, Kahta 1234 2023/01/22
Karaman, Kızıltepe 1304 2023/01/05
Karaoğlan, Ovacık 1467 2023/02/13
Karapolat, Yedisu 1408 2023/02/04
Karasar, Çemişgezek 1323 2023/02/15
Karasungur, Pervari 1117 2023/01/12
Karataş, Derik 1389 2023/01/07
Karataş, Kahta 1309 2023/01/22
Karataş, Mazıdağı 1429 2023/01/05
Karataş, Ovacık 1472 2023/02/14
Karatepe, Beşiri 1061 2023/01/31
Karayonca, Ovacık 1364 2023/02/14
Karayusuf, Mazgirt 1444 2023/02/12
Karayün, Sason 1620 2023/02/03
Karaçavuş, Hozat 1531 2023/02/15
Karaçubuk, Adaklı 1422 2023/02/05
Karcı, Genç 1557 2023/02/12
Kardelen, Hozat 1471 2023/02/15
Kardeşler, Bingöl 1133 2023/02/11
Kargapazarı, Karlıova 1339 2023/02/05
Kargın, Tercan 1934 2023/02/19
Karlıca, Karlıova 1315 2023/02/05
Karlıova District 4783 2023/02/05
Karlı, Yüksekova 1848 2022/12/16
Karsan, Mazgirt 1612 2023/02/12
Kartalkaya, Dargeçit 1325 2022/12/27
Kartal, Bingöl 1307 2023/02/10
Kartutan, Mazgirt 1523 2023/02/12
Karşıkaya, Pervari 1119 2023/01/12
Karşıkonak, Mazgirt 1655 2023/02/12
Karşılar, Tunceli 1484 2023/02/16
Kasrik, Şırnak 1336 2022/12/21
Kasımlı, Baykan 1508 2023/01/14
Kasımlı, Şirvan 1583 2023/01/12
Katarlı, Kızıltepe 1354 2023/01/06
Katran, Cizre 1388 2022/12/23
Kavakgölü, Eruh 1678 2023/01/08
Kavaklı, Genç 1569 2023/02/12
Kavaklı, Hakkâri 2382 2022/12/17
Kavaktepe, Mazgirt 1532 2023/02/13
Kavaközü, Siirt 1593 2023/01/09
Kavaközü, Silopi 1315 2022/12/21
Kavalköy, Hakkâri 2136 2022/12/18
Kavallı, Silopi 1297 2022/12/20
Kavuktepe, Hozat 1483 2023/02/15
Kavuncu, Şırnak 1317 2022/12/22
Kayabalı, Ömerli 1382 2022/12/31
Kayabağlar, Kurtalan 1160 2023/01/16
Kayabağ, Pertek 1459 2023/02/14
Kayabaşı, Midyat 1585 2022/12/29
Kayaboyun, Şırnak 1411 2022/12/22
Kayaboğaz, Siirt 1681 2023/01/09
Kayacıklar, Savur 1324 2023/01/04
Kayacık, Derik 1298 2023/01/07
Kayacı, Mazgirt 1684 2023/02/13
Kayadere, Ömerli 1612 2022/12/31
Kayadibi, Adıyaman 1181 2023/01/28
Kayadibi, Nusaybin 1340 2023/01/01
Kayagöze, Ömerli 1342 2022/12/31
Kayahisar, Şirvan 1253 2023/01/14
Kayaköy, Cizre 1289 2022/12/23
Kayalar, Midyat 1498 2022/12/29
Kayalar, Şemdinli 2416 2022/12/15
Kayalık, Çukurca 1976 2022/12/17
Kayalıpınar, Midyat 1321 2022/12/29
Kayalısu, Kurtalan 1473 2023/01/15
Kayalı, Adıyaman 1178 2023/01/28
Kayapınar, Kızıltepe 1369 2023/01/06
Kayatepe, Savur 1278 2023/01/03
Kayaüstü, Ömerli 1317 2022/12/31
Kaymaklı, Hakkâri 2099 2022/12/18
Kaymaztepe, Pülümür 1477 2023/02/15
Kaynakdüzü, Adaklı 1485 2023/02/05
Kaynakkaya, Ömerli 1337 2022/12/31
Kaynak, Karlıova 1413 2023/02/05
Kaynarca, Kızıltepe 1351 2023/01/06
Kaynarpınar, Karlıova 1331 2023/02/05
Kayıklı, Hasankeyf 1323 2023/01/29
Kayırlar, Pülümür 1678 2023/02/15
Kayı, İdil 1318 2022/12/26
Kazanlı, Karlıova 1311 2023/02/05
Kazan, Yüksekova 1086 2022/12/17
Kazan, Çukurca 1726 2022/12/17
Kazılı, Pertek 1358 2023/02/14
Kaşıklı, Kızıltepe 1361 2023/01/06
Kaşıklı, Yedisu 1449 2023/02/04
Kaşıkyayla, Eruh 1111 2023/01/09
Kaşıkçı, Karlıova 1322 2023/02/05
Kaşıkçı, İdil 1408 2022/12/27
Kebapçı, Mazıdağı 1305 2023/01/04
Kebeli, Cizre 1272 2022/12/23
Keklikdere, Genç 1656 2023/02/11
Kekliktepe, Eruh 1592 2023/01/08
Kelekçi, Hasankeyf 1321 2023/01/29
Kemerli, Mazıdağı 1302 2023/01/04
Kemerli, Siirt 1676 2023/01/09
Kengerli, Kızıltepe 1351 2023/01/05
Kentli, İdil 1358 2022/12/27
Kepçeli, Genç 1478 2023/02/11
Keruh, Cizre 1281 2022/12/22
Keskin, Pervari 1109 2023/01/12
Kesmetaş, Şirvan 1134 2023/01/14
Keçili, Yüksekova 1329 2022/12/17
Kilimli, Kızıltepe 1350 2023/01/06
Kilis, Sason 1051 2023/02/04
Kirazlı, Şirvan 1328 2023/01/12
Kiğı District 2975 2023/02/04
Kocadağ, Nusaybin 1420 2023/01/01
Kocahüyük, Savur 1606 2023/01/04
Kocakent, Mazıdağı 1304 2023/01/04
Kocakoç, Tunceli 1584 2023/02/16
Kocakuyu, Ömerli 1335 2022/12/31
Kocalar, Kızıltepe 1444 2023/01/05
Kocalar, Tunceli 1365 2023/02/16
Kocapınar, Cizre 1299 2022/12/23
Kocasırt, Ömerli 1338 2022/12/31
Kocatepe, Derik 1101 2023/01/07
Kocatepe, Pülümür 1465 2023/02/16
Kocaçavuş, Pervari 1296 2023/01/11
Kolankaya, Pertek 1507 2023/02/14
Kolbaşı, Yüksekova 1456 2022/12/17
Konacık, Siirt 1210 2023/01/10
Konakbaşı, Erzincan 1431 2023/02/26
Konaklar, Ovacık 1367 2023/02/14
Konaklar, Pertek 1469 2023/02/14
Konaklı, Artuklu 1319 2023/01/02
Konakpınar, Kurtalan 1424 2023/01/15
Konak, Derik 1440 2023/01/07
Konuklu, Kızıltepe 1605 2023/01/06
Konuk, Derik 1379 2023/01/07
Konurat, Pertek 1459 2023/02/14
Konur, Mazıdağı 1346 2023/01/04
Konur, Şemdinli 2236 2022/12/15
Kopuzlar, Tunceli 1474 2023/02/16
Korgan, Şemdinli 2476 2022/12/16
Korluca, Pertek 1382 2023/02/14
Korlu, Yayladere 1505 2023/02/04
Korucu, Cizre 1382 2022/12/23
Korucu, Dargeçit 1318 2022/12/28
Koruköy, Hozat 1481 2023/02/15
Kovalı, Derik 1101 2023/01/07
Kovanlı, Derik 1381 2023/01/07
Kovanlı, Ömerli 1335 2022/12/31
Kovuklu, Pülümür 1476 2023/02/16
Koyunlu, Yeşilli 1317 2022/12/31
Koyunoba, Beytüşşebap 1321 2022/12/20
Koyunuşağı, Mazgirt 1648 2023/02/12
Kozluca, Hozat 1718 2023/02/15
Kozluca, Ovacık 1528 2023/02/13
Kozluca, İdil 1424 2022/12/26
Kozluk District 4966 2023/02/01
Kozlu, Adaklı 1404 2023/02/05
Koçbeyi, Şırnak 1446 2022/12/22
Koçkuyusu, Mazgirt 1621 2023/02/13
Koçlu, Kızıltepe 1831 2023/01/06
Koçlu, Siirt 1585 2023/01/09
Koçpınar, Pertek 1475 2023/02/14
Koçsırtı, Genç 1453 2023/02/11
Koçtepe, Cizre 1293 2022/12/23
Koçtepe, Güçlükonak 1416 2022/12/24
Koçyiğit, Derik 1301 2023/01/07
Koşuyolu, Savur 1295 2023/01/03
Kulaksız, Sason 1060 2023/02/04
Kumdere, Dargeçit 1321 2022/12/28
Kumgeçit, Bingöl 1313 2023/02/10
Kumlu, Artuklu 1369 2023/01/03
Kumçatı, Şırnak 1344 2022/12/22
Kurtalan District 3758 2023/01/15
Kurtuluş, Bingöl 1396 2023/02/11
Kurtuluş, Cizre 1277 2022/12/23
Kurtuluş, İdil 1466 2022/12/26
Kuruca, Bingöl 1479 2023/02/10
Kurudere, Bingöl 1244 2023/02/11
Kurukaymak, Hozat 1564 2023/02/15
Kuruköy, Nusaybin 1600 2023/01/01
Kuruçay, Derik 1102 2023/01/07
Kutlubey, Midyat 1307 2022/12/29
Kutluca, Derik 1104 2023/01/07
Kutluca, Kiğı 1293 2023/02/04
Kuyluca, Tunceli 1479 2023/02/16
Kuyular, Nusaybin 1349 2023/01/01
Kuyulu, Adıyaman 1614 2023/01/25
Kuyulu, Artuklu 1281 2023/01/03
Kuyulu, Derik 1273 2023/01/07
Kuyulu, İdil 1384 2022/12/26
Kuzulca, Pülümür 1553 2023/02/15
Kuşaklı, Mazgirt 1613 2023/02/12
Kuşburnu, Bingöl 1107 2023/02/11
Kuşdalı, Eruh 1496 2023/01/08
Kuşhane, Mazgirt 1614 2023/02/12
Kuşkondu, Bingöl 1386 2023/02/08
Kuşluca, Dargeçit 1318 2022/12/28
Kuşluca, Ovacık 1473 2023/02/13
Kuştepe, Adıyaman 1425 2023/01/23
Kuştepe, Cizre 1274 2022/12/23
Kuşçimeni, Kiğı 1415 2023/02/04
Kuşçu, Derik 1101 2023/01/07
Köklüce, Tunceli 1648 2023/02/16
Köklü, Bingöl 1123 2023/02/11
Kömürlü, Ömerli 1339 2022/12/31
Kömürlü, Şirvan 1232 2023/01/13
Köprübaşı, Kızıltepe 1365 2023/01/06
Köprübaşı, Siirt 1208 2023/01/10
Köprücek, Yüksekova 1373 2022/12/17
Köprülü, Savur 1311 2023/01/03
Köprüçay, Pervari 1099 2023/01/12
Körsu, Kızıltepe 1348 2023/01/06
Körüklükaya, Şırnak 1122 2022/12/22
Köseler, Ovacık 1550 2023/02/14
Köseveli, Derik 1105 2023/01/07
Kösreli, Silopi 1457 2022/12/21
Kösüklü, Gölbaşı 1493 2023/01/22
Köyceğiz, İdil 1285 2022/12/26
Közlüce, Pülümür 1376 2023/02/15
Köşkönü, Yüksekova 1793 2022/12/16
Külafhüyük, Adıyaman 1526 2023/01/24
Kümbet, Karlıova 1309 2023/02/05
Küplüce, Kızıltepe 1355 2023/01/06
Kürük, Karlıova 1427 2023/02/05
Kütüklü, Yeşilli 1311 2022/12/31
Küçükayrık, Kızıltepe 1375 2023/01/06
Küçükboğaziye, Kızıltepe 1401 2023/01/06
Küçükhasancık, Adıyaman 1195 2023/01/28
Küçükkardeş, Nusaybin 1368 2023/01/01
Küçükköy, Artuklu 1576 2023/01/03
Küçüktekören, Bingöl 1404 2023/02/09
Kılavuz, Dargeçit 1373 2022/12/27
Kılduman, Kızıltepe 1358 2023/01/06
Kılköy, Nazımiye 1467 2023/02/13
Kılçadır, Bingöl 1395 2023/02/09
Kılıçkaya, Eruh 1598 2023/01/08
Kılıçlı, Kurtalan 1250 2023/01/16
Kılıç, Batman 1266 2023/01/29
Kıran, Bingöl 1202 2023/02/11
Kıraçlar, Çemişgezek 1479 2023/02/15
Kıraçtepe, Karlıova 1316 2023/02/05
Kırbalı, Savur 1576 2023/01/04
Kırca, İdil 1321 2022/12/26
Kırdım, Pülümür 1637 2023/02/15
Kırkdirek, Savur 1355 2023/01/04
Kırkkuyu, Kızıltepe 1359 2023/01/06
Kırkkuyu, Şırnak 1428 2022/12/22
Kırklar, Pülümür 1570 2023/02/15
Kırkmeşe, Pülümür 1464 2023/02/15
Kırkpınar, Adaklı 1307 2023/02/05
Kırköy, Yayladere 1510 2023/02/04
Kırıkdağ, Hakkâri 2399 2022/12/17
Kırık, Solhan 1499 2023/02/08
Kısmetli, Dargeçit 1330 2022/12/27
Kısıklı, Yüksekova 1767 2022/12/16
Kızık, Ovacık 1447 2023/02/13
Kızılağaç, Karlıova 1259 2023/02/06
Kızılcık, Mazgirt 1552 2023/02/13
Kızılkale, Mazgirt 1655 2023/02/13
Kızılmescit, Pülümür 1567 2023/02/15
Kızılsu, Şırnak 1428 2022/12/22
Kızıltepe District 12413 2023/01/05
Kızılçubuk, Karlıova 1329 2023/02/05
Kışlacık, Pervari 1166 2023/01/12
Kışlacık, Siirt 1289 2023/01/09
Kışlak, Mazıdağı 1364 2023/01/04
Lokman, Adıyaman 1503 2023/01/24
Madenköy, Şirvan 1329 2023/01/12
Mahmutlu, Silopi 1156 2022/12/20
Malpınarı, Adıyaman 1200 2023/01/28
Mazıdağı District 4996 2023/01/04
Mercan, Adaklı 1478 2023/02/05
Mercan, Tercan 1230 2023/02/23
Mercimekli, Midyat 1624 2022/12/30
Mercimek, Pertek 1428 2023/02/14
Meydandere, Siirt 1366 2023/01/09
Mezraa, Beytüşşebap 1324 2022/12/20
Mezraa, Pülümür 1645 2023/02/15
Meşecik, Şirvan 1130 2023/01/13
Meşedalı, Genç 1604 2023/02/12
Meşelidere, Siirt 1593 2023/01/09
Meşelik, Baykan 1403 2023/01/14
Meşelik, Şemdinli 1704 2023/02/12
Meşeli, Derik 1395 2023/01/07
Meşeli, Mazıdağı 1302 2023/01/05
Meşeyolu, Tunceli 1480 2023/02/16
Midyat District 5073 2022/12/28
Mollaaliler, Ovacık 1490 2023/02/14
Mollaibrahim, Genç 1574 2023/02/12
Mollaşakir, Karlıova 1396 2023/02/05
Muratköy, Solhan 1387 2023/02/06
Mutluca, Beytüşşebap 1247 2022/12/20
Mutluca, Solhan 1417 2023/02/06
Mutluca, Ömerli 1337 2022/12/31
Nacaklı, Kiğı 1437 2023/02/04
Nallıkaya, Şirvan 1248 2023/01/14
Narlıdere, Kahta 1337 2023/01/22
Narlıyurt, Baykan 1463 2023/01/14
Narlı, Midyat 1387 2022/12/29
Narlı, Çukurca 1991 2022/12/17
Narsuyu, Pervari 1110 2023/01/12
Nazımiye District 2340 2023/02/13
Nergizli, Nusaybin 1597 2023/01/02
Nohutlu, Pülümür 1375 2023/02/15
Nur (Akıncı), Artuklu 1530 2023/01/03
Nusaybin District 5994 2022/12/31
Obalı, Baykan 1568 2023/01/14
Obrukkaşı, Mazgirt 1512 2023/02/13
Obuzbaşı, Mazgirt 1641 2023/02/13
Ocaklı, İdil 1374 2022/12/26
Odabaşı, Nusaybin 2402 2023/01/01
Odaköy, Kızıltepe 1348 2023/01/06
Ofis, Kızıltepe 1095 2023/01/06
Okurlar, Tunceli 1363 2023/02/16
Okçular, Eruh 1104 2023/01/09
Okçu, İdil 1274 2022/12/26
Olgunlar, Hakkâri 1987 2022/12/18
Olukpınar, Bingöl 1334 2023/02/09
Onbaşılar, Yüksekova 1964 2022/12/17
Ormanardı, Bingöl 1130 2023/02/11
Ormanardı, Siirt 1358 2023/01/09
Ormanbağı, Şirvan 1224 2023/01/13
Ormandalı, Pervari 1317 2023/01/11
Ormaniçi, Güçlükonak 1308 2022/12/24
Ormanlı, Şirvan 1221 2023/01/14
Ormanpınar, Baykan 1137 2023/01/15
Ortabağ, Uludere 1351 2022/12/19
Ortaca, Derik 1097 2023/01/07
Ortaca, Midyat 1388 2022/12/30
Ortaca, İdil 1316 2022/12/30
Ortadurak, Mazgirt 1642 2023/02/12
Ortaharman, Mazgirt 1620 2023/02/12
Ortaklar, Derecik 2277 2022/12/15
Ortaklı, Eruh 1681 2023/01/08
Ortaklı, Mazıdağı 1308 2023/01/04
Ortaköy, Artuklu 1310 2023/01/03
Ortaköy, Bingöl 1303 2023/02/09
Ortaköy, Karlıova 1319 2023/02/05
Ortaköy, Kızıltepe 1648 2023/01/06
Ortaköy, Silopi 1312 2022/12/21
Ortaköy, İdil 1289 2022/12/26
Ortalı, Beytüşşebap 1316 2022/12/20
Ortasu, Uludere 1601 2022/12/19
Ortaçanak, Bingöl 1314 2023/02/10
Ortaç, Yüksekova 1834 2022/12/17
Otlubahçe, Ovacık 1469 2023/02/13
Otluca, Hakkâri 2147 2022/12/17
Otlukaya, Mazgirt 1613 2023/02/12
Otlukbeli District 1843 2023/02/25
Otluk, Kızıltepe 1347 2023/01/06
Otluk, Şirvan 1212 2023/01/13
Ovabaşı, Ömerli 1335 2022/12/31
Ovaköy, Silopi 1372 2022/12/21
Ovaköy, Yeşilli 1328 2022/12/31
Oyalı, İdil 1331 2022/12/26
Oya, Şirvan 1123 2023/01/14
Oymadal, Mazgirt 1650 2023/02/12
Oymakaya, Beytüşşebap 1466 2022/12/20
Oymak, İdil 1368 2022/12/26
Oymakılıç, Eruh 1584 2023/01/08
Oymapınar, Solhan 1467 2023/02/06
Oğuldere, Bingöl 1413 2023/02/10
Oğul, Hakkâri 2923 2022/12/17
Palamutlu, Pervari 1464 2023/01/11
Palamut, Hasankeyf 1677 2023/01/29
Payamlı, Eruh 1676 2023/01/08
Paşacık, Çemişgezek 1477 2023/02/15
Paşadüzü, Ovacık 1372 2023/02/14
Pelitli, Midyat 1533 2022/12/30
Pertek District 3191 2023/02/14
Pervari District 2998 2023/01/11
Peçenek, İdil 1321 2022/12/26
Pirinçli, Beytüşşebap 1456 2022/12/20
Pirinçli, Derik 1319 2023/01/07
Pirinçli, Şirvan 1530 2023/01/13
Pirinççi, Pertek 1452 2023/02/14
Pülümür District 3310 2023/02/15
Pınaraltı, Genç 1407 2023/02/11
Pınarbaşı, İdil 1354 2022/12/26
Pınarca, Hakkâri 1885 2022/12/18
Pınarca, Siirt 1211 2023/01/10
Pınarcık, Derik 1387 2023/01/07
Pınarcık, Ömerli 1344 2022/12/31
Pınardere, Savur 1311 2023/01/03
Pınargözü, Yüksekova 1793 2022/12/16
Pınarlar, Pertek 1481 2023/02/14
Pınarova, Siirt 1109 2023/01/10
Pınar, Tunceli 1454 2023/02/16
Pınarönü, Silopi 1400 2022/12/21
Ramazanköy, Nazımiye 1547 2023/02/13
Rıhani, Kızıltepe 1378 2023/01/05
Sabırtaşı, Kiğı 1406 2023/02/04
Saipbeyli, Kurtalan 1253 2023/01/17
Sakalar, Artuklu 1331 2023/01/03
Sakaören, Karlıova 1306 2023/02/05
Sakyol, Çemişgezek 1499 2023/02/15
Sakızlı, Mazıdağı 1433 2023/01/05
Salihköy, Ömerli 1546 2022/12/31
Salkımbağlar, Eruh 1351 2023/01/08
Salkımlı, Yüksekova 1785 2022/12/17
Salkımözü, Pülümür 1486 2023/02/15
Sancaklı, Bingöl 1478 2023/02/10
Sancaklı, Savur 1357 2023/01/04
Sancarlı, Kızıltepe 1352 2023/01/05
Sancar, Yeşilli 1310 2022/12/31
Sandıklı, Kızıltepe 1613 2023/01/05
Sapköy, Nazımiye 1493 2023/02/13
Saray, Nizip 1043 2023/02/18
Sarmakaya, Genç 1440 2023/02/11
Saruhan, Kızıltepe 1605 2023/01/05
Sarıbudak, Genç 1564 2023/02/12
Sarıca, Kızıltepe 1357 2023/01/06
Sarıdam, Pervari 1289 2023/01/11
Sarıdana, Baykan 1364 2023/01/14
Sarıdana, Şirvan 1134 2023/01/13
Sarıdibek, Adaklı 1447 2023/02/05
Sarıgül, Pülümür 1377 2023/02/16
Sarıkaya, Midyat 1282 2022/12/30
Sarıkoç, Mazgirt 1639 2023/02/12
Sarıkuşak, Karlıova 1319 2023/02/05
Sarıköy, Midyat 1785 2022/12/30
Sarıköy, İdil 2311 2022/12/27
Sarısalkım, Baykan 1323 2023/01/14
Sarısaltık, Hozat 1548 2023/02/15
Sarısaman, Genç 1464 2023/02/11
Sarıtaş, Hakkâri 1955 2022/12/18
Sarıtaş, Tunceli 1465 2023/02/16
Sarıtaş, Yüksekova 1697 2022/12/17
Sarıtepe, Siirt 1221 2023/01/10
Sarıtosun, Ovacık 1472 2023/02/14
Sarıyaprak, Pervari 1209 2023/01/12
Sarıyayla, Nazımiye 1574 2023/02/13
Sarıçiçek, Bingöl 1531 2023/02/10
Savaşköy, Eruh 1440 2023/01/08
Savur District 3946 2023/01/03
Sağgöze, Genç 1472 2023/02/11
Sağkol, Güçlükonak 1320 2022/12/24
Sağlamtaş, Pülümür 1383 2023/02/16
Sağlarca, Siirt 1591 2023/01/09
Sağmal, Mazıdağı 1408 2023/01/04
Sağırsu, Siirt 1592 2023/01/09
Selçik, Silopi 1087 2022/12/20
Senek, Pülümür 1473 2023/02/15
Serenli, Savur 1338 2023/01/03
Serhatlı, Adıyaman 1303 2023/01/28
Serindere, Yüksekova 1750 2022/12/17
Serpmekaya, Karlıova 1431 2023/02/05
Servi, Genç 1473 2023/02/12
Sevimli, Kızıltepe 1604 2023/01/05
Sevkar, Adaklı 1434 2023/02/05
Siirt District 3246 2023/01/09
Silopi District 3526 2022/12/25
Sinan, Tunceli 1442 2023/02/16
Sinep, Tillo 1323 2023/01/12
Sivrice, Midyat 1310 2022/12/29
Sivritepe, Ömerli 1340 2022/12/31
Solhan District 2841 2023/02/06
Soylu, Savur 1332 2023/01/04
Soğanlı, Kızıltepe 1355 2023/01/05
Soğanlı, Şirvan 1135 2023/01/13
Soğukkuyu, Derik 1106 2023/01/07
Soğukpınar, Genç 1236 2023/02/12
Soğukpınar, Karlıova 1417 2023/02/05
Soğuksu, Şirvan 1230 2023/01/14
Subaşı, Derik 1383 2023/01/07
Sudurağı, Karlıova 1328 2023/02/05
Sudüğünü, Bingöl 1559 2023/02/08
Sulakdere, Ömerli 1335 2022/12/31
Sulak, Artuklu 1309 2023/01/02
Sulak, Cizre 1280 2022/12/23
Sulak, İdil 1401 2022/12/26
Sultanköy, Artuklu 1355 2023/01/02
Suludere, Şirvan 1137 2023/01/14
Suluyazı, Şirvan 1238 2023/01/14
Sumak, Pertek 1369 2023/02/14
Suvaran, Bingöl 1124 2023/02/11
Suvat, Tunceli 1485 2023/02/16
Suçatı, Dargeçit 1323 2022/12/27
Suçatı, Karlıova 1291 2023/02/05
Suüstü, Yüksekova 1373 2022/12/17
Sökücek, Mazgirt 1629 2023/02/13
Söğütce, Beytüşşebap 1404 2022/12/20
Söğütlütepe, Pertek 1378 2023/02/14
Söğütlü, Midyat 2008 2022/12/29
Söğütlü, Nusaybin 1119 2023/01/02
Söğütlü, Ovacık 1368 2023/02/14
Söğütönü, Pervari 1126 2023/01/12
Söğütözü, Derik 1113 2023/01/07
Sükyan, Solhan 1510 2023/02/08
Süleymanuşağı, Pülümür 1583 2023/02/15
Sülünkaş, Solhan 1436 2023/02/06
Sürekli, Genç 1291 2023/02/11
Sürekli, Kızıltepe 1386 2023/01/06
Sürekli, Yüksekova 1852 2022/12/16
Sürgücü, Savur 1342 2023/01/03
Sürgüç, Pertek 1362 2023/02/14
Sürmelikoç, Yayladere 1446 2023/02/04
Sütgölü, Bingöl 1375 2023/02/11
Sütlüce, Adaklı 1504 2023/02/05
Sınırtepe, Nusaybin 1346 2023/01/01
Sırmalıoya, Genç 1482 2023/02/12
Sırmaçek, Kiğı 1281 2023/02/04
Sırtköy, İdil 1525 2022/12/24
Sırçalı, Şirvan 1136 2023/01/14
Tahtköy, Tunceli 1429 2023/02/16
Tandır, Artuklu 1314 2023/01/02
Tanrıverdi, Kızıltepe 1614 2023/01/05
Tanrıyolu, Mazıdağı 1304 2023/01/05
Tanyeri, Dargeçit 1333 2022/12/27
Tarhan, Solhan 1460 2023/02/08
Tarlabaşı, Genç 1424 2023/02/11
Tarlabaşı, Kızıltepe 1358 2023/01/06
Tarlacık, Mazıdağı 1324 2023/01/04
Tatlıca, Kızıltepe 1351 2023/01/06
Tatlıpayam, Şirvan 1333 2023/01/12
Tatlı, Kurtalan 1130 2023/01/16
Tatlı, Yüksekova 1322 2022/12/17
Tatuşağı, Ovacık 1453 2023/02/14
Tavuklu, Ömerli 1900 2022/12/31
Tavşanlı, Dargeçit 1331 2022/12/28
Taşbalta, Tillo 1372 2023/01/12
Taşbaşı, Hakkâri 2447 2022/12/18
Taşdelen, Uludere 1383 2022/12/19
Taşdibek, Pervari 1476 2023/01/11
Taşgedik, Ömerli 1336 2022/12/31
Taşhöyük, Cizre 1316 2022/12/23
Taşkonak, Güçlükonak 1402 2022/12/24
Taşlıburç, Midyat 1563 2022/12/31
Taşlıca, Kızıltepe 1357 2023/01/06
Taşlıca, Ömerli 1340 2022/12/31
Taşlık, Pülümür 1408 2023/02/15
Taşlık, Savur 1337 2023/01/04
Taşlı, Şirvan 1456 2023/01/12
Taşlıçay, Kahta 1386 2023/01/22
Taşlıçay, Karlıova 1329 2023/02/05
Taşoluk, Kurtalan 1221 2023/01/17
Taşyaka, Şirvan 1130 2023/01/14
Taşıtlı, Hozat 1595 2023/02/15
Taşıt, Derik 1099 2023/01/07
Tecir, Adıyaman 1193 2023/01/28
Tekağaç, Beşiri 1093 2023/01/31
Tekağaç, Nusaybin 1381 2023/02/15
Tekbaş, Kiğı 1401 2023/02/04
Tekeköy, İdil 1294 2022/12/26
Tekeli, Çemişgezek 1386 2023/02/15
Tekeli, Şemdinli 2037 2022/12/15
Tekkuyu, Ömerli 1334 2022/12/31
Teknecik, Kâhta 1326 2023/01/20
Temelli, Dargeçit 1321 2022/12/27
Temürtaht, Mazgirt 1530 2023/02/13
Tepealtı, Nusaybin 1344 2023/01/01
Tepebağ, Derik 1360 2023/01/07
Tepebaşı, Bingöl 1382 2023/02/08
Tepecik, İdil 1279 2022/12/26
Tepeköy, İdil 1491 2022/12/26
Tepeli, Midyat 1305 2022/12/29
Tepeönü, Cizre 1275 2022/12/23
Tepeören, Nusaybin 1345 2023/01/01
Tepeüstü, Nusaybin 1440 2023/01/01
Tepsili, Ovacık 1388 2023/02/14
Tercan District 2035 2023/02/19
Teylan, Kurtalan 1603 2023/01/16
Tilkitepe, Artuklu 1091 2023/01/03
Tillo District 1939 2023/01/12
Timurçiftliği, Kızıltepe 1369 2023/01/06
Tiraşlı, Kızıltepe 1610 2023/01/06
Tokdere, Ömerli 1330 2022/12/31
Tokluca, Savur 1453 2023/01/04
Toklular, Karlıova 1323 2023/02/05
Toklu, İdil 1274 2022/12/26
Topalan, Bingöl 1188 2023/02/11
Topağaçlar, Adaklı 1425 2023/02/05
Topağaç, Ömerli 1339 2022/12/31
Topluca, Sason 1538 2023/02/04
Topraklı, İdil 1371 2022/12/27
Toptepe, Beytüşşebap 1316 2022/12/20
Toptepe, Midyat 1365 2022/12/29
Toptepe, Şırnak 1428 2022/12/22
Topuzlu, Ovacık 1458 2023/02/13
Toratlı, Çemişgezek 1472 2023/02/15
Tosunbağı, Kurtalan 1232 2023/01/16
Tosunlu, Kızıltepe 1350 2023/01/06
Tosuntarla, Pervari 1376 2023/01/11
Toytepe, Kurtalan 1222 2023/01/17
Tozan, Artuklu 1323 2023/01/03
Tozkoparan, Pertek 1386 2023/02/14
Tulgalı, Midyat 1561 2022/12/30
Tulumtaş, Kurtalan 1477 2023/01/15
Tunceli District 3125 2023/02/16
Turanlı, Kahta 1332 2023/01/22
Turgutköy, Nusaybin 1114 2023/01/02
Turnadere, Pülümür 1378 2023/02/15
Turnalı, Sason 1629 2023/02/04
Turnayolu, Nazımiye 1498 2023/02/13
Tuzcular, Pervari 1114 2023/01/12
Tuzkuyusu, Siirt 1214 2023/01/10
Tuzlaköy, Kızıltepe 1612 2023/01/06
Tuzluca, Karlıova 1420 2023/02/05
Tuzluca, Kızıltepe 1352 2023/01/06
Tuğlu, Yüksekova 1728 2022/12/16
Tüllük, Tunceli 1462 2023/02/16
Tünekpınar, Eruh 1746 2023/02/15
Türktaner, Hozat 1494 2023/02/15
Tütenocak, Baykan 1430 2023/01/14
Tütünköy, Kurtalan 1784 2023/01/16
Tütünlü, Şemdinli 2224 2022/12/15
Ufaca, Eruh 1579 2023/01/08
Ulak, İdil 1274 2022/12/26
Ulaşlı, Kızıltepe 1352 2023/01/06
Ulaştı, Baykan 1128 2023/01/15
Ulaş, Cizre 1289 2022/12/23
Ulaş, Dargeçit 1337 2022/12/27
Uludere District 4357 2022/12/24
Ulukale, Çemişgezek 1490 2023/02/15
Uluköy, Kurtalan 1467 2023/01/15
Uluköy, Kızıltepe 1414 2023/01/06
Ulupınar, Pertek 1471 2023/02/14
Ulutaş, Mazıdağı 1299 2023/01/05
Urganlı, Batman 1307 2023/01/29
Uslu, Derecik 1985 2022/12/15
Uzundal, Hozat 1461 2023/02/15
Uzungeçit, Uludere 1305 2022/12/19
Uzungöl, Çemişgezek 1414 2023/02/15
Uzunkaya, Kızıltepe 1367 2023/01/06
Uzunköy, Yeşilli 1314 2022/12/31
Uzunsavat, Bingöl 1467 2023/02/08
Uzuntarla, Tunceli 1371 2023/02/16
Uçarlı, İdil 1281 2022/12/27
Uğrak, İdil 1401 2022/12/26
Uğuraçan, Şemdinli 2213 2022/12/15
Uğurlu, Sincik 1275 2023/01/17
Uğurova, Bingöl 1376 2023/02/08
Uğur, Cizre 1282 2022/12/23
Varlık, Adıyaman 1470 2023/01/24
Varlık, Cizre 1272 2022/12/23
Varımlı, İdil 1319 2022/12/26
Veyselkarani, Baykan 1465 2023/01/14
Vezirli, Yüksekova 1095 2022/12/17
Viranşehir, Karlıova 1325 2023/02/05
Vişneli, Çemişgezek 1518 2023/02/15
Yakacık, Cizre 1290 2022/12/22
Yakıttepe, Kurtalan 1208 2023/01/17
Yalaz, İdil 1318 2022/12/26
Yalkaya, Şirvan 1128 2023/01/13
Yalmanlar, Ovacık 1508 2023/02/13
Yalım, Artuklu 2541 2023/01/03
Yalınağaç, Mazıdağı 1310 2023/01/05
Yalınkaya, Pertek 1467 2023/02/14
Yalınkılıç, Kızıltepe 1370 2023/01/06
Yalıntepe, Cizre 1396 2022/12/23
Yamanlar, Kızıltepe 1355 2023/01/06
Yamaçlı, Şirvan 1239 2023/01/14
Yamaçoba, Pertek 1471 2023/02/14
Yamaç, Bingöl 1295 2023/02/09
Yamaç, Kızıltepe 1349 2023/01/06
Yanarsu, Kurtalan 1133 2023/01/17
Yandere, Nusaybin 1346 2023/01/01
Yanıkses, Eruh 1337 2023/01/09
Yanılmaz, Dargeçit 1320 2022/12/27
Yanılmaz, Eruh 1576 2023/01/08
Yapraktepe, Pervari 1229 2023/01/12
Yarbaşı, Pülümür 1577 2023/02/15
Yarbaşı, İdil 1287 2022/12/26
Yardere, Artuklu 1314 2023/01/02
Yarımca, Baykan 1216 2023/01/15
Yarımca, Kızıltepe 1610 2023/01/06
Yarımkaya, Ovacık 1542 2023/02/14
Yarımtepe, Şirvan 1147 2023/01/13
Yatansöğüt, Genç 1573 2023/02/12
Yatağankaya, Güçlükonak 1337 2022/12/24
Yavruköy, Nusaybin 1595 2023/01/01
Yavuztaş, Yayladere 1424 2023/02/04
Yavşan, İdil 1432 2022/12/26
Yayalar, İdil 1278 2022/12/27
Yaydere, Genç 1475 2023/02/12
Yaygınçayır, Bingöl 1478 2023/02/08
Yaylabağ, Yayladere 1402 2023/02/04
Yaylabaşı, Artuklu 1319 2023/01/02
Yaylacık, Artuklu 1572 2023/01/02
Yaylacı, Şirvan 1133 2023/01/13
Yayladağ, Şirvan 1221 2023/01/13
Yayladere District 3029 2023/02/04
Yaylagünü, Ovacık 1508 2023/02/13
Yaylaköy, Artuklu 1748 2023/01/02
Yaylapınar, Şemdinli 2278 2022/12/16
Yaylatepe, Ömerli 1328 2022/12/31
Yaylayanı, Savur 1352 2023/01/04
Yayla, Genç 1653 2023/02/12
Yaylım, Kızıltepe 1353 2023/01/06
Yaylı, Artuklu 1298 2023/01/03
Yayvantepe, Midyat 1889 2022/12/30
Yayıkağıl, Nazımiye 1521 2023/02/13
Yayıklı, Besni 1171 2023/01/29
Yayıklı, Kurtalan 1116 2023/01/17
Yayıklı, Kızıltepe 1356 2023/01/06
Yazeli, Mazgirt 1521 2023/02/13
Yazgeldi, Nazımiye 1529 2023/02/13
Yazgülü, Bingöl 1389 2023/02/08
Yazgünü, Kiğı 1391 2023/02/04
Yazkonağı, Genç 1699 2023/02/12
Yazlıca, Siirt 1439 2023/01/09
Yazman, İdil 1324 2022/12/26
Yazyurdu, Nusaybin 1344 2023/01/01
Yazıcık, Derik 1103 2023/01/07
Yazılı, Genç 1468 2023/02/12
Yazır, Savur 1339 2023/01/04
Yazıören, Ovacık 1528 2023/02/14
Yağcılar, Şirvan 1261 2023/01/14
Yağmurca, İdil 1297 2022/12/26
Yağmurkuyusu, Güçlükonak 1501 2022/12/24
Yağmurpınar, Yedisu 1403 2023/02/04
Yağmurtepe, Siirt 1235 2023/01/10
Yağmur, Mazıdağı 1300 2023/01/05
Yağızca, Genç 1455 2023/02/11
Yağızoymak, Güçlükonak 1327 2022/12/24
Yaşarköy, Kızıltepe 1357 2023/01/05
Yaşaroğlu, Mazgirt 1653 2023/02/12
Yedikapı, Şirvan 1235 2023/01/13
Yedikardeş, Kızıltepe 1359 2023/01/06
Yedisu District 2544 2023/02/04
Yediyaprak, Eruh 1697 2023/01/08
Yeldeğen, Mazgirt 1528 2023/02/12
Yeldeğirmeni, Adaklı 1321 2023/02/05
Yelesen, Bingöl 1306 2023/02/10
Yelkaya, Genç 1621 2023/02/12
Yelkesen, Eruh 1437 2023/01/08
Yellice, Kurtalan 1135 2023/01/16
Yemişdere, Çemişgezek 1480 2023/02/15
Yemişli, Uludere 2642 2022/12/19
Yeniaslanbaşar, Şırnak 1492 2022/12/22
Yeniaydın, Pervari 1462 2023/01/11
Yenibaşak, Solhan 1389 2023/02/06
Yenibaşlar, Bingöl 1304 2023/02/10
Yenibudak, Mazgirt 1639 2023/02/13
Yenice, Artuklu 1085 2023/01/03
Yenice, Kahta 1328 2023/01/22
Yenidal, Solhan 1534 2023/02/06
Yenidoğdu, Hozat 1506 2023/02/15
Yenikonak, Ovacık 1489 2023/02/14
Yeniköprü, Kurtalan 1395 2023/01/16
Yeniköy, Artuklu 1573 2023/01/02
Yeniköy, Bingöl 1334 2023/02/10
Yeniköy, Karlıova 1158 2023/02/06
Yeniköy, Pertek 1469 2023/02/14
Yeniköy, Silopi 1424 2022/12/20
Yenilmez, Savur 1278 2023/01/03
Yenisu, Genç 1399 2023/02/11
Yenisöğüt, Ovacık 1488 2023/02/13
Yeniyazı, Genç 1536 2023/02/11
Yeniçevre, Genç 1481 2023/02/12
Yeniışık, Yüksekova 1555 2022/12/17
Yerköy, Nusaybin 1343 2023/01/01
Yerlibahçe, Siirt 1110 2023/01/10
Yerliçoban, Eruh 1354 2023/01/08
Yetkinler, Mazıdağı 1306 2023/01/04
Yeşilalan, Savur 1309 2023/01/03
Yeşilgöl, Yedisu 1420 2023/02/04
Yeşilkaya, Kahta 1316 2023/01/22
Yeşilkaya, Tunceli 1486 2023/02/16
Yeşilkonak, Kurtalan 1485 2023/01/16
Yeşilköy, Bingöl 1128 2023/02/11
Yeşilköy, Kızıltepe 1376 2023/01/06
Yeşilköy, Mazıdağı 1667 2023/01/05
Yeşiller, Kızıltepe 1609 2023/01/05
Yeşilli District 2055 2022/12/31
Yeşilova, Gölbaşı 1175 2023/01/29
Yeşilova, Çelikhan 1455 2023/01/18
Yeşilyazı, Ovacık 1459 2023/02/13
Yeşilyurt, Cizre 1414 2022/12/23
Yeşilçevre, Baykan 1445 2023/01/14
Yeşilören, Eruh 1592 2023/01/08
Yeşilöz, Beytüşşebap 1331 2022/12/20
Yeşilöz, Midyat 1313 2022/12/29
Yiğitbaşı, Genç 1423 2023/02/11
Yiğitharmanı, Solhan 1485 2023/02/08
Yiğitler, Karlıova 1428 2023/02/05
Yiğitler, Nazımiye 1494 2023/02/13
Yokuşbağları, Siirt 1250 2023/01/10
Yokuşlu, Eruh 1369 2023/01/08
Yolaldı, Kızıltepe 1608 2023/01/06
Yolaçan, İdil 1283 2022/12/26
Yolaçtı, Genç 1642 2023/02/12
Yolağzı, Silopi 1311 2022/12/21
Yolbaşı, Artuklu 1574 2023/01/03
Yolbaşı, Midyat 1752 2022/12/30
Yolbaşı, Şirvan 1223 2023/01/13
Yolbilen, Nusaybin 1339 2023/01/01
Yoldere, Kızıltepe 1354 2023/01/05
Yoldurağı, Kurtalan 1142 2023/01/17
Yolindi, Nusaybin 1352 2023/01/01
Yolkonak, Tunceli 1368 2023/02/16
Yolçatı, Bingöl 1425 2023/02/08
Yolüstü, Kızıltepe 1612 2023/01/05
Yoncalık, Karlıova 1328 2023/02/05
Yoncalık, Yüksekova 2185 2022/12/16
Yoncalı, Dargeçit 1332 2022/12/27
Yoncalı, Hakkâri 1607 2022/12/17
Yoncalı, Kızıltepe 1350 2023/01/06
Yoncalı, Ovacık 1363 2023/02/13
Yorgançayır, Karlıova 1410 2023/02/05
Yoğunçam, Ovacık 1495 2023/02/13
Yoğurtçular, Şırnak 1494 2022/12/22
Yufkalı, Şemdinli 2018 2022/12/15
Yukarıakpınar, Bingöl 1402 2023/02/09
Yukarıaydınlı, Artuklu 1308 2023/01/03
Yukarıazıklı, Kızıltepe 1370 2023/01/05
Yukarıbalcılar, Pervari 1287 2023/01/11
Yukarıbudak, Çemişgezek 1402 2023/02/15
Yukarıdoluca, Nazımiye 1553 2023/02/13
Yukarıgülbahçe, Pertek 1508 2023/02/14
Yukarıhatunlu, Artuklu 1297 2023/01/03
Yukarıkonak, Mazıdağı 1325 2023/01/04
Yukarımezraa, Derik 1425 2023/01/07
Yukarıocak, Mazıdağı 1363 2023/01/04
Yukarıoyumca, Mazgirt 1544 2023/02/12
Yukarıserinyer, Kiğı 1382 2023/02/04
Yukarıyakabaşı, Pertek 1484 2023/02/14
Yukarıyağmurlu, Karlıova 1342 2023/02/05
Yukarıyeniköy, Artuklu 1077 2023/01/03
Yumaklı, Bingöl 1402 2023/02/10
Yumrucuk, Kızıltepe 1354 2023/01/06
Yumrutaş, Kızıltepe 1359 2023/01/06
Yurtderi, Kızıltepe 1358 2023/01/06
Yurtözü, Kızıltepe 1358 2023/01/06
Yuvalı, Kurtalan 1517 2023/01/15
Yuvalı, Midyat 1315 2022/12/29
Yuvalı, İdil 1423 2022/12/26
Yuvalıçay, Sason 1547 2023/02/04
Yörük, İdil 1278 2022/12/26
Yücebağ, Mazıdağı 1304 2023/01/04
Yüceldi, Hozat 1535 2023/02/15
Yüceli, Kızıltepe 1443 2023/01/05
Yüce, Artuklu 1079 2023/01/03
Yüksekköy, İdil 1284 2022/12/26
Yüksekova, Hakkâri 3103 2022/12/22
Yüksektepe, Kızıltepe 1615 2023/01/06
Yünbüken, Çemişgezek 1195 2023/02/15
Yürekli, Yüksekova 1093 2022/12/17
Yürekveren, Kurtalan 1229 2023/01/16
Yılmaz, Dargeçit 1320 2022/12/28
Zeynelli, Yayladere 1424 2023/02/04
Zeytinli, Yeşilli 1322 2022/12/31
Ziyaret, Kızıltepe 1356 2023/01/05
Ziyaret, Midyat 1250 2022/12/29
Ziyaret, Ovacık 1447 2023/02/13
Ziyaret, Sason 1554 2023/02/03
Zorkaya, Siirt 1081 2023/01/10
Çadırkaya, Tercan 1293 2023/02/23
Çadırlı, Derik 1105 2023/01/07
Çakmaklar, Adıyaman 1152 2023/01/28
Çakmaklı, Ovacık 1478 2023/02/14
Çakıllı, Kurtalan 1142 2023/01/17
Çakırbahçe, Pertek 1462 2023/02/14
Çakırkaya, Pülümür 1385 2023/02/15
Çakır, Kızıltepe 1352 2023/01/06
Çaldere, Midyat 1310 2022/12/30
Çalkıran, Tunceli 1479 2023/02/16
Çalkışla, Tercan 1518 2023/02/19
Çalpınar, Midyat 1311 2022/12/29
Çaltıkoru, Hakkâri 2074 2022/12/18
Çalıdüzü, Kurtalan 1144 2023/01/17
Çalıkağıl, Yayladere 1577 2023/02/04
Çalıköy, Nusaybin 1393 2023/01/01
Çalıözü, Pertek 1469 2023/02/14
Çalışan, Ömerli 1336 2022/12/31
Çalışkanlar, Şemdinli 1321 2023/02/15
Çalışkan, Silopi 1355 2022/12/20
Çalışlı, Artuklu 1403 2023/01/03
Çambulak, Ovacık 1525 2023/02/13
Çamlıca, Adaklı 1302 2023/02/05
Çamlıca, Kahta 1366 2023/01/22
Çamlıca, Kızıltepe 1352 2023/01/05
Çamlıdere, Kızıltepe 1636 2023/01/05
Çamlıyurt, Genç 1120 2023/02/12
Çamtaşı, Baykan 1132 2023/01/15
Çamyurt, Midyat 1308 2022/12/29
Çanaklı, Hakkâri 2456 2022/12/17
Çanaklı, Kızıltepe 1354 2023/01/06
Çanakçı, Genç 1448 2023/02/11
Çanakçı, Kiğı 1367 2023/02/04
Çandarlı, Midyat 1557 2022/12/31
Çankaya, Mazıdağı 1303 2023/01/04
Çardaklı, Silopi 1391 2022/12/20
Çataksu, Pertek 1510 2023/02/14
Çatak, Artuklu 1536 2023/01/03
Çatak, Karlıova 1306 2023/02/05
Çatalan, Dargeçit 1320 2022/12/28
Çatalca, Kızıltepe 1354 2023/01/06
Çatalca, Şemdinli 2319 2022/12/16
Çatalkaya, Yayladere 1433 2023/02/04
Çatalköy, Cizre 1300 2022/12/23
Çataltepe, Derik 1392 2023/01/07
Çatalyurt, Ömerli 1343 2022/12/31
Çatalözü, Nusaybin 1794 2023/01/01
Çatköy, Mazgirt 1533 2023/02/12
Çatköy, Ovacık 1541 2023/02/13
Çatköy, Pervari 1093 2023/01/12
Çatma, Adaklı 1319 2023/02/05
Çatma, Yüksekova 1377 2022/12/16
Çattepe, Kurtalan 1362 2023/01/15
Çavuşköy, Cizre 1313 2022/12/23
Çavuşlar, Bingöl 1145 2023/02/11
Çavuşlu, Dargeçit 1323 2022/12/28
Çavuşlu, Midyat 2197 2022/12/29
Çavuşlu, Pervari 1292 2023/01/11
Çayağzı, Bingöl 1232 2023/02/11
Çayağzı, Yayladere 1442 2023/02/04
Çaybaşı, Genç 1125 2023/02/12
Çaybaşı, Kızıltepe 1613 2023/01/06
Çayboyu, Bingöl 1122 2023/02/11
Çaykaya, Baykan 1431 2023/01/14
Çayköy, Derik 1330 2023/01/07
Çaytaşı, Hozat 1512 2023/02/15
Çaytepe, Genç 1428 2023/02/11
Çayönü, Mazıdağı 1302 2023/01/05
Çayüstü, Ovacık 1478 2023/02/13
Çayıralanı, Ömerli 1342 2022/12/31
Çayırlı District 2182 2023/02/25
Çayırlı, Kurtalan 1141 2023/01/17
Çayırpınar, Artuklu 1105 2023/01/03
Çağbaşı, Siirt 1593 2023/01/09
Çağlarca, Hozat 1505 2023/02/15
Çağlar, Artuklu 1085 2023/01/03
Çağlar, Nusaybin 1344 2023/01/01
Çağlayan, Pülümür 1522 2023/02/15
Çağıl, Cizre 1323 2022/12/23
Çağıl, Derik 1106 2023/01/07
Çağıl, Kızıltepe 1353 2023/01/05
Çelikköy, Dargeçit 1324 2022/12/28
Çelikli, Baykan 1316 2023/01/14
Çeltikbaşı, Kurtalan 1382 2023/01/15
Çeltiksuyu, Bingöl 1219 2023/02/11
Çeltiksuyu, Eruh 1349 2023/01/08
Çeltikyolu, Şirvan 1137 2023/01/13
Çemberlitaş, Ovacık 1830 2023/02/13
Çemçeli, Tunceli 1473 2023/02/16
Çetinkaya, Kızıltepe 1614 2023/01/06
Çetinkol, Eruh 1587 2023/01/08
Çetinler, Kızıltepe 1359 2023/01/05
Çevirme, Genç 1423 2023/02/11
Çevrecik, Nazımiye 1462 2023/02/13
Çevreli, Adaklı 1478 2023/02/05
Çevre, Şemdinli 1540 2023/02/12
Çevrimli, Güçlükonak 1331 2022/12/24
Çevrimpınar, Bingöl 1412 2023/02/10
Çevrimtepe, Baykan 1651 2023/01/14
Çeşmebaşı, Batman 1321 2023/01/30
Çiftlikköy, Artuklu 1096 2023/01/03
Çiftlikköy, Karlıova 1330 2023/02/05
Çiftlikköy, Silopi 1417 2022/12/20
Çikan, Yayladere 1453 2023/02/04
Çimencik, Eruh 1338 2023/01/08
Çimenlik, Ömerli 1334 2022/12/31
Çimenli, Hakkâri 2019 2022/12/18
Çimenli, Kızıltepe 1353 2023/01/06
Çimenli, Tunceli 1467 2023/02/16
Çiriş, Bingöl 1293 2023/02/09
Çitlibağ, Kızıltepe 1357 2023/01/06
Çizmeli, Eruh 1699 2023/01/08
Çiçekdere, Bingöl 1434 2023/02/10
Çiçektepe, Kiğı 1397 2023/02/04
Çiçekyayla, Bingöl 1302 2023/02/10
Çiğdem, Nusaybin 1596 2023/01/02
Çobankazanı, Güçlükonak 1412 2022/12/24
Çobantaşı, Bingöl 1301 2023/02/10
Çobanyıldızı, Pülümür 1592 2023/02/15
Çobançeşmesi, Genç 1486 2023/02/11
Çobanören, Pervari 1297 2023/01/11
Çubuklu, Şemdinli 2197 2022/12/15
Çukurca District 3869 2022/12/22
Çukurca, Baykan 1458 2023/01/14
Çukurca, Bingöl 1418 2023/02/10
Çukurca, Pertek 1448 2023/02/14
Çukurca, Yüksekova 1293 2022/12/17
Çukurdede, Dargeçit 1342 2022/12/27
Çukurköy, Pervari 1185 2023/01/12
Çukurlu, İdil 1410 2022/12/26
Çukursu, Derik 1403 2023/01/07
Çukurtepe, Karlıova 1316 2023/02/05
Çukuryurt, Artuklu 1317 2023/01/03
Çukur, Tunceli 1502 2023/02/16
Çölova, Nusaybin 1351 2023/01/01
Çöğürlük, Ovacık 1370 2023/02/13
Çınaraltı, Ömerli 1346 2022/12/31
Çınarcık, Kızıltepe 1618 2023/01/05
Çınarlı, İdil 1285 2022/12/27
Çınarlı, Şirvan 1135 2023/01/13
Çınarönü, Savur 1343 2023/01/03
Çıplaktepe, Artuklu 1577 2023/01/03
Çıplak, Kızıltepe 1361 2023/01/06
Çıralı, Tunceli 1365 2023/02/16
Çırpılı, Eruh 1684 2023/01/08
Çığlıca, Beytüşşebap 1486 2022/12/20
Çığırlı, Hozat 1505 2023/02/15
Çığır, İdil 1416 2022/12/26
Ömerli District 4143 2022/12/31
Ömürlü, Mazıdağı 1324 2023/01/04
Ördekli, Hakkâri 1873 2022/12/18
Örencik, Kızıltepe 1358 2023/01/06
Öreniçi, Mazgirt 1527 2023/02/12
Örnekköy, Yüksekova 1098 2022/12/17
Öveçler, Ovacık 1464 2023/02/14
Özbek, İdil 1404 2022/12/26
Özdek, Mazgirt 1600 2023/02/12
Özen, İdil 1303 2022/12/26
Özgen, Silopi 1087 2022/12/21
Özlüce, Artuklu 1084 2023/01/03
Özlüpelit, Eruh 1614 2023/01/08
Özpınar, Şirvan 1326 2023/01/12
Öztaş, Ömerli 1591 2022/12/31
Öğündük, İdil 6219 2022/12/26
Ülkerköy, Kızıltepe 1624 2023/01/06
Ünlüce, Baykan 1425 2023/01/15
Ünsallı, Ömerli 1334 2022/12/31
Ünveren, Pülümür 1463 2023/02/15
Ürek, Erzincan 1115 2023/02/26
Ürünlü, Mazıdağı 1128 2023/01/05
Üzümcü, Hakkâri 1851 2022/12/18
Üzümlü District 2708 2023/02/24
Üzümlük, Eruh 1620 2023/01/08
Üzümlü, Çukurca 1979 2022/12/17
Üçağaç, Silopi 1433 2022/12/21
Üçağıl, Midyat 1321 2022/12/30
Üçdam, Pülümür 1491 2023/02/15
Üçdirek, Adıyaman 1394 2023/01/25
Üçerli, Savur 1353 2023/01/04
Üçevler, Kızıltepe 1609 2023/01/05
Üçgül, Genç 1645 2023/02/12
Üçkavak, Savur 1386 2023/01/03
Üçkuyu, Derik 1402 2023/01/07
Üçköy, Nusaybin 1355 2023/01/01
Üçok, İdil 1275 2022/12/26
Üçoyuk, Pervari 1114 2023/01/12
Üçpınar, Kurtalan 1251 2023/01/16
Üçtepe, Derik 1394 2023/01/07
Üçyaka, Bingöl 1290 2023/02/09
Üçyol, Nusaybin 1433 2023/01/01
İbimahmut, Mazgirt 1676 2023/02/12
İdil District 5849 2022/12/26
İkikuyu, Kızıltepe 1128 2023/01/06
İkipınar, Ömerli 1336 2022/12/31
İkisu, Mazıdağı 1299 2023/01/05
İkitepe, Ömerli 1334 2022/12/31
İkizbağlar, Tillo 1323 2023/01/12
İkizce, Şırnak 1228 2022/12/22
İkizdere, Midyat 1308 2022/12/29
İkizler, Baykan 1339 2023/01/14
İkizler, Kızıltepe 1609 2023/01/06
İkizler, Şirvan 1634 2023/01/12
İkiztepe, Nusaybin 1348 2023/01/01
İlbeyi, Kiğı 1442 2023/02/04
İnandık, Solhan 1463 2023/02/08
İnandı, Kızıltepe 1607 2023/01/06
İnanlı, Yüksekova 1097 2022/12/17
İncekaya, Şirvan 1320 2023/01/12
İnceler, Uludere 1227 2022/12/19
İncesu, Bingöl 1128 2023/02/11
İncesu, Derik 1388 2023/01/07
İncirlik, Kurtalan 1228 2023/01/16
İncirli, Çelikhan 1455 2023/01/18
İnkapı, Siirt 1218 2023/01/10
İnköy, Hozat 1368 2023/02/15
İpekli, Adıyaman 1399 2023/01/23
İsmailli, Mazgirt 1640 2023/02/13
İçören, Savur 1295 2023/01/04
İğdeli, Kurtalan 1226 2023/01/16
İşgören, Savur 1342 2023/01/04
Şabanköy, Bingöl 1423 2023/02/08
Şahverdi, Derik 1379 2023/01/07
Şahverdi, Ovacık 1484 2023/02/14
Şampaşakaraderbendi, Pülümür 1619 2023/02/15
Şanlı, Mazıdağı 1347 2023/01/05
Şehitköy, Genç 1233 2023/02/12
Şehittepe, Genç 1394 2023/02/11
Şemdinli District 5866 2022/12/22
Şemikan, Adıyaman 1411 2023/01/23
Şenköy, Kahta 1333 2023/01/22
Şenköy, Kurtalan 1247 2023/01/16
Şenköy, Midyat 1379 2022/12/30
Şenköy, Yedisu 1250 2023/02/04
Şenoba, Uludere 1309 2022/12/19
Şenocak, Savur 1338 2023/01/04
Şenyuva, Mazıdağı 1305 2023/01/04
Şerefli, Derik 1409 2023/01/07
Şimşirpınar, Solhan 1410 2023/02/06
Şirvan District 4789 2023/01/12
Şırnak District 3653 2022/12/22

Arbitrary break

I think you're in the wrong location. Per WP:MASSCREATION, the correct venue to request the right to mass-create articles in a semi-automated fashion is at WP:BFRA. --Jayron32 18:50, 28 February 2023 (UTC)
It is sort of a chicken/egg scenario. Yes, this will need a BRFA - but the BRFA will want to see that there is community support for the activity. That can occur beforehand (such as here), as part of the BRFA, or separately prior to the BRFA closing. The BRFA will primarily focus on the technical aspects, but will also be looking to see that there is consensus for the activity at all. If this is a completely inappropriate activity for a bot, the proposed operator could just stop now. 18:59, 28 February 2023 (UTC) — xaosflux Talk 18:59, 28 February 2023 (UTC)
Based on the discussion on their talk page, I don't think they want to use a bot; they're using a boilerplate template to create new articles. Thus discussion at the village pump may be more appropriate. isaacl (talk) 19:04, 28 February 2023 (UTC)
Gotcha, so unless a bot-flagged account is going to be used to make "likely good" edits that are autopatrolled, etc - no BRFA will be involved. "Mass-creation" is certainly subjective, if it is going to flood recent changes - bot is the way, else may not be needed. — xaosflux Talk 19:15, 28 February 2023 (UTC)
WP:MASSCREATE says Any large-scale automated or semi-automated content page creation task must be approved at Wikipedia:Bots/Requests for approval. (emphasis added) Maybe we should update that to say that non-bot semi-automated mass creation should be approved at VPR, if BAG doesn't want semi-auto to go to BRFA. Levivich (talk) 20:58, 1 March 2023 (UTC)
This! I'm not interested in a bot but to continue my boilerplate template if possible. Semsûrî (talk) 19:43, 28 February 2023 (UTC)
Semsuri, can you expand a little bit about the proposed creations, like how many are you planning to make, based on what sources, and give a few examples of what they look like when done? I assume we're talking about articles like Altınbaşak, Üzümlü and Gökçe, Artuklu, in the same form, using the same sources?
Also, how is this related to your earlier effort to redirect existing village articles, if it's related at all? (I saw the discussion on your talk page.)
I would support either redirecting villages to other articles (that can contain the information about villages), or creating new village stubs (if redirecting is not desirable), I'm just not sure what is the best way, and maybe it's redirecting some and having stand-alone pages for others. Levivich (talk) 19:31, 28 February 2023 (UTC)
I can give a very specific estimate by counting the number of villages and towns in the provinces that I haven't gotten around to yet (I'm not planning on creating an article for every notable settlement in the country!).
The two primary sources that are recurring in all of the pages are TUIK and e-icisleri - the former gives me info on population history from 2007 to 2022 while the other gives me info on the administrative status of the entity and whether there are hamlets attached to the entity. Ofis, Kızıltepe is an example of an article with the bare minimum. In many cases, however, I have secondary references that allows me to expand the pages to various degrees as seen with these:
The issues with the articles that I redirected last year were plenty including lack of primary references that confirmed their status (some quarters in a town had their own article claiming to be villages), no coordinates, no population, and so on, so I just believed that the easiest thing to do was to redirect them (which was also very cathartic for me). Since then (and having in mind that I had plenty of secondary and reliable references in my library), I believed I could create better articles — even the stubs that I have created are of better quality than the ones we were used to.
I'm going to do my calculations now. Semsûrî (talk) 20:23, 28 February 2023 (UTC)
  • My advice… take your time. Go slowly. Do say 5 articles… wait to see if there are any problems… if none, then do 10 and wait… If after a few iterations of this no one is stating a problem, you can ramp up the pace further. Blueboar (talk) 19:36, 28 February 2023 (UTC)
  • You didn't say much about the amount of content within the articles. The worst case scenario that is covered by your request would be a zillion content free stubs with just an "it exists" statement with one reference which supports "it exists" I took a look at 2 of your articles and they have a lot more content and sourcing than that. Looking at that and you saying SEMI-automated, you have real articles each with a few sources and a few sections and text covering a few areas and a moderate amount of time invested in each one. . If so, we're talking about a moderate amount of real articles, not a zillion geostubs. If so, perhaps you could describe that in a few sentences and then I think it would receive affirmation / support here. Sincerely North8000 (talk) 20:13, 28 February 2023 (UTC)
  • What is the overall scope of your endeavor (e.g. 500 articles over 3 months)? — xaosflux Talk 20:31, 28 February 2023 (UTC)
    2,004 since 15 December. Semsûrî (talk) 21:13, 28 February 2023 (UTC)
  • So from my quick calculations, there are around 2.7K articles left. Semsûrî (talk) 20:50, 28 February 2023 (UTC)
  • Articles created so far seem good. I'd suggest Blueboar's approach to start, but this is a good endeavour. DFlhb (talk) 21:08, 28 February 2023 (UTC)
  • The first three articles on that list have 5+ references and material derived from them, multiple sections and represent at least a moderate investment of time on each one. I support continuation of that (or even articles a bit skimpier) and thank you for your work. Sincerely, North8000 (talk) 21:19, 28 February 2023 (UTC)
  • Looking at the table some of these are appropriate, but the majority appear to be the sort of stub that got Lugnuts into trouble (for example, 100. Yıl, Adıyaman). If Semsûrî limits themselves to the more expansive articles that would be fine, but the majority of the articles are not. BilledMammal (talk) 03:28, 1 March 2023 (UTC)
    I believe the Lugnuts problem involved mass-use of unreliable sources (as opposed to here, government sources), and violations of WP:GEOLAND; but the article you link above seems to suffer from neither problem. DFlhb (talk) 03:59, 1 March 2023 (UTC)
    I was referring to the broader Lugnuts problem, that resulted in him being topic banned from creating articles of less than 500 words; the articles listed above are the same sort that resulted in that sanction, and the rate of creation is very similar. I think you are referring to the narrower Lugnuts Turkish village problem, that resulted in him losing autopatrolled and having all the relevant articles deleted. BilledMammal (talk) 04:06, 1 March 2023 (UTC)
    All of the articles will be expanded with info added to the template:historical populations as you can see at 100. Yıl, Adıyaman expanding these articles a bit. Semsûrî (talk) 09:06, 1 March 2023 (UTC)
    In some ways that is better, but it makes other things worse; when an article consists of little but a table showing population growth by year it introduces WP:NOTDATABASE issues. What is needed is additional prose, giving information on the history, geography, economy, etc of the location. BilledMammal (talk) 09:12, 1 March 2023 (UTC)
    I don't disagree that additional prose would make the article better, but the addition of the population chart does not make anything worse, nor does it introduce "WP:NOTDATABASE issues." That guideline is concerned with "excessive listings of unexplained statistics" that "lack context or explanation can reduce readability" and further suggests that "statistics should be placed in tables to enhance readability, and articles with statistics should include explanatory text providing context." In the case of 100. Yil, the population statistics are not excessive and do not reduce readability. Moreover, they are placed in a table (as the guideline suggests), and the article includes explanatory text explaining that there has been a recent decline in population due to climate issues. This seems to be exactly what NOTDATABASE suggests. Cbl62 (talk) 12:29, 1 March 2023 (UTC)
    The explanatory text providing context and rectifying the WP:NOTDATABASE issues was added after my comment. I would still prefer additional prose and a second source providing WP:SIGCOV, but considering the locations are currently covered by WP:GEOLAND I wouldn't object to Semsûrî's creations if they were all like the current status of 100. Yıl, Adıyaman. For the moment, they aren't, but I understand Semsûrî intends to bring them up to that status; once they do so for the current 2000 I would support the creation of the final 3000. BilledMammal (talk) 13:17, 1 March 2023 (UTC)
    Yes, I've created a database for myself (User:Semsûrî/Turkeyplaces) where I can keep track on my work. There are many articles that are at the same level or more voluminous than 100. Yıl like Kayalık, Çukurca and Anadağ, Derecik but it would be great to have clear criterias so I don't have to guess whether I've reached a sufficient volume at each article. I'm planning on adding the historical population template to all of the articles and moreover expand the prose based on secondary references. Semsûrî (talk) 19:48, 1 March 2023 (UTC)
    @Semsûrî: Thanks for answering all these questions. If I understand correctly, for every article you have created (about 2000 so far) and plan to create (about another 2700), there is at least one secondary source (in addition to the databases TUIK and Icisleri). I understand that creation of the stubs with the database sources can be done semi-automatically (with a template), but expansion of those stubs with the secondary source cannot, that requires manual work, and so will take longer.
    Assuming I understand correctly, here is my question: can you create these articles so that when they are created, the secondary source is listed in a "Further reading" section (even if it hasn't yet been worked into the article as a source)? That way, every article created will have at least one secondary source in the Further reading. Is it possible/reasonable to do? Levivich (talk) 20:00, 1 March 2023 (UTC)
    Sometimes a secondary reference is used in multiple articles where I change the prose + page in the citation template. So, at times a secondary reference is included in my boilerplate template. I see the point in adding a 'Further reading-section' if there are none utilized as sources and it shouldn't be an issue. Semsûrî (talk) 20:38, 1 March 2023 (UTC)
    WP:MASSCREATE says all mass-created articles (except those not required to meet WP:GNG) must cite at least one source which would plausibly contribute to GNG, so I think if you are including the secondary source in "Further reading" then that's good enough (even if the source isn't yet cited for prose). That way, anyone looking at the article knows the village has at least one GNG source (the one in Further reading), plus anyone else who wants to expand the article will have at least one source listed they can use to expand it, so I think it would encourage expansion. Levivich (talk) 21:02, 1 March 2023 (UTC)
  • The articles are covered by GEOLAND, and having checked a dozen or so I'm not seeing issues. They appear better than many such stub location articles. -- LCU ActivelyDisinterested ∆transmissions∆ °co-ords° 19:57, 1 March 2023 (UTC)
  • Support after the discussion above. It isn't a ridiculous amount (2k created, 2.7k to go, <5k total), it's not like 100k of villages in Turkey. Each article would be supported by at least one non-database source (included at least in Further reading, as I understand it), so it's not like an indiscriminate collection (not like every village in Turkey), and it's not just scraping a database and copy/pasting it to Wikipedia. Because of the secondary source, I think it's reasonable to believe the articles will be expanded (at least there exists one source that can be used for expansion, which is more than we can say about other mass-created articles from other users in the past). I don't think redirects would be a good alternative; I think it would make articles like Üzümlü District unwieldy if we merged every village (e.g. Altınbaşak, Üzümlü) into the district article. I'm generally more inclined to see the value in populated, legally-recognized place stubs than other types of stubs (obscure athletes). Finally, WP:SYSTEMICBIAS encourages me to support; we have articles about every abandoned train stop and dirt road in the US; because Wikipedia is so heavily Western, we don't have as many editors who are going to manually create articles about populated/legally-recognized villages in Turkey, as compared to editors who will write about places in the US, so I'm more inclined to say yeah, let's do some mass-creation of expandable stubs about non-Western notable topics to even out systemic bias. Levivich (talk) 21:18, 1 March 2023 (UTC)
  • Conditional Support I would strongly suggest asking a bot coder to include more information upon creation than just population. I would also support the deletion and recreation of ones I started over 10 years ago without much information. It would be much more beneficial for Wikipedia to have near start class articles on these villages than short stubs sitting around which nobody is working on. Much better to do this than redirect to districts as the proposer did in the past. I would oppose a proposal to mass create one or two line stubs like Gökçe, Artuklu. I generally don't like what bots do on Swedish and Cebuano wiki etc but I'm of the opinion that English Wikipedia would benefit massively for a bot to create missing populated settlements which are near start class upon creation and consistent. I did propose something back in 2008 in fact with Fritz. ♦ Dr. Blofeld 14:31, 2 March 2023 (UTC)
    I'm of the opinion that English Wikipedia would benefit massively for a bot to create missing populated settlements which are near start class upon creation and consistent In theory I would support this; I suspect it can be done well, and if it is the result would be both the creation of new articles and the improvement of existing articles. BilledMammal (talk) 14:43, 2 March 2023 (UTC)
    In the case of Turkey, I would even include depopulated settlements due to the violent history of the Kurdish region. Kovankaya, Beytüşşebap is unpopulated but still notable enough to have its own article. Semsûrî (talk) 18:33, 2 March 2023 (UTC)
  • CONDITIONAL support Conditional on them having the amount of content and sourcing in the first three of the 4 listed examples, or close to it. North8000 (talk) 14:50, 2 March 2023 (UTC)
  • Conditional support per North8000. I had many of these watchlisted and up until now, it looks like the vast majority have been based purely on lists and statistics like Saray, Nizip, Kilis, Sason and Kulaksız, Sason. Any further creations would ideally include in-depth secondary sources like Gelinkaya, Midyat, Ayranlı, Şemdinli and Bağlar, Şemdinli. Question for Semsûrî: As someone who doesn't read the language, could you explain the political status of these villages? Are they self-governing municipalities, census tracts or something else? I just want to make sure we don't make the same mistakes as past mass creators. –dlthewave ☎ 00:05, 4 March 2023 (UTC)
    On the village politically, I think Jongerden explains it best:

    "The center-village model is best understood against an administrative background. Administration in Turkey is strong in centers, but weak in peripheries. The villages are formally headed by the village-chief (muhtar), who is supposed to implement the law in village affairs and act upon directives of the governor and district officer. In practice, the governor and district officer do not take much notice of village affairs (as long there is no urgent need), and the village headman does not take much notice of the law (so long as he is not forced to), particularly if village custom already provides an accepted alternative method of dealing with a problem". The administrative status of the hamlets, which outnumber villages by almost a third, is unclear. In some occassions the muhtar of a neighboring village has authority over a hamlet, but at other times a formal administration is absent, and administration takes place through customary law.

    Not mentioned in the quote is that muhtars are locally elected by the village. Semsûrî (talk) 10:43, 4 March 2023 (UTC)
    Quote is from "The Settlement Issue in Turkey and the Kurds" by Joost Jongerden (page 292) Semsûrî (talk) 10:44, 4 March 2023 (UTC)

Promote WikiShootMe.js user script as Gadget

I am writing to request the promotion of the WikiShootMe.js user script as a Gadget on Wikipedia. The WikiShootMe.js user script is a useful tool that allows users to quickly access the Wikishoot tool page, which displays Wikidata items, Wikipedia articles, and Commons images with coordinates on the same map, won the Coolest Tool Award in 2021.

The user script takes latitude and longitude coordinates from a Wikipedia page and redirects the user to the Wikishoot tool page. This can be very useful for editors who need to quickly locate images and other media related to a particular location.

The WikiShootMe.js user script has been developed and tested by myself and other users, and we believe it meets the criteria for promotion as a Gadget on Wikipedia. I have provided a link to the script below, along with an installation guide for interested users:

Script link: User:Gopavasanth/UserScripts/WikiShootMe.js Installation guide: User:Gopavasanth/UserScripts More about the tool: WikiShootMe on Meta-Wiki.

Thank you for your consideration. Please let me know if you have any questions or need further information.

Sincerely, Gopavasanth (talk) 05:51, 5 March 2023 (UTC)

Adopt MILHIST's C-class quality assessment criteria

WikiProject Military history's assessment criteria can be viewed at WP:MHA#CRIT. Their C-class criteria are:

The article meets B1 or B2 as well as B3 and B4 and B5 of the B-Class criteria.

I am proposing we adopt this for WP:ASSESS's C-class criteria. B6 would not be required for C-class; note that some projects don't use B6.

Rationale:

  • The current distinction between Start-class and C-class is somewhat subjective.
  • This provides much more objective criteria for C-class, which will make our ratings more consistent across articles.
  • Grades provide "gamification" that incentivise article expansion, so the more precise they are, the more effective the incentive is.
  • These criteria provide clearer guidance for editors wishing to improve Start-class articles, who may be unsure of where to start.
  • When one B-criteria is filled, the B-criteria are shown by default on Start-class articles, which this proposal would not affect.

DFlhb (talk) 13:07, 17 February 2023 (UTC)

I agree that the line between Start and C is blurry. But as someone who edits in topics that have some overlap with MILHIST, I've found that particular assessment system and the B-checklist tool to be more of a mild annoyance than anything. I suspect you could come up with an article that's only a few sentences long but would technically meet this set of C-class criteria. Thebiguglyalien (talk) 15:30, 17 February 2023 (UTC)
Wouldn't that fail B3? DFlhb (talk) 11:28, 18 February 2023 (UTC)
You don't need much content to make a lead and a section. Thebiguglyalien (talk) 16:15, 18 February 2023 (UTC)
I see. I've noticed that even short MILHIST articles tend to be far better sourced than for other WikiProjects. Maybe that has at least a little to do with their criteria incentivising either completeness or sourcing, while our current criteria just incentivises completeness? Seems like a bad incentive. DFlhb (talk) 16:57, 18 February 2023 (UTC)
I hate to ask this, but does anyone outside of MILHIST and I guess the 1.0 Editorial Team actually care about the non GA/FA article criteria? Sideswipe9th (talk) 23:31, 17 February 2023 (UTC)
From my experience at talk pages, apparently NO, at least for C/Start class. —CX Zoom[he/him] (let's talk • {C•X}) 08:43, 18 February 2023 (UTC)
MILHIST very much cares about b-class, with the others being less significant. Hog Farm Talk 16:31, 18 February 2023 (UTC)
Very much so. C class did not originate at MILHIST. It was brought in by other projects and adopted by MILHIST for conformity only after some debate. I argued against it; I did not think creating an additional class between Start and B was worthwhile, given that B is the minimum acceptable standard for any article. The outcome was not what the advocates expected. It resulted in the criteria for B class being hardened. Where once an article could have an unreferenced sentence or two and still be waved through as B class, now such articles were now graded C. Over time the role of C class has become that of identifying candidates for elevation to B class through a small amount of work. Currently MILHIST has about 20,000 articles rated B class and 60,000 as C class. Hawkeye7 (discuss) 18:40, 18 February 2023 (UTC)
WP:MILHIST has some advantages because of long continuity among the project's ranks. Hawkeye7 has been among those leading the project for many, many years and the respect I feel for his experience, competence, dedication and long first-hand knowledge of Wikipedia's history has been earned. I'd rather not speak for other wikiprojects but C-class can be, as Hawkeye7 points out, a useful flag that moderate diligence has been exercised in review and that only comparatively small effort needs be made to get the work to B-class thresholds. The required effort to promote between start and B-class reviews is substantial. BusterD (talk) 19:44, 18 February 2023 (UTC)
At WP:HWY, this means that there are at least all the required sections (Route description, History, and Junction list]], but that they are not necessarily complete or fully sourced. WP:HWY/A. --Rschen7754 19:55, 18 February 2023 (UTC)
I just thought of another potential benefit: with this change, all assessment grades will have clear, specific criteria (except of course Stub). It doesn't just clarify C; it also defines Start-class as any article that fails both B1 and B2, or fails any of B3, B4, B5. DFlhb (talk) 18:34, 19 February 2023 (UTC)
  • Should I turn this into an RFC? Would be nice to get wider community participation ruling on this one way or another, before we switch to project-independent quality assessments. DFlhb (talk) 20:35, 28 February 2023 (UTC)
  • Oppose per WP:BURO. The proposal is incomprehensible jargon because even an experienced editor like myself has no idea what those various B numbers are. And, as Sideswipe9th says, what's the point of these fine distinctions? For example, I attend discussions at WP:ITN/C where article quality is an important consideration for every nomination. Project ratings get no respect there. I have suggested that they be used but most editors use their own assessment based upon the number of citations, the amount of prose and little else. Andrew🐉(talk) 10:28, 4 March 2023 (UTC)
  • IMO, the key point for C-Class is content (B2). Format (B4) and supporting materials (B5) are really immaterial for C-Class. I am glad to pass an article for C-Class if it meets B2 but fails all of B4 and B5 and B6.--Lopullinen 15:44, 5 March 2023 (UTC)
    I'd be fine with defining C-class as either B1 or B2, and dropping the rest, to echo your and Andrew's comments (or dropping the B-jargon and saying "citations" and "coverage" or equivalents. DFlhb (talk) 15:52, 5 March 2023 (UTC)

Request to mass create ISO 3166-2 codes as redirects

Hi all! I'm planning to undertake a task that would involve creating a large number of redirects to point the ISO 3166-2 country subdivision codes to the relevant articles on that country's subdivisions. Unless an page with a title matching a country subdivision code already exists, this process would create a redirect at that title to point the relevant subdivision. Some of these already exist as redirects (e.g. the subdivision codes for Argentina), but that set of redirects is currently incomplete. I realize that I could probably do this manually without issue, but it would take quite a while. I would hope to eventually semi-automate the process of creating these, since creating 5000 redirects and adding tags can be tedious if done manually. For that reason, I am asking for consensus around whether this sort of redirect creation is looked upon favorably by the community before I go ahead with mass creation. — Red-tailed hawk (nest) 16:59, 4 March 2023 (UTC)

Can you provide a few examples? Also, what practical problem would this solve? Sandstein 18:56, 4 March 2023 (UTC)
Sure! This would mean pointing things like UZ-NG to Namangan Region, ZM-05 to Northern Province, Zambia, et cetera. I think that this is a reasonable search term; I've had to type the codes into google to figure out what they've referred to when looking at datasets in the past. We have {{R from ISO 639 code}} for language codes, and the plan would be to do a similar thing for subdivision codes—so long as there isn't any conflict with existing redirects. — Red-tailed hawk (nest) 19:19, 4 March 2023 (UTC)
With respect to the problem it would solve, it would allow users to type in the ISO code in the search bar and then be taken to the article on the corresponding geographic entity. Users currently can't do this. — Red-tailed hawk (nest) 19:21, 4 March 2023 (UTC)
Personally, I prefer to defer to search engines to figure out the best destination for a search term, and not try to make every reasonable search term a redirect. I appreciate, though, that others have different views. isaacl (talk) 23:03, 4 March 2023 (UTC)
I tend to use Wikipedia where possible since it's ad-free and respects users' privacy, hence I'm in favour of creating redirects such as these. Daß Wölf 20:38, 5 March 2023 (UTC)
Sure; I think it's better to improve Wikipedia's search capability, though, without requiring editors to create innumerable redirects. isaacl (talk) 22:06, 5 March 2023 (UTC)
If this does happen, make sure you create a new redirect template (Template:R from ISO 3166-2 code) and use it, along with other relevant redirect templates. Gonnym (talk) 19:30, 4 March 2023 (UTC)
Note that User:PotatoBot (User:Anypodetos) created the ISO 639 redirects (Wikipedia:Bots/Requests for approval/PotatoBot 2) so this isn't a completely new idea. Gonnym (talk) 19:33, 4 March 2023 (UTC)
I would be sure to make a redirect template and tracking category in the case that this gets approved, yes. — Red-tailed hawk (nest) 19:35, 4 March 2023 (UTC)
Looks good to me. EpicPupper (talk) 05:38, 5 March 2023 (UTC)
A very good idea in theory but beware of name clashes. For example, ISO 3166-2:AL tells us that AL-01 is Berat, Albania, but AL-01 currently redirects to Alabama's 1st congressional district. Certes (talk) 18:06, 5 March 2023 (UTC)
As specified above, I wouldn't touch anything with a name clash during a mass creation. I agree that those are best handled manually. — Red-tailed hawk (nest) 18:32, 5 March 2023 (UTC)
I think this is a good idea. It's a well-defined and limited set of redirects, all of which will be plausible search terms (pretty sure I've searched some myself). Where clashes exist, it may even be worth turning those clashes into disambiguation pages, although this will presumably be a manual process. Might be worth including some tracker for codes where the target page doesn't exist, or is itself a redirect, for manual follow up. CMD (talk) 01:14, 6 March 2023 (UTC)
I support this. User:Red-tailed hawk, if you can provide a complete list, I can provide you with a list of the ones that clash with existing redirects, and the ones that clash with existing articles (if any). I agree with CMD that disambiguation pages would likely be appropriate for all clashes with redirects. BilledMammal (talk) 01:41, 6 March 2023 (UTC)
I would be happy to. Do you know of any script that converts a Microsoft Excel document into a Wikitable? I'd be happy to post one here if I can get the formatting fixed. — Red-tailed hawk (nest) 01:51, 6 March 2023 (UTC)
Try copying and pasting the cells into Visual Editor. Otherwise, see Wikipedia:Village pump (technical)/Archive 204 § Excel to Wikipedia tables for a couple of Toolforge tools that will convert tab-separated text into wikitext tables, so you can try copying and pasting the cells into those tools. isaacl (talk) 02:14, 6 March 2023 (UTC)
I'm getting a terrible error when I try to copy-paste into VE. I'll take a look at those tools. Thank you for the pointers! — Red-tailed hawk (nest) 02:16, 6 March 2023 (UTC)
Sorry, I don't. However, I would suggest saving the excel document as a CSV file, opening it in notepad, and copying and pasting the contents - probably to another page. It won't be formatted, but that isn't important. BilledMammal (talk) 02:30, 6 March 2023 (UTC)
Lgtm. Thanks, Hawk. Levivich (talk) 03:14, 6 March 2023 (UTC)

Making templates for votes

ok so i think that vote "options" (idk what's it called in enwiki) such as Support, Oppose, Comment should have a little icon that represents the options. so like  Support ;  Oppose;  Comment and Meh. tynjee 02:58, 4 March 2023 (UTC)

Hey -tynjee. There is a long-established consensus against templates for marking votes, in particular because they encourage voting over discussion. See Wikipedia:Voting templates. — The Earwig (talk) 03:18, 4 March 2023 (UTC)
I will echo what The Earwig says in that there's been longstanding hesitation around making those templates. There already exists a {{comment}} template, and a {{meh}} template (though the current meh template is slightly different from what you're proposing). — Red-tailed hawk (nest) 17:01, 4 March 2023 (UTC)
  • These are in widespread use on other language Wikipedias, so their absence on en.wiki often surprises multilingual editors!—S Marshall T/C 07:12, 5 March 2023 (UTC)
    I wonder if they ever trigger template limits. CMD (talk) 16:01, 5 March 2023 (UTC)
    Yes, and that shows the English Wikipedia is different, which is a good thing. Trying to achieve technical compatibility would merely mask existing social incompatibilities and make things worse. (And I say this despite being active on 3 different multilingual wikis, and an admin on one). * Pppery * it has begun... 17:28, 5 March 2023 (UTC)
    I'm sure you're not proposing to use them on English Wikipedia. Just that something is done on many other Wikipedias doesn't make it right for us. Voting seems to be more common on other Wikipedias too. What I would love is for more editors to discuss things first before coming to a conclusion that can be summed up in one word (or icon), but I seem to be pissing into the wind there. Phil Bridger (talk) 17:42, 5 March 2023 (UTC)
  • Oppose. Wikipedians might find such icons difficult to use. YTKJ (talk) 18:30, 5 March 2023 (UTC)
    I agree with your conclusion, but not with how you got there. What is so difficult about copying and pasting an icon? Phil Bridger (talk) 18:42, 5 March 2023 (UTC)
  • Oppose. There are userscripts that do this automatically (visually only, not actually in source) for those who want it. Just use those - no need to poke the bear. casualdejekyll 17:35, 6 March 2023 (UTC)
Retrieved from "https://wiki.riteme.site/w/index.php?title=Wikipedia:Village_pump_(proposals)/Archive_198&oldid=1240937185"