Wikidata:Project chat

Wikidata project chat

A place to discuss any and all aspects of Wikidata: the project itself, policy and proposals, individual data items, technical issues, etc.

Please use {{Q}} or {{P}} the first time you mention an item or property, respectively.
Other places to find help

• Frequently asked questions
• Requests for deletions
• Requests for new items
• Merging instructions
• Report a technical problem
• Requests for protections, undeletions and other matters requiring administrator attention. To report vandalism, click here.

For realtime chat rooms about Wikidata, see Wikidata:IRC.

Start a new discussion

• Afrikaans
• العربية
• беларуская
• беларуская (тарашкевіца)
• български
• Banjar
• বাংলা
• brezhoneg
• bosanski
• català
• کوردی
• čeština
• словѣньскъ / ⰔⰎⰑⰂⰡⰐⰠⰔⰍⰟ
• dansk
• Deutsch
• Zazaki
• dolnoserbski
• Ελληνικά
• English
• Esperanto
• español
• eesti
• فارسی
• suomi
• føroyskt
• français
• Nordfriisk
• galego
• Alemannisch
• ગુજરાતી
• עברית
• हिन्दी
• hrvatski
• hornjoserbsce
• magyar
• հայերեն
• Bahasa Indonesia
• interlingua
• Ilokano
• íslenska
• italiano
• 日本語
• Jawa
• ქართული
• қазақша
• ಕನ್ನಡ
• 한국어
• kurdî
• Latina
• lietuvių
• latviešu
• Malagasy
• Minangkabau
• македонски
• മലയാളം
• मराठी
• Bahasa Melayu
• Mirandés
• مازِرونی
• Nedersaksies
• नेपाली
• Nederlands
• norsk bokmål
• norsk nynorsk
• occitan
• ଓଡ଼ିଆ
• ਪੰਜਾਬੀ
• polski
• پنجابی
• português
• Runa Simi
• română
• русский
• Scots
• davvisámegiella
• srpskohrvatski / српскохрватски
• සිංහල
• Simple English
• slovenčina
• slovenščina
• shqip
• српски / srpski
• svenska
• ꠍꠤꠟꠐꠤ
• ślůnski
• தமிழ்
• తెలుగు
• ไทย
• Tagalog
• Türkçe
• українська
• اردو
• oʻzbekcha / ўзбекча
• Tiếng Việt
• Yorùbá
• 中文

Edit

On this page, old discussions are archived after 7 days. An overview of all archives can be found at this page's archive index. The current archive is located at 2026/10.

On this page all sections tagged with {{Section resolved|1=~~~~}} after 1 day and sections whose oldest comment is older than 7 days are automatically archived.

Announcing a new tool: Mergers & Acquisitions, a web app for finding and merging duplicate Wikidata items

Hello all! I've been a Wikidata editor for almost a decade and have always wanted a good tool for finding duplicate items. Since nothing existed and as an early birthday present for Wikidata, I've been building it for the last few weeks.

It matches based on a variety of heuristics (same external IDs, same release/creation date, same/similar name, alias matching the label of the other item, no "different from" statement, etc.) and ranks them based on those patterns. I've been tweaking it based on feedback and adding more functionality to it, and I think it's now very useful. It's not perfect (partially because our data isn't perfect!), but hopefully you'll find it useful as well.

You can use it on Toolforge here, it's called M&A: A Wikidata Merge Assistant.

Main features:

• Matches have been discovered for you, your job is to evaluate whether they should be merged or not.
• Detailed display of item statements for every pair so you can quickly compare potential duplicates against one another.
• Merging items.
  • When merging items, the app automatically handles redirecting the item and removing any already-redirected sitelinks for you.
  • It will force you to make manual changes if it can't handle everything automatically for you, I'll try to improve this in some cases but I want to make sure the edits are always safe!
• You can add different from (P1889) if the pair of items is distinct.
• You can "dismiss" a pair, and the app won't bring it back again in the future. This is mainly intended for items where it doesn't necessarily make sense for it to marked with P1889, but it also shouldn't be merged together.
• Various filters:
  • by item type or WikiProject (e.g. video games, music, film/tv, anime/manga, companies, comics, etc).
  • by the user which created either side of the pair, if you want to look for your own dupes.
  • by the languages available for the item labels, so you can filter out items you can't evaluate effectively because you don't speak that other language.
• Desktop and mobile support, so you can use it from your phone if you prefer.
• Leaderboard, for bragging rights :P
• Automatically refreshes with data from Wikidata dumps every Wednesday, and automatically finds any new dupes.
• Fast load times, I've tried to optimize things whenever I've noticed any slowdown and so far it seems to be working pretty well.

Only some types of items (around 2 million items total right now) are available to match, but I intend to increase the coverage further over the next few weeks. I wanted to keep it scoped to start with so I could tweak things without needing to run hours-long imports whenever I changed the logic.

Please tell me if you have any feedback or suggestions! If you find anything where the app made an obvious mistake with a duplicate candidate, definitely send it to me!

Thanks, and sorry for the wall of text :P I hope it's helpful to other editors! Nicereddy (talk) 01:07, 27 September 2026 (UTC)

Looks a very good tool. I suggest you display both label and description on the initial page, as often its the latter that makes the situation clear, and allow the flipping of the merge order by tapping on the arrow. Obvious areas of expansion are ships, buildings and places, and properties initial date (start, inception, publication, launch date etc) and coodinates within a mile. Vicarage (talk) 05:17, 27 September 2026 (UTC)

Also, I'm not sure you have your session data separated, I clicked on "Back to candidates" and got filters I'd not set up. Vicarage (talk) 06:27, 27 September 2026 (UTC)

Hmm, are you certain? I'll investigate to make sure, but the filters are stored entirely in the user's browser and never stored in any way in the database. They're persisted across reloads/page changes, which might be why you saw that behavior, but they definitely shouldn't be having any sort of session state issue. Regardless, I'll double-check. Nicereddy (talk) 13:12, 27 September 2026 (UTC)

This looks like a great project.

I do agree with Vicarage, that you do want to show the property labels instead of having P-numbers on the initial page.

Currently, you label English (Q1860) and American English (Q7976) as distinct. Given that there's a subclass relationship (2-level deep) that should probably go under "similar" not "distinct".

Given that you do provide the option to mark them as different from (P1889) I think it would be good if you offer the user to specify criterion used (P1013). ChristianKl ❪✉❫ 10:16, 27 September 2026 (UTC)

I'll update the P-numbers to show names on the list view and I'll see about adding a picker for criterion used (P1013). I'm not sure how best to handle the sub-class relationships without needing to store the entire subclass structure of everything on Wikidata, which might slow things down considerably / require a much larger database. I could just hardcode a few common subclasses, but that feels like cheating. I'll think on it some more. Thanks for the feedback! Nicereddy (talk) 13:19, 27 September 2026 (UTC)

I've added the criterion used (P1013) selector with a few common options, and also updated the list view to display Property names instead of just PIDs, that you and Vicarage suggested. Nicereddy (talk) 13:42, 27 September 2026 (UTC)

When it comes to subclass relationships a merged item where both have unreferenced statements where one is English (Q1860) and the other is different from (P1889) also doesn't need the English (Q1860) claim, so it's not just UI.

Intuitively, maybe it can be okay to have them distinct for the initial scoring but then when the user loads the page for a given match make the queries live? ChristianKl ❪✉❫ 07:36, 28 September 2026 (UTC)

Why not allow users to write a custom SPARQL query to get a pool of items to work on? Vicarage (talk) 10:52, 1 October 2026 (UTC)

I guess I could consider that, but at least right now we only have a chunk of Wikidata's database in the app. So you'd be limited in how much you can actually filter down to. Do you have anything specific you wanted to filter by? Nicereddy (talk) 22:42, 1 October 2026 (UTC)

I would want to filter by anatomic structure. ChristianKl ❪✉❫ 12:23, 2 October 2026 (UTC)

I have little desire to fix all the books in WD (for one thing, lots of the titles are in other languages, and I have no competence there), but would want to fix say the military history books, but that would require me providing a query for the subset. Other than the WD gamification people, I suspect many would want to work on an area of interest. Vicarage (talk) 12:56, 2 October 2026 (UTC)

Tool should look, if there is some connection - when one item links to other, possibility of duplicate is lower. [1] JAn Dudík (talk) 19:16, 6 October 2026 (UTC)

Spiritual Canticle

Spiritual Canticle (Q3071431) is a book length commentary on the poem with the same title, by John of the Cross (Q190388). Spiritual Canticle (Q23894939) is the poem by the same author. The articles in French Wikipedia are fr:Le Cantique spirituel (livre) and fr:Le Cantique spirituel. How should the two be linked?

I found these using Nicereddy's tool. TSventon (talk) 13:09, 27 September 2026 (UTC)

Looks like a pretty straightforward use case for main subject (P921) to me... Circeus (talk) 22:24, 28 September 2026 (UTC)

And, conversely, described by source (P1343). Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 12:04, 5 October 2026 (UTC)

Thank you both, I think that would work. TSventon (talk) 15:24, 10 October 2026 (UTC)

Should Fagus sylvatica 'Atropunicea' (Q110765786) be merged with Fagus sylvatica f. purpurea (Q886511)?

Fagus sylvatica f. purpurea (Q886511) has name of Fagus sylvatica 'Atropunicea' (Q110765786) as alt name, but these two taxons have different commons categories, so i'm not sure if they're describing the same tree type or not VlaDexa (talk) 23:00, 3 October 2026 (UTC)

@VlaDexa: I would suggest asking whether the Commons categories should be merged first.

@MILEPRI:, I see that you created c:Category:Fagus 'Atropunicea' in 2017, do you know if and how Fagus sylvatica f. purpurea and Fagus sylvatica ‘Atropunicea’ are different? Or where to ask?

I looked online and Missouri Botanical Garden, https://plantfinder.mobot.org/PlantFinderDetails.aspx?taxonid=265856 , says they are "basically synonyms". TSventon (talk) 02:23, 4 October 2026 (UTC)

In general, I think Wikidata:WikiProject Taxonomy can be helpful. Ainali (talk) 07:50, 4 October 2026 (UTC)

While waiting on this getting answered, I've found taxon synonym of (P12763) and taxon synonym (P1420) and marked these items accordingly VlaDexa (talk) 22:37, 11 October 2026 (UTC)

Merging Shtokavian lexemes

Because I am not trying to give any credence to maintaining a split of lexemes based on some notion of standardized varieties, I will only indirectly refer to those varieties in terms of where they are used or who uses them.

There are currently a significant number of lexemes whose stated language is a separate standardized variety of a particular South Slavic dialect, either that used in Zagreb or that used in Belgrade and Banja Luka. (There aren't as many lexemes marked with the varieties used in West Sarajevo or in Podgorica, but those are also of concern here.) These are causing unnecessary, almost verbatim duplication of much semantic and morphological information, which will only increase as more lexemes so explicitly tied to those varieties are added.

I believe that three decades on from the brutal, senseless conflicts that have engulfed speakers of these standardized varieties, and nearly a decade on from the Declaration on the Common Language (Q29018604), there should be work at least in Wikidata lexemes to use the same lexical items for documenting terms used in these standardized varieties, with any actual distinctions in use or form based on ethnoreligious group or locale indicated just in those places where they are absolutely necessary. Once a merger is allowed to begin, I would be willing to make the initial necessary lexeme adjustments, for which an external property I proposed could assist in providing sourcing.

As prior art for such a merger, I note the following about other (Indo-European, admittedly) languages with a substantial portion of lexemes already:

• New Persian (Q56356571) (Persian, Dari, Tajik) uses a single set of lexemes with multiple scripts in lemmata and forms, with indications such as language style (P6191) and location of sense usage (P6084) on their forms and senses as to the applicability of words in a given language community (in places where e.g. etymological origin in Arabic or Russian may not suffice to determine that applicability). The morphological distinctions internal to words between these varieties are not nearly significant enough, or difficult enough to handle, to warrant a split in this case.
• Hindustani (Q11051) (Hindi, Urdu), as well as Punjabi (Q58635), Sindhi (Q33997), Kashmiri (Q33552), and other languages with communities split by the Radcliffe Line (Q1419358) and Line of Control (Q1366583), are set up similarly to New Persian (although with etymological origins in Perso-Arabic and Sanskrit instead), with the same relative lack of significance/difficulty in morphological distinctions.
• Words and phrases in languages like English (Q1860), French (Q150), or Spanish (Q1321) are not split into completely different lexemes depending on whether they are used in, for example, Canada ("Canadian French"), the United States ("American English"), or Mexico ("Mexican Spanish"); the language is simply marked as one of the three general language items, and any location distinctions on senses and forms are indicated using the same properties used with New Persian or the South Asian languages. (The same note on morphological distinctions from the previous two bullet points applies here.)

(@Aca, Denny, Dungodung, Ivi104, Janjko, Vipz: as individuals whose (counter)arguments might be interesting to read.) Mahir256 (talk) 20:49, 4 October 2026 (UTC)

This makes sense to me - I'd always heard of the language as "Serbo-Croatian" (I had an aunt from Croatia), but it sounds like Shtokavian is the more ethnicity-neutral label for it. Wikidata lexemes are designed to be somewhat higher-level than "words" - we include all forms, and differing scripts is not a problem. So this seems a sensible approach that fits in with how lexemes work here. ArthurPSmith (talk) 19:44, 5 October 2026 (UTC)

15 years ago I would have, without hesitation, answered that a single set is sufficient and the right thing. Now I have a much weaker opinion, and in addition I wonder if I am at all the right person to weigh in on this or offer an opinion. I would like to hear from native speakers of these variants / languages who are actively living in that language area, instead of a diaspora member who has never lived in it. As far as my opinion is concerned, I would say that the longer the separation goes, the more the variants seem to be like languages, with an increasing difference in the lexicon.

What about having both the individual variants / languages, *and* the common language? For the common lexemes the common language, and for the ones that are not, use the specific language? I don't know. Again, I am probably the wrong person to ask. --Denny (talk) 15:10, 6 October 2026 (UTC)

I wouldn't say that's the case, because due to common cyberspace shared by the speakers (ie., exposure to each other's music, movies, sports broadcasts, and internet culture), the varieties seem to stay very similar, and any proscriptive norms fail to materialize if they are significantly different (see Montenegrin ź and ś, for example, where no media outlets in Montenegro actually uses them). – Aca (talk) 18:21, 6 October 2026 (UTC)

Thank you for including me in this discussion.

Since this is a lexical project, I'd imagine we would wish to capture the variety of all those languages instead of putting them all under the same umbrella, as is usually done. Unlike your usual language varieties, these languages all have official standardizing bodies that publish official grammars and dictionaries. American English or Canadian French do not have independent standardization bodies that legally define and regulate their respective languages. These languages do, Institute for Serbian Language, Matica hrvatska, or the Language Institute of Sarajevo, to list a few.

There is a great deal of nuance within these languages and their dialects that would be difficult to convey in a merger. Let's take the word "carrot" as an example. Croatian speakers use use exclusively "mrkva" in standard štokavian, Serbian use exclusively "šargarepa". As a Croatian speaker, I had to look up the meaning of šargarepa the first time I heard it. The Croatian word for "one's own" is strictly "vlastiti", while Serbian can use "vlastiti" and "sopstveni" where each have distinct semantic nuances, so "sopstvena težina" means dead weight of an object, but "vlastita težina" to a speaker of Serbian sounds unnatural in that sense.

Administrative terms also carry similar nuance, In Croatian, a legal association translates as "udruga", in Serbian "udruženje". In Croatian, "udruženje" carries a different semantical meaning, as a verbnoun (gerund) for "udružiti", to join together, to merge, to organize, but no administrative context is conveyed.

There is also the issue of writing. To cook is ("kuhati") in Croatian, ("kuvati" or "кувати") in Serbian and ("kuhati" or "кухати") in Bosnian. A form denoting past simple, genderized, would then have 2 variants (one for each gender) x2 (one for each language) x2 (one for each alphabet). Croatian uses 2 of 8, Serbian uses 4, Bosnian uses 4. I am not personally all to familiar with Montenegrin, but I am aware they use the jat reflex somewhat differently than Croatian, Bosnian and Serbian which would lead to even more issues.

Dividing these languages into dialects is itself somewhat problematic. Chakavian exists only in Croatian, while Kajkavian is partly shared by Croatian and Slovenian, a language which is not typically included when discussing "the hbs pluricentric language". If you ask a random stranger on the street "which language do you speak?", I guarantee you will get NO respondees to say Shtokavian (nor Serbo-Croatian, for that matter).

For these reasons, I am  strongly opposed to this proposal. Kind regards, — Ivi104 (talk) 17:15, 6 October 2026 (UTC)

 Strong support – The Serbo-Croatian (also referred to as BCMS) language is a pluricentric language (just like English, German, etc.), meaning it has several officially codified standard forms. Despite this, these standards are almost completely mutually intelligible (more information on this), so there is not any linguistic reason to spend resources on four almost identical standard varieties plus a common Serbo-Croatian label. A while ago, the English Wiktionary, a lexical project too, merged all standard varieties into a unified Serbo-Croatian label, so when we talk about lexemes, there are no solid grounds for having multiple standards. Separate Wikipedia editions exist just because the current Language policy of the Language Committee wasn't adopted before these editions were created. For "vlastiti" and "sopstveni", as a speaker of the Serbian language, I don't find a difference between these two, and our dictionary by Matica srpska says that they are completely interchangeable. Everyone has the right to call their language whatever they want (in the Balkans, we often say "ours" or "our language"), but the scientific linguistics (and not national linguistics) is something we should rely on when we contribute to the Wikimedia projects. – Aca (talk) 18:08, 6 October 2026 (UTC)

There is no BCMS language, this is a linguistic broadstroke used used for classification purposes only. Living speakers make the living language. Not history books, not academics on other continents. I've outlined the problems with merging lexical descriptions above, very clearly and in no uncertain terms. Further, Croatian is mutually intelligible with Slovak, should they be merged too? What about Ukranian and Russian? Swedish and Danish? All mutually intelligible, all share a corpus of words, certainly many lexemes are identical or similar enough to warrant this type of discussion as well, hm? No, because the languages have a different structural identity, as do ours. The phonological core of our languages relies on the jat reflex. It is a fundamental, historical phonological divergence that alters the root vowel structure of thousands of words. British and American English do not have competing, codified standards that systematically alter the internal root vowels of their entire vocabularies.

You argue that because vlastiti and sopstveni are interchangeable in Serbian, they must be interchangeable across the entire language area. This is entirely false. Our languages have cases of asymmetry, which I have clearly outlined above: Croatian does not use sopstveni, ever. It does not exist as a passive variant, a synonym, or an archaism; it is completely foreign to the modern lexicon. Any linguistic system that forces these two words into a single Serbo-Croatian or Shtokavian or whatever-you-wanna-call-it lexical unit actively falsifies the lexical reality of the language. A pluricentric model cannot override the fact that a word can have a zero-frequency status in one standard while being common in another.

To further build on what you have said, mutual intelligibility does not mean the words are linguistically identical. The "standard varieties" have highly systematic, divergent rules for how words are structurally built from roots:

• Croatian standard strictly preserves the infinitive construction ("Želim ići", "Moram kuhati").
• Serbian standard systematically prefers the da + present construction ("Želim da idem", "Moram da kuvam").

How each language incorporates foreign words is another example of relevance:

• Croatian integrates foreign verbs using the -irati suffix (organizirati, identificirati).
• Serbian systematically prefers the -ovati or -isati suffixes (organizovati, identifikovati).

These are codified, divergent morphological rules taught in schools and enforced by structural syntax.

"Scientific linguistics" does not dictate that mutually intelligible varieties must be compressed into a single lexical entry. True descriptive linguistics recognizes that when standard languages possess independent standardizing bodies, divergent morphological suffixes, system-wide phonological splits (ekavian/ijekavian), and entirely separate alphabets, they constitute distinct lexical systems. To merge them is to erase real, documented linguistic diversity in the name of an oversimplified model. As stewards of knowledge, I believe this flies in the face of what we are supposed to be doing here. Cherish the beauty of your own language, @Aca:! Ivi104 (talk) 19:04, 6 October 2026 (UTC)

No, Croatian is not mutually intelligible with Slovak, and neither are Ukrainian and Russian. Serbo-Croatian has the identical structural identity in all its variants, with the same grammatical cases and tenses. You say it is completely foreign to the modern lexicon – yes, and that's the case with many other policentric languages. Word frequency can depend on the standard variant. As for the structural reference, it's simply wrong, as many Serbian linguists actually recommend the infinitive construction (see Srpski jezički priručnik). For the sufixes, the situation is more complex than you have presented. The Serbian language actually got a lot of "-irati" verbs in the modern times, as that suffix is more fertile. All suffixes are linguistically accepted in Serbian tho. So no, most of these claims have no basis in the standard language or scientific linguistics. – Aca (talk) 20:39, 6 October 2026 (UTC)

Yes, they are. Slovak is an 80% match for Croatian, and the closest of the West Slavic languages.^ref Vast majority of Ukrainians can understand Russian with near 100% fluency. I do not know if you realize the flaw in your argument: you are attempting to use the structural fluidity of the Serbian standard to dictate the structural boundaries of the others. As I've previously explained, that doesn't work, the languages are asymmetrical. You state "Word frequency can depend on the standard variant". No. A word like "sopstveni" does not have a "low frequency" in Croatian; it has zero frequency. It is grammatically and lexically illegal in standard Croatian. In true polycentric languages like English, a British word like autumn is understood and holds a non-zero passive frequency in American English. "Sopstveni" is entirely absent from any officially recognized dictionary of Croatian and no Croatian speaker ever uses it. Your structural reference counter-argument fails similarly: the Serbian standard allows for both, but "da + present" construction is syntactically fully integrated and preferred in everyday standard speech. In Croatian, replacing the infinitive with da + present is considered a severe syntactic error in official, educational and literary use. One standard enforces a strict syntactic constraint, the other does not. Your third counter, same issue: Serbian accepts -irati verbs, Croatian strictly rejects -ovati and -isati verbs. You are supporting a model where one language's boundaries are completely porous while the other's are strictly rigid. Merging them forces the rigid system to inherit forms it explicitly rejects.

You completely ignored my "jat reflex" point, allow me to make it stand out via "blindness": ekavian slepoća vs. ijekavian sljepoća. This is a structural mutation of the root itself, altering the consonant clusters (sl vs slj). In standard polycentric languages, regional variations do not systematically mutate the root consonants and vowels of thousands of words across codified literary standards. If we take this one step further, the declension rules and form generation do not behave the same across these languages: Serbian "planeta" (feminine noun, declines like žena, ends in -a), Croatian "planet" (masculine noun, declines like prozor, ends in a consonant). Plenty of other examples, quality (kvalitet - kvaliteta), secretion (sekret - sekrecija). Wikidata's own Lexeme architecture does not support this. Ivi104 (talk) 23:43, 6 October 2026 (UTC)

@Ivi104 It is possible to model lexemes which differ in gender among different speakers, for example see मसकारा/مسکارا (L1171963) and मसकारा/مسکارا (L1171964) where the loaned word "mascara" is feminine in the Urdu of Gilgit-Baltistan. (Granted, Hindi/Urdu is not pluricentric in a similar way to Serbo-Croatian, as Pakistan considers it to be one language while India has officialized it as two separate ones. There are also no differences at all in the spoken language, unlike even American and British English it is generally not possible to call someone an Urdu speaker or Hindi speaker depending on how they speak. Most of the differences within the standard language have arisen as a result of adoption by non-native speakers.) عُثمان (talk) 01:10, 7 October 2026 (UTC)

 Oppose Maybe some of you should first impose merging of the Scots language lexemes into English ("Given that there are no universally accepted criteria for distinguishing a language from a dialect, scholars and other interested parties often disagree about whether Scots is a dialect of English or a separate language."): Lexeme:L1459992, Lexeme:L1453684. Or merging Bokmål and Nyorsk as two orthographies/variants of the Norwegian language? Maybe you can take some advice from a linguistics expert in BCMS: "These forms of speech have often been termed a language, but they are also seen as separate languages: Serbian, Croatian, and in recent years also Bosnian and Montenegrin. Neither view is completely right or wrong; the concept language has multiple definitions, and the status of BCMS will depend on the definition one adopts." (Claiming one way or another is always going to be seen as POV) Or you could develop a system where the shared lexemes are marked as such, but only if they are the same in all forms. ~2026-53836-22 (talk) 19:02, 6 October 2026 (UTC)

 Strong oppose, because we are not discussing about local versions of language, but languages that each have their own institutions, classifications, and dictionaries. As user:Ivi104 already mentioned, these languages have distinct histories, traditions, and standardization processes, and they function as separate languages rather than just variants. For example, does "Shtokavian" even have an ISO code? Renaming "Serbo-Croatian" to the name of a dialect (= Shtokavian, and even comparing it to German, English etc.) seems to be an attempt to make the term sound more politically correct, while in practice, literally nobody refers to their own spoken language as "Shtokavian", and this should not be based on personal opinions. Is there even a "Shtokavian dictionary"? There isn't! Croatian and Serbian also have thousands of words that are not mutually understood, especially by younger speakers, along with differences in phonology and morphology. Croatian tends toward Slavic purism, while Serbian and Bosnian more frequently adopt Latin-based internationalisms. --Koreanovsky (talk) 19:19, 6 October 2026 (UTC)

I have а reason to express a concern that some editors might have been canvassed to this discussion. – Aca (talk) 20:24, 6 October 2026 (UTC)

Canvassing is against the rules, so this is a very serious accusation. Whose comments do you find are not written with the intent to improve the quality of the discussion by broadening participation to more fully achieve consensus, and what reason can you give? Ivi104 (talk) 20:58, 6 October 2026 (UTC)

@Ivi104: An assortment of replies to things you have mentioned above:

• As a general initial note, I am somewhat disappointed that you did not engage with the examples of Persian and the South Asian languages in any part of your replies. Persian in particular has useful parallels to the situations you bring up (perhaps @عُثمان: can add more parallels from the South Asian languages). I am also disappointed in a large number of absolutist assertions you have made about various things without providing references to support them (with one exception after the words "closest of the West Slavic languages"), including to say "Wikidata's own Lexeme architecture does not support this" about any of the issues you have raised.
• American English or Canadian French do not... French has its Académie Française (Q161806) in France and the Office québécois de la langue française (Q2578454) in Quebec, which have some levels of authority in those regions; while English does not have such official bodies, you will have a difficult time suggesting that the Australian rely on Merriam-Webster (Q585329) for language decisions and the American rely on the Macquarie Dictionary (Q6113225) (or a New Zealander the The American Heritage Dictionary of the English Language (Q464886)), so those resources can be said to have a standardizing force in their countries of origin. (Additionally Spanish has its Royal Spanish Academy (Q11993457) in Spain and its affiliates in other countries through the Association of Academies of the Spanish Language (Q607959).)
• "mrkva" ... "šargarepa" This is solved by adding the statement location of sense usage (P6084) Q224 on the sense(s) of the first word and location of sense usage (P6084) Q403 on the sense(s) of the second. Compare Persian words for "telephone" as used in Iran, Afghanistan, and Tajikistan, which are annotated similarly.
• "vlastiti" ... "sopstveni" location of sense usage (P6084) is not limited to having just one value; compare Persian words for autumn used in Iran and Afghanistan and in Tajikistan.
• "udruga" ... "udruženje" These would of course be different lexemes with their own senses; the derivation from a verb could be indicated using derived from lexeme (P5191) (compare the Persian noun "request/petition" derived from a similar verb, and "a throw" from a related verb); field of usage (P9488) on the senses of these words can make their use in administrative contexts clear.
• "kuhati" ... "kuvati" This sounds like a situation in which two lexemes with senses/forms annotated with location of sense usage (P6084) would be appropriate; no need to put these in the same lexeme. Compare Persian verbs for "to throw" which differ in whether a velar stop in its stem is unvoiced or voiced; or for "to stand" which differ in whether the initial vowel is emphasized or not emphasized in the Arabic script; or for "to fill" where the first consonant has three possible realizations of place/manner of articulation.
• "Chakavian" ... "Kajkavian" Note that I did not bring either of these up in my original message, as I understand those to not be the primary foundation of any of the standardized varieties under consideration; as far as I am aware, lexemes which are different in those two compared to Shtokavian are better left as referring to those varieties. At no point did I suggest using Q9301 as a possible unified language item in my original message, either; compare Persian lexemes which use a different language item, noted in my initial message, from Q9168, since this latter item would have unnecessary connotations of primary use in a particular country.
• "ijekavian" ... "ekavian" Unlike the previous bullet point, this distinction does fall under the scope of my original message, and in this case I would point to the Persian verbs in the bullet point above that (given their differences in stems), as well as how Bokmål and Nynorsk lexemes are nearly always split (though keeping the same language item!) when there is a stem difference affecting the entire paradigm (just one of many examples: Bokmål "home" with a semivowel versus with a diphthong). "Planet" vs "planeta" could similarly be kept as separate lexemes with the same language item (just with differing location of sense usage (P6084) values, as noted previously).
• "da + present" ... infinitive This is not a distinction that has to live in lexicographical data; if both the present and infinitive forms exist on a lexeme, then a function (like would be written and used on @Denny:'s Wikifunctions project) can choose the right form to use in a particular situation based on a particular preference.
• -irati ... -ovati and -isati Some combination of location of sense usage (P6084) and language style (P6191) on the senses of these verbs may well be enough to indicate their admissibility in a particular standard variety.
• British and American English do not have...of their entire vocabularies. If you have not been exposed to many major varieties of English, you perhaps may not notice that vowels differ systematically in words across varieties all the time (analysis in terms of diaphonemes and lexical sets helps a lot to get them understood here!). With some exceptions in George Bernard Shaw and early LDS settlers, attempts have not been made as much in English to spell things systematically distinctly to indicate cross-variety vowel distinctions.
• Whose comments do you find...what reason can you give? Koreanovsky is not someone I thought to ping with respect to this discussion; they have not edited lexemes at all, they had made precisely two edits on Wikidata in the preceding two months, and before that seemed almost exclusively to make sitelink changes on hrwiki. That they should come to this specific discussion after such inactivity to register an oppose vote is genuinely strange to me as well, and I applaud @Aca: for calling it out.

Mahir256 (talk) 05:22, 12 October 2026 (UTC)

The aforementioned method of annotating different lexemes is something I would support, as it is in line with the English Wiktionary's lexicographic practices. – Aca (talk) 10:00, 12 October 2026 (UTC)

Labels for sitelink languages

When you hover over the short-form sitelink identifiers (like en), the full name appears in a tooltip (like English). This is broken for uk, which displays українська instead of an English-language label. TE(æ)A,ea. (talk) 14:13, 5 October 2026 (UTC)

Because uk is Ukrainian (українська), not British English... Amitie 10g (talk) 02:25, 8 October 2026 (UTC)

Wikidata weekly summary #752

Here's your quick overview of what has been happening around Wikidata in the
week leading up to 2026-10-05. Missed the previous one? See issue #751.

Discussions

• New requests for permissions/Bot:
  • SaadBot - Task/s: A read-only (no edits) entity lookups for an academic research project building a relation triplet extraction (RTE) dataset from web text.
  • OKA bot - Tasks: Improve Wikidata items using authoritative open datasets, e.g., national mapping data and reference works: add sources, fill gaps, create missing items and report conflicts from the Swisstopo dataset and its subsets.
  • FoxfindingBot - Task/s: Passively enrich existing Wikidata games with gog.com metadata
  • Wahl.de Bot - Task/s: Keep mandate data of German parliamentary members current. Edits to end date (P582), successor/replaced by (P1366), start time (P580), parliamentary term (P2937)retrieved and sourced from official sources.
• New request for comments: Wikidata:Requests for comment/Split needed from Q4167836: Split Wikimedia category (Q4167836) into two items, because one is for MediaWiki non-main namespace (Q35252665) and the other is for Wikimedia project page (Q14204246)

Events

• Upcoming events:
  • On October 9 ends up the early-bird registration with its reduced fees for MediaWiki Users and Developers Conference Fall 2026, November 11-13, at Jožef Stefan Institute (Q5918873). The program is already set up!
  • Wikidata's 14th birthday (Q139103554) in Taiwan: Wikidata Cross-Domain Forum 2026, 24 Oct 2026.
  • (Deutsch) Wikidata Writing Workshop, takes place Saturday, 31 October, 10:00 to 13:00 CEST at the Aargauer Kantonsbibliothek, Obere Vorstadt 6, 5000 Aarau.

Press, articles, blog posts, videos

• Blogs:
  • (Deutsch) Domus – an open data project on the history of houses - Wikidata and FactGrid Wikibase combine to help build a map visualiser.
  • WikiNusantara 2026: a second chance in Makassar
  • N-RICH: a new Wikimedia Project to explore Wikidata as a connective layer for UK cultural heritage infrastructure
• Videos:
  • (Short) Schomburg Center’s 2026 Wikidata Edit-a-thon during the New York Black and African Literature Festival
  • RLUK DSF | Linked data and the research library - explores how libraries are engaging with linked data (including Wikidata) and what this means for metadata creation, management, and discovery.
  • Wikidata 14th Birthday Celebration stream with Africa Wiki Women.
  • AI BRIDGES Open Forum meeting, the September 2026 meeting, showcasing updates from the DARIAH’s DHWiki working group on Wikibase.
  • Exploring networks of artists and scientists with the Wikidata Query Service.
  • (Spanish) What does Wikidata contribute to open library data? with Elena Sánchez Nogales.
• LD4 Conference streams:
  • Sessions 1 / Building more complete and linked GLAM datasets: The Smithsonian’s (In)Visible Women’s Project
  • Sessions 2, incl.
    • EMCO: Entity management for everyone
    • Using Wikidata to identify duplicates in the Library of Congress Name Authority File (LCNAF)
    • From Wikidata to Our Collection Management System: Automating GIS Import for Cultural Heritage Data
  • Sessions 4 including Finding where to contribute on Wikidata with Dustpan and Broomstick. Wikidata is mentioned throughout the stream.
  • Sessions 5 / Reduced Fuzziness in Semantic Kompakkt 3D Object Viewer through Extensive Data Modelling in Wikibase
  • Sessions 9 / Using Wikidata to Improve the Visibility of African Women in Open Knowledge
  • Sessions 10 / From Sounds to Solidarity: Jazz, Student Protests, and Wikidata
  • Wikidata Affinity Group: Working with Corporate Bodies for EMCO

Tool of the week

• Mergers & Acquisitions: A Wikidata Merge Assistant, a new web app that surfaces possible duplicate items from Wikidata and provides a simple interface for evaluating the candidate pairs and merging them together or marking them as different.

Newest properties and property proposals to review

• Newest properties:
  • General datatypes:
    • disjoint with (instances of this type cannot be simultaneously instances of that type)
    • ‎contribution URL (URL of a page explaining how to participate in or contribute to a project or organization)
    • atomic radius (measured or calculated radius of an atom of a chemical element)
    • covalent radius (radius of an atom of a chemical element when covalently bonded)
    • Van der Waals radius (radius of an imaginary hard sphere representing the distance of closest approach for a non-bonded atom)
  • External identifiers: Tric Trac game ID, Techniques de l'Ingénieur author ID, Stereo Ve Mono release ID, ‎Sky programme ID, ‎Sky series ID, Scent Base perfumes ID, ‎Register of British Slave Traders person ID, ‎Onderwijstermen Taalunie ID, ‎NZPCN legacy ID, Biopsa ID, ‎Writers at Risk database ID, LEO-BW person (GND) ID, Leipziger Biographie ID, Jersey HER Reference, Isle of Man Registered Building No., ‎Holy See cardinal biography ID, ‎Google Search profile handle, Filmbaze people ID, ‎China Railway Pinyin code, belarusenc.by ID, ‎BLL-Ontology concept ID, ‎IFWiki article, Brussels ‎Inventory of Movable Heritage designer ID, Eldoblatge original actor ID, Eldoblatge original dub actor ID, Drag France directory ID, OrthodoxWiki ID (French), Le Maitron author ID, ‎Brussels Inventory of Architectural Heritage glossary ID, ‎Brussels Inventory of Movable Heritage material ID, ‎Brussels Inventory of Movable Heritage object type ID, ‎Brussels Inventory of Movable Heritage technique ID, ‎Brussels Inventory of Natural Heritage taxon ID, ‎WE League manager ID, ‎WE League player ID, ‎ArchaMap ID, Womens German Basketball Bundesliga Player ID
• New property proposals to review:
  • General datatypes:
    • has language or spelling variant (the (multilingual) label of the linked item is a a language, spelling or etymological variation of the label of this item)
    • school of martial arts (school or style of martial arts this person studied)
  • External identifiers: YouSaid person ID, Demko ID, Niconico Pedia article ID, Scholastica scholar ID, Hannah Arendt edition person ID, AbeBooks author ID (2), Identifiant dans Calames, identifiant d'un(e) auteurice dans le catalogue du Centre Delavouët

You can comment on all open property proposals!

Did you know?

• Schema examples: ICH item(E379) - schema for a Unesco Intangible Cultural Heritage item in the international lists or national inventories.
• Newest WikiProjects: EastEnders (TV series) - a project for the BBC soap opera.
• Newest database reports: The EntitySchema Directory

Development

• REST API: Continuing the work on adding support for lexicographical data, specifically creating a statement, Form and Sense on a Lexeme
• Wikidata integration in the Wikimedia projects: We are continuing to look into raising the entity usage limit. We are setting up monitoring to see how much it can reduce the amount of Recent Changes entries triggered from Wikidata.
• Mobile editing of statements: We continued addressing the remaining UX issues, including RTL and Kartographer issues
• hCaptcha: We are planning the support for it to Wikibase-specific pages like Special:New Item

You can see all open tickets related to Wikidata here. If you want to help, you can also have a look at the tasks needing a volunteer.

Weekly Tasks

• Add labels, in your own language(s), for the new properties listed above.
• Contribute to the showcase Item and Lexeme above.
• Govdirectory weekly focus country: Tanzania
• Summarize your WikiProject's ongoing activities in one or two sentences.
• Help translate or proofread the interface and documentation pages, in your own language!
• Help merge identical items across Wikimedia projects.
• Help write the next summary!

· Previous issue · Full report · Unsubscribe . JosefAnthony talk ·MediaWiki message delivery (talk) 15:57, 5 October 2026 (UTC)

OpenAI hacking Wikimedia projects

Ars Technica reports that OpenAI agents tried to hack Wikipedia tools and flooded it with traffic. Apart from following the Wikimedia lead on hardening their servers, does WD have special vunerabilities in this area, given the specialist wikibase software, the fragility of Blazegraph, and the common practice of bot and QuickStatments running large number of updates. I'm conscious that WD has many fewer editors than ENWP, and many more items to patrol, and is vulnerable to different sorts of manipulation. Vicarage (talk) 13:42, 6 October 2026 (UTC)

See also the blog post from Wikimedia Foundation. Ainali (talk) 14:03, 6 October 2026 (UTC)

That mentions Wikidata. "Agents we believe to be operated by OpenAI made millions of automated requests to our public APIs to access the knowledge on Wikimedia projects, crawled millions of pages (mainly from our projects Wikidata and Wikimedia Commons), and made hundreds of thousands of data queries to the Wikidata Query Service (WDQS). This traffic may have contributed to a partial outage on WDQS in May." Secretlondon (talk) 17:29, 6 October 2026 (UTC)

Didn't the Wikimedia Foundation provide a paid API to be used by companies that want more data access? OpenAI should pay for it. It makes sense for them to query Wikidata for data but they can pay for it. ChristianKl ❪✉❫ 23:55, 6 October 2026 (UTC)

Yes, and also other methods suitable for AI consumption it seems: Wikidata:Data_access. WDQS is more susceptible to abuse by being a public endpoint. It can't really defend against things like amplification. Infrastruktur (talk) 11:34, 7 October 2026 (UTC)

@Infrastruktur Even when it can't defend directly, telling OpenAI that they are expected to pay for it and raising it as a topic to journalists willing to listen if they don't pay for it is a valid defense. And that includes paying for the past access. ChristianKl ❪✉❫ 14:30, 7 October 2026 (UTC)

Wikidata + Wikibase Office Hour // 2026-10-07 - 16:00 UTC

The next Wikidata+Wikibase office hour will take place on Wednesday, 16:00 UTC, 07th October 2026 (18:00 Berlin time) in the Wikidata Telegram group. The Wikidata and Wikibase office hours are online events where the development team presents what they have been working on over the past quarter, please bring your questions, discuss important issues with the teams and hear about future development of Wikidata and Wikibase. Look forward to seeing you there! Danny Benjafield (WMDE) (talk) 14:29, 6 October 2026 (UTC)

Notes are now at: Wikidata:Events/Telegram office hour 2026-10-07. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 15:53, 9 October 2026 (UTC)

African plant database ID

Can you please review Property:P2036, because the links to the website seem to be dead links. Windwardcoast (talk) 02:08, 7 October 2026 (UTC)

Now the links just seem wrong, but not dead links. An example is Q113881766. Windwardcoast (talk) 02:40, 7 October 2026 (UTC)

It's going to the home page currently. It looks like they have changed their website that link should be: https://africanplantdatabase.ch/en/nomen/specie/83628/phyllogeiton-zeyheri-sond-suess Secretlondon (talk) 10:55, 7 October 2026 (UTC)

Think I managed to make the formatter URL work again. Links can take 24 hours to update. Infrastruktur (talk) 11:55, 8 October 2026 (UTC)

Unacceptable lag continues - Quickstatements (2 and 3) making most edits while lag high

There have been persistent problems with too many edits to Wikidata for the WDQS servers to keep up with (partially due to the high load on those servers, but there's not much we can do about that as editors here).

I checked RecentChanges (including bots) for a time period starting at 2026-10-08 00:34 when the maxlag parameter had been over 5 for at least 10 minutes. Of the 500 changes during the next minute or so, 166 were done by QuickStatements 3.0, 145 by "MS Sakib" (a bot?), 85 by Quickstatements 2.0, 74 by either "Wikidata user interface" or "Wikidata for Firefox"(?), and a handful of admin updates, cross-wiki updates, and other scripts like merge.js. According to the documentation on maxlag, "Noninteractive tasks should always use it." Why do we allow Quickstatements (both versions), and some other clearly noninteractive actions, to avoid this? The bulk of the Quickstatements actions in this time period seemed to be adding descriptions on items in languages where they don't have them, which doesn't seem like a high priority justifying aggressive editing. Meanwhile well-behaved bots are unable to do their work. I know there has been one recent related Phabricator task - T421642 - but that seems to so far have just focused on allowing bots to read at higher lag values, and not the underlying issue that many "noninteractive" edits - 79% of all edits in this time period - are happening completely ignoring the maxlag parameter. We need to enforce this better somehow. ArthurPSmith (talk) 01:09, 8 October 2026 (UTC)

MS Sakib is doing many edits a minute but is a human. They have the flood tag. Unregistered bot? Also just adding descriptions.Secretlondon (talk) 07:04, 8 October 2026 (UTC)

https://addons.mozilla.org/en-GB/firefox/addon/wikidata/ reviews claim it automatically adds unwanted aliases. Secretlondon (talk) 07:08, 8 October 2026 (UTC)

I assume QS is allowed because it's *technically* manually-curated edits (or at least should be in a lot of cases), but there's certainly a strong argument here that it should be throttled to avoid causing problems for other editors. Or at the very least it should be possible to opt-in or force specific users to opt into respecting max lag on their QS batches. Nicereddy (talk) 14:14, 8 October 2026 (UTC)

Also, at least for merge.js that's definitely manual by an editor. Nicereddy (talk) 14:15, 8 October 2026 (UTC)

Yes, I wasn't complaining about that one, just noting it was one of the handful of ones that weren't quickstatements or MS Sakib or the standard Wikidata UI. ArthurPSmith (talk) 21:05, 8 October 2026 (UTC)

Calling someone who's an admin at the Bengali Wikipedia a bot does not seem to be conducted to me.

I think having a policy that manages descriptions would be worth it, and I think it does make sense to have the policy forbid adding these kinds of mass descriptions.

Ideally, I would want to see descriptions move to it's own service in the future where they are in standard cases autogenerated with WikiFunctions so that these kind of descriptions don't take up valuable database space and database writes. ChristianKl ❪✉❫ 15:33, 8 October 2026 (UTC)

Agreed. On why I said (a bot?) - the edits in Recent Changes had the 'b' designator for bot edits, and were not there when I filtered only for human edits. ArthurPSmith (talk) 21:03, 8 October 2026 (UTC)

If you have the 'flood' flag, your edits are tagged with 'b' and hidden from recent changes I think. Reading Wikidata:Flooders, it is intended for temporary use; so using it for a bot like task seems a bit questionable, although it prevents that description edits fill up your Recent Changes. Difool (talk) 01:57, 9 October 2026 (UTC)

+1 on having a policy that generally forbids massive additions of descriptions, especially if they can be easily inferred from a few of the statements of the item (and so, probably, they could be autogenerated in the future). Epìdosis 14:09, 10 October 2026 (UTC)

 Question I have another suggestion. What if we introduced a temporary permission for contributors planning very large mass-editing projects? They could explain the purpose, expected number of edits, data sources, and why the project would be useful to Wikidata. After community review, approved projects could be given scheduled editing windows or controlled priority, while still respecting server load and maxlag. This could help support valuable large-scale contributions without putting unnecessary pressure on Wikidata's infrastructure. What do others think? -- DERDAKI ILIAS (talk) 11:31, 9 October 2026 (UTC)

@DERDAKI ILIAS while writes are one limit total size of our data also matters. Generally when it comes to adding a larger amount of data, most people on Wikidata just want to add data and not review what other people do. If look at the amount of community engagement that bot requests and property requests currently get, it's relatively little. ChristianKl ❪✉❫ 17:03, 9 October 2026 (UTC)

Property proposals seem to be getting a pretty good level of attention lately - most proposals get at least one or two comments and several edits from other people. I agree that bot requests haven't, but I think that is largely because so many people seem to have workarounds like Quickstatements or not even asking for a bot flag to do mass edits, so they don't see it as relevant to what they do. ArthurPSmith (talk) 00:19, 10 October 2026 (UTC)

@ArthurPSmith@ChristianKl

I suggest establishing a clear process for managing large-scale imports through Wikidata:Mass editing proposals:

1. Contributors should provide their data sources, licenses, estimated number of edits, and methods for checking data quality and avoiding duplicates.

2. Each project should start with a test batch of 50–100 edits, reviewed by an independent Wikidata contributor.

3. If no major concerns remain after community review, imports could proceed in small batches, starting with around 1,000 edits and gradually increasing if no issues arise.

4. A shared schedule could help coordinate major imports and prevent several large-scale operations from running simultaneously.

5. Imports should automatically pause when maxlag increases or repeated errors occur, and resume only after the issues are resolved.

To address the lack of community participation, we could also create a list of volunteer reviewers who receive notifications about proposals related to their areas of expertise.

This would help address both data quality and server load without introducing new user rights or allowing anyone to bypass maxlag. --DERDAKI ILIAS (talk) 10:28, 12 October 2026 (UTC)

Mobile statement editing is officially coming soon!

Great news! After a successful beta testing period, we are delighted to reveal that Wikidata mobile statement editing will become fully available for all datatypes, to all editors, next week (October 14, 2026).
But if you really can’t wait, you can already edit statements on mobile by enabling it in your preferences.

Enable Beta and Mobile skin

• Tick the checkbox for mobile editing in your User Preferences > Beta features
• It works best on the mobile skin, activate MinervaNeue for your device (or browser).

Community Gadgets:

• may need to be updated for full compatibility with the mobile skin ‘MinervaNeue’
• Gadget maintainers, please check your tools.

Feedback still wanted:

• We encourage you to start mobile editing but the feature is still in beta and still new, bugs and errors can happen.
• If you encounter something you think is not right or not working, please let us know!

Thank you, -- Danny Benjafield (WMDE) (talk) 14:01, 8 October 2026 (UTC)

• Preview of mobile editing on Wikidata
• 
  Editing a statement on Wikidata mobile
• 
  Adding a value on Wikidata mobile
• 
  Searching for a claim on Wikidata mobile

Danny Benjafield (WMDE) (talk) 14:11, 8 October 2026 (UTC)

Thanks for the update! One thing I think is important to test is how the mobile editor handles right-to-left languages like Arabic, especially when statements contain a mix of Arabic text, Latin characters, and QIDs. It would be great to make sure editing is comfortable for users of these languages before the wider rollout. DERDAKI ILIAS (talk) 11:22, 9 October 2026 (UTC)

ITTF PTT ID

Can someone review my changes for Property:P13063? I can't see any problem, but it has been 48 hours since I changed the URLs to the new website but the links are not updating, still sends to old website. Otto Von Heim (talk) 18:13, 8 October 2026 (UTC)

I get the old site when I click on a player. Secretlondon (talk) 18:36, 8 October 2026 (UTC)

Looks good. It will change eventually, it takes some time. Any new claims you add should use the new formatter URL. Infrastruktur (talk) 20:33, 8 October 2026 (UTC)

Bad, old, merge

This 2019 merge conflated a person and a ritual dance (which may have been named after him). Would anyone care to unpick it? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 20:02, 8 October 2026 (UTC)

Mass editing policy in effect

I just created Wikidata:Mass-editing policy based on the conclusion of Wikidata:Requests for comment/Mass-editing policy. It should probably be translated; the related subpages with Caveats and the proposal page are also new and may need some attention. ArthurPSmith (talk) 01:05, 10 October 2026 (UTC)

I think we forgot to be explicit about this, but I guess that already properly approved bot tasks don't need to go through the process again, right? Whereas bots that are running without approved tasks should check if the policy now would apply to them? Ainali (talk) 05:54, 10 October 2026 (UTC)

In my view bot operators should check that they are in compliance with the policy, but step 3 (the approval process) can be skipped for "uncontroversial" batch editing, which would definitely include approved bot tasks. ArthurPSmith (talk) 12:33, 10 October 2026 (UTC)

I think it'd be good to inform any active bot operators of the new policy to ensure they're conforming to it. Not sure of what policy/standards we have of how to go about that, but it seems important to do so if we're changing/updating the rules. Nicereddy (talk) 12:49, 10 October 2026 (UTC)

Yeah, that's why I was specific in separating already community approved tasks. All users, not only those also having an account with a bot flag, should be informed about this policy as also usage of tool like QuickStatements or OpenRefine may be affected. Ainali (talk) 13:15, 10 October 2026 (UTC)

Probably, there should be a message in QuickStatements when a batch is over X edits reminding people of the policy. ChristianKl ❪✉❫ 07:39, 10 October 2026 (UTC)

Unknown daughters, again

Sir Henry Holland, 1st Baronet (Q7527156) has, among his children:

• unknown daughter Holland (Q76236375)
• unknown daughter Holland (Q76236376)

both by Saba Holland (Q18109072), and other with dates.

Other than two user-generated external IDs, neither of which adds any meaningful data, there is nothing to distinguish them.

But [2] names one one of these daughters, with dates: Caroline Holland, 1835–1909. How are we to determine which of those items (if, indeed, either) represents Caroline?

If I create a new item for Caroline, it could well give the impression that he has one more child than he should. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 18:15, 10 October 2026 (UTC)

Well since the two unknown daughters are not clearly identifiable, should they even be on Wikidata? Kordishal (talk) 18:24, 10 October 2026 (UTC)

en:Sir Henry Holland, 1st Baronet says Caroline Holland (1834–1909), author of Notebooks of a Spinster Lady, publ. posth. 1919, and Gertrude Holland (1840–1898). See also Burke's, e.g. here. TSventon (talk) 21:04, 10 October 2026 (UTC)

Thank you. Which of the two items I listed represents which of those women? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 22:23, 10 October 2026 (UTC)

As I said last time, the unknown daughters were found in Burke's peerage, which lists sons and daughters in order of age, so the first one should be the elder, Caroline, and the second the younger, Gertrude.

Again as last time, there was a third daughter who died when a baby, https://www.wikitree.com/wiki/Holland-16237. TSventon (talk) 00:08, 11 October 2026 (UTC)

@Pigsonthewing:, or anyone, I see you have updated Caroline Holland (Q76236375) and Gertrude Holland (Q76236376) but links in Sir Henry Holland, 1st Baronet (Q7527156) are still labelled "unknown daughter Holland", is it possible to update the labels shown, or do they update automatically after a delay? TSventon (talk) 16:10, 11 October 2026 (UTC)

It's a caching issue.

Thanks for the info, BTW. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 16:31, 11 October 2026 (UTC)

More thin item

What are we to make of the mother-and-daughter pair:

• NN (Q116150736): no description
• NN (Q116150739): no description ?

Are "NN" initials, or do they stand for "no name"? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 11:15, 12 October 2026 (UTC)

Further details requested

Madamebiblio deleted page Q141422288 (Does not meet the notability policy), could you explain what part of the policy? There was time invested in the creation of this entry, no warnings or messages were provided, the entry was erased without any description. MMERVIN (talk) 15:11, 11 October 2026 (UTC)

Logically, if it did not meet the notability policy, then it did meet any part of the notability policy.

""time invested" is not a criteria in determining notability. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 15:45, 11 October 2026 (UTC)

Emoji Zero Width Joiner (ZWJ) sequences vs. Unicode characters

Hi, I am looking at the item for astronaut Q11631. There are several statements for P487 Unicode character and all are flagged for violating the format constraint because they are Q100587415 emoji ZWJ sequences rather than single characters. Q117134681 exists as the emoji ZWJ sequence for astronaut.

Is the right thing to do here to remove the P487 Unicode character statements? Is there an appropriate statement to reflect the emoji ZWJ sequence on the item for astronaut? Is there a way to do this that continues to reflect the diversity of the astronaut images?

Thanks for any help you can provide. JMMaok (talk) 20:23, 11 October 2026 (UTC)

Wikidata API

hello all,

I came across something regarding the Wikidata API. In ticket Kristina Reiko Cooper (Q6588453), an unsourced claim about the year of birth was removed and added sourced claim. The older clam was hidden by admin. But in this link the older data still appears.Does anyone understand what's going on here? Geagea (talk) 05:56, 12 October 2026 (UTC)

Wikidata dates consist of a date value and a precision. Only the precision was changed to "century", so the item showed "20th century", but the stored date value still contained the exact year. I've now changed the stored date value to 1950, so it no longer contains the birth year. Difool (talk) 06:13, 12 October 2026 (UTC)

That's interesting. Is it possible that Google takes the date from the API? So theoretically the data in google search will be the direct date (1950 in this case)? Geagea (talk) 06:22, 12 October 2026 (UTC)

Request: item for ONCOassist (I have a conflict of interest)

Hello. I am the CEO of Portable Medical Technology Ltd, which develops ONCOassist, so I have a conflict of interest (declared on my user page). I'm not creating the item myself and would be grateful if an independent editor would consider it.

ONCOassist is a clinical decision support mobile app for oncology healthcare professionals (iOS, Android, web), developed by Portable Medical Technology Ltd, Ireland, since 2012.

Independent sources: - Liñares D, et al. "Mobile Apps for Oncology Health Care Professionals: Mapping and Assessment Study." JMIR mHealth and uHealth, 2026. doi:10.2196/71203 (independent evaluation of 20 apps) - "ONCOassist app: what nurses need to know" (already on Wikidata as Q127307756) - Healthcare IT News: https://www.healthcareitnews.com/news/europe/irish-oncology-app-launches-search-engine-clinical-trials - GEN review: https://www.genengnews.com/best-apps/oncoassist

Possible statements: instance of: mobile app; developer: Portable Medical Technology Ltd; country of origin: Ireland; operating system: iOS, Android; official website: https://oncoassist.com/; App Store app ID: 558299114; Google Play Store app ID: com.oncoassist.core.

If editors don't think it meets the notability criteria, I'll accept that. Thank you. Eoinoc1 (talk) 13:57, 12 October 2026 (UTC)

This is not the place to ask Vicarage (talk) 14:17, 12 October 2026 (UTC)

Thank you, understood. Could you point me to the right place for this kind of request, or is the advice that an item like this shouldn't be requested by someone with a conflict of interest at all? I'm happy to leave it if so. Eoinoc1 (talk) 15:34, 12 October 2026 (UTC)

Human classification 2026-10-12

1. Fake artists (Q107662846) subclass of human (Q5) @Peter F. Patel-Schneider - why would that be so? 2024-07-29 https://www.wikidata.org/w/index.php?title=Q107662846&diff=prev&oldid=2215638791
2. child (Q7569) subclass of human (Q5) @TomT0m - why would that be so? 2025-06-25 https://www.wikidata.org/w/index.php?title=Q7569&diff=prev&oldid=2367595699
3. male human (Q84048850) and female human (Q84048852) each
   1. subclass of natural person (Q154954) @عُثمان - why would that be so?
      1. male 2026-09-13 https://www.wikidata.org/w/index.php?title=Q84048850&diff=prev&oldid=2544334717
      2. female 2026-09-13 https://www.wikidata.org/w/index.php?title=Q84048852&diff=prev&oldid=2545252008
   2. instance of class of human (Q134264207) - but not a subclass of human
   3. instance of class of living thing (Q55597235)
   4. subclass of male animal (Q118947593) or female animal (Q118947579) - neither of these subclass of animal - but subclass of male organism (Q44148) and female organism (Q43445) each of these instance of sex (Q290) and type of living thing (Q136772242)
4. natural person (Q154954)
   1. main subject human (Q5) @WikiHelper232 - why would that be so? 2024-07-20 https://www.wikidata.org/w/index.php?title=Q154954&diff=prev&oldid=2208897822
   2. subclass of legal person (Q3778211)
   3. subclass of anatomically modern human (Q5891007) - which is a subclass of Homo sapiens (Q15978631) - @عُثمان - why would that be so? 2026-09-01 https://www.wikidata.org/w/index.php?title=Q154954&diff=prev&oldid=2539105584
5. orphan (Q193279)
   1. instance of condition (Q813912) and legal status (Q2628882)
   2. subclass of child (Q7569) @Coyau - why would that be so? 2014-06-20 https://www.wikidata.org/w/index.php?title=Q193279&diff=prev&oldid=139149110
6. princess (Q863048)
   1. subclass of aristocrat (Q2478141) - which is instance of social class (Q187588)
   2. subclass of woman (Q467) @Infovarius - why would that be so? 2019-02-04 https://www.wikidata.org/w/index.php?title=Q863048&diff=prev&oldid=850770357
7. woman (Q467) subclass of adult human (Q9584157)
8. adult human (Q9584157) instance of phase of human life (Q785260) and social status (Q189970)
   1. subclass of human (Q5) @Swpb - why would that be so? 2018-07-09 https://www.wikidata.org/w/index.php?title=Q9584157&diff=prev&oldid=708586475

HumanDataManager (talk) 15:32, 12 October 2026 (UTC)

What points are you trying to make? Peter F. Patel-Schneider (talk) 15:36, 12 October 2026 (UTC)

What do you mean? HumanDataManager (talk) 15:38, 12 October 2026 (UTC)

Bonus: Mighty Mike Plays (Q141581790) instance of YouTube channel (Q17558136) and instance of child (Q7569) . HumanDataManager (talk) 15:50, 12 October 2026 (UTC)

@HumanDataManager A natural person according to the enwiki article attached to the item is "the human being considered as a subject of rights and obligations". This excludes premodern humans that would not have been considered subject to rights and obligations. All natural persons are anatomically modern humans.

The Borhan Ontology (linked in the equivalent class property) has a natural person class, along with subclasses for Male and Female natural persons. The class hierarchy is intended to match that. عُثمان (talk) 16:04, 12 October 2026 (UTC)

Wikidata weekly summary #753

Here's your quick overview of what has been happening around Wikidata in the
week leading up to 2026-10-12. Missed the previous one? See issue #752.

Discussions

• Open request for adminship:
  • DERDAKI ILIAS - RfP scheduled to end after 13 October 2026 11:19 (UTC)
  • Aue Nai - RfP scheduled to end after 15 October 2026 02:58 (UTC)
• New requests for permissions/Bot:
  • OKA bot 2 - Tasks: Two additional datasets for the (already approved task of OKA bot). For each entry, the bot finds the matching item, adds the identifier if it is missing, and adds the facts the entry states, each referenced to the entry.
  • MisovalkoProfileBot - Task: A narrowly scoped source-verification and, only if approved, existing-item update process for Q97454550.
  • RegularBot 4 - Task/s: Create new items from Wikipedias.
  • GZWDer (flood) 7 - Task/s: Import data from external sources in comply with the recently approved Wikidata:Mass-editing policy.
  • GZWDer (flood) 8 - Task/s: Adding mul labels and aliases; cleanup existing labels in certain cases. No edits to other people's biographies, invented conference items, undocumented private engagements, unsupported future appearances, or promotional link dumps.
• Closed request for permissions/Bot, all closed as successful: MamouriBot, OKA bot, Rebot, Rebot 2, Rebot 3, Rebot 4
• New request for comments: Requests for comment/has part (P527) for european political alliances (Q127603408) - Q127603408 (European political alliance) was created as a subclass of Q60170135 (political alliance) for european parties. While Q60170135 allows using has part(s) (Property:P527), they were reverted, with "Members are not "parts".
• Closed request for comments:
  • Mass-editing Policy - Consensus reached, the policy will be implemented.
  • External Identifier sorting - No consensus

Events

• Upcoming events:
• Wikidata Query Service Days commences 17 October, until 23 October, make sure to register for access.
  • See the full program, sessions will repeat for different timezones
• Wikidata's 14th Birthday is coming, 29 October. Join the Birthday call and see what presents have been prepared, and see what community events are happening near you.
• Wikidata Days in Africa 2026
• Dates, location and scholarships are open for: Wikimania 2027
• Dates and location for next Wikimedia Hackathon has been announced and scholarship applications are open: Wikimedia Hackathon 2027 * Previous event:
  • If you missed the quarterly Wikidata + Wikibase Office Hour, you can find the transcript here.

Press, articles, blog posts, videos

• Blogs: P101 - field of work by rtnF
• Videos:
  • Access to Memory (AtoM) with Wikidata links.
  • Lightning Talk Wikilokal Exploring Wikimedia Around You with Affandy Murad, it combines information from Wikipedia, Wikidata, Wikivoyage, Wiktionary, and Nominatim within a 3-kilometer radius.
  • RDA Wikibase Cloud Sandbox Demonstration: Creating an Account and Logging In - demonstrates account creation and login process for Crystal Yragui's Wikibase cloud instance: A sandbox for students at University of Washington information school as they learn Official RDA cataloging.

Tool of the week

• Wikidata Reference Validator - A tool which helps validate external references of Wikidata items to check if their links are still accessible or now offline. This matters because we want to ensure that we have solid references for statements in Wikidata, so we can demonstrate how we know what we know

Other Noteworthy Stuff

• Wikidata talk:Mass-editing policy has been accepted and is now in effect.
• Wikifunctions Status Update 2026-09-25 (The Mayor of Paris) and Wikidata's spread across Wikipedias.
• Editing Wikidata statements on mobile devices is officially launching soon!
  The beta is ending, from October 14, all editors will be able to edit all datatypes from mobile devices.

Newest properties and property proposals to review

• New property proposals to review:
  • General datatypes:
    • disambiguated by (Links a Wikibase Lexeme to a general disambiguation page, such as a [[Q4167410|Wikipedia disambiguation page]].)
    • biome (biome in which a geographical area is wholly or partly located, according to a documented ecological classification)
  • External identifiers: Bibliothèque nationale de Tunisie ID, Mappola ID, On Think Tanks ID, Beeld & Geluid program ID, Le Random subject ID, RETE ID, identificativo Corago di un evento, AVN company ID, AVN person ID 2, swissNAMES3D ID, THB Wiki ID, Nederlands Fotomuseum-id

You can comment on all open property proposals!

Did you know?

• Query examples: Current collections of Astrolabes by the Lahore astrolabists (relevant English Wikipedia article)

Development

• Mobile statement editing: We fixed a few remaining issues before the full roll-out to everyone later this week.
• hCaptcha support: We planned how to integrate support for hCaptcha in the Wikibase-related pages.
• Wikidata integration in the other Wikimedia projects:
  • We are collecting feedback from the first wikis about removing the language link change entries from Recent changes and watchlists.
  • We are collecting data to determine how much we can increase the entity usage limit.
• REST API: We are continuing to add support for Lexeme editing to the REST API.

You can see all open tickets related to Wikidata here. If you want to help, you can also have a look at the tasks needing a volunteer.

Weekly Tasks

• Add labels, in your own language(s), for the new properties listed above.
• Contribute to the showcase Item and Lexeme above.
• Govdirectory weekly focus country:
• Summarize your WikiProject's ongoing activities in one or two sentences.
• Help translate or proofread the interface and documentation pages, in your own language!
• Help merge identical items across Wikimedia projects.
• Help write the next summary!

· Previous issue · Full report · Unsubscribe . JosefAnthony talk ·MediaWiki message delivery (talk) 15:48, 12 October 2026 (UTC)