Jump to content

Wikidata:Project chat

Add topic
Shortcuts: WD:PC, WD:CHAT, WD:?
From Wikidata

Merging Shtokavian lexemes

[edit]

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)Reply

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)Reply
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)Reply
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)Reply
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)Reply
 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)Reply
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)Reply
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)Reply
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)Reply
@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)Reply
 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)Reply

 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)Reply

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)Reply

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)Reply
@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)Reply
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)Reply
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.
I seriously hope stewards are watching this, because this is literally turning into some personal discussion against me since you are more commenting me as a Wikipedian and totally not my comments (= what I wrote). So basically being pinged to a discussion makes someone's opinion more or less valid? Basically your entire argument is that my comment is suspicious (probably canvassing?/meatpuppetry?) because I lack activity with lexemes? You are wrong. Wikidata is a global place, familiar to all of us, regardless of our primary area/project of focus or activity. A "sudden appearance" is definitely not strange it is common practice for editors to find out about important discussions through watchlists, community portals/village pumps or off-wiki communication. Similar to RfCs on meta-wiki, I only appeared when it was something hr.wiki or Croatian language related. Nothing weird for people to only come to a different project when it catches their interest. Every established Wikipedian knows that and I guess that so do you. Sorry, but if an important discussion catches someones eye then it is nothing "strange" that even someone who is less active in that area "appears out of nowhere", nothing to "call out". Treating a return from a period of low activity on Wikidata as a red flag is far from productive or collegial. At the same time, limiting valid participation to "lexeme specialists" only creates an echo chamber and "preventing" less active users on Wikidata from commenting is definitely undermining the nature of community discussions on Wikimedia projects. This is definitely not a type of discussion I want to participate. Koreanovsky (talk) 22:07, 12 October 2026 (UTC)Reply
I intend to chime in on this topic in the coming day. – Vipz (talk) 14:50, 19 October 2026 (UTC)Reply
@Vipz: Your thoughts on this matter are still welcome. Mahir256 (talk) 00:46, 26 October 2026 (UTC)Reply
Initially, I was not entirely sure whether they should fall under Shtokavian (Q148893) or Serbo-Croatian (Q9301). After reading your posts more closely, however, I am fully convinced that Shtokavian is the better choice for the merger. The question on how to annotate all of these distinctions seems to have been worked out and covered in your October 12th post, so I have little to add here. Are we going to cover the Ikavian (Q3043944) yat reflex as well, then connect all three with "said to be the same as lexeme (P11577)"? – Vipz (talk) 06:30, 27 October 2026 (UTC)Reply
@Mahir256: thank you for a very detailed reply. I'm sorry you were disappointed by my replies, but unfortunately I have minimal contact and no understanding of internal workings of Persian and other South Asian languages, so I did not feel comfortable speaking and basing my opinion on things I have no knowledge of.
I similarly feel as though you did not understand the root of the problem I'm pointing to. The problem is not Wikidata itself, if this proposal is accepted, a solution to implement it into Wikidata would be found with minimal issues. My opposition relates to whether or not this proposal should be accepted in the first place.
In your examples, you systematically insist on location of sense usage (P6084), a unified language and a separate geographic location. you are turning a linguistic classification into a geographical classification. What possible value is gained by forcing these entries to share a fictional, unified language item and then having them split this way? A lexical database should categorize words by the language they belong to, not by the geopolitical borders of where the speaker happens to be standing. I have already given many examples for why this doesn't work, yet you keep insisting. Even dialects within Croatia alone have enough semantic nuance to warrant a separate Lexeme entry, it is beyond silly to merge three or more languages into one, based on virtually no understanding of how they work within their communities. Ivi104 (talk) 12:56, 31 October 2026 (UTC)Reply

Disagreement about image (P18) versus image of cosplay (P13632)

[edit]

I and User:Mikirito 07 have a disagreement surrounding when to use image (P18) versus image of cosplay (P13632). I have been (manually) moving many claims from P18 to P13632 whenever the photo clearly depicts a cosplay (example), and Mikirito 07 have been reverting many of this. I ask for help to resolve this dispute and find a consensus-supported solution.

My side of the story: I believe it is obvious that cosplay photos belong under P13632 since that is the whole point of the property. Its property proposal seem to show consensus in favor of using P13632 in place of P18 when that is what the media depicts, including how sisterprojects should handle it. Any sisterproject that checks for images on P18 are more than free to also check on P13632. Rose Abrams (talk) 18:58, 18 October 2026 (UTC)Reply

The problem is P13632 doesn't allow the image to be shown here or here, and instead P18 makes it possible. I think P18 should be used whenever there is no other image other than cosplays, and P13632 should be used only in cases like this one. Mikirito 07 (talk) 19:31, 18 October 2026 (UTC)Reply
And as mentioned on your usertalk, you can easily modify the script of those pages to display from either P18 or P13632 depending on what's available for any given item. Rose Abrams (talk) 19:47, 18 October 2026 (UTC)Reply
I don't know if it can be done, but in this case I don't know how to do it. Mikirito 07 (talk) 19:48, 18 October 2026 (UTC)Reply
I suspect a lot of these shouldn't be on commons anyway as they are trademarked characters. Secretlondon (talk) 07:00, 19 October 2026 (UTC)Reply
@Secretlondon cosplays are allowed as free depictions of the characters Mikirito 07 (talk) 08:13, 19 October 2026 (UTC)Reply
Secretlondon, that's not what our questions are about, please stay on topic. If you have concerns about files being on Commons, then start a deletion discussion over on that project. Rose Abrams (talk) 09:00, 19 October 2026 (UTC)Reply
The trademark issue means than in many cases our only image would be a cosplay one, but I still think image of cosplay (P13632) is the place for them. It ensures the queryier knows what they are getting Vicarage (talk) 21:33, 19 October 2026 (UTC)Reply
Is it possible to modify the script of the paged to display from either P18 or P13632 depending on what's available? If so, how? Mikirito 07 (talk) 21:42, 19 October 2026 (UTC)Reply
Probably you can just query both properties and union the results with P18 taking priority. I could try modify the pages' queries tomorrow if you want. Rose Abrams (talk) 21:44, 19 October 2026 (UTC)Reply
Ok, thank you :)
P.S. can you please do the same for those two pages? Mikirito 07 (talk) 21:51, 19 October 2026 (UTC)Reply
I have now edited one of the pages per your request. @Mikirito 07: Please confirm that it gives the functionality you want, and then I will do the same with the other 3. Rose Abrams (talk) 07:45, 23 October 2026 (UTC)Reply
@Mikirito 07: I would like to remind you to that I above asked for confirmation that the script now behaves as you want it to. You have not replied, but I see that you are still performing the same type of edits while this discussion is ongoing. I was reluctant to fix your script(s) in the first place since I have no interest in the galleries, so I kindly ask that you are cooperative and not further the disagreement. Rose Abrams (talk) 13:25, 2 November 2026 (UTC)Reply
Query to 2 dIfferent variables and use COALESCE in the order you want them Vicarage (talk) 03:49, 22 October 2026 (UTC)Reply
I also think that if anything wants images of cosplay as well as regular images, it should query that. Making the database worse instead of making other pages better seems like a bad solution. Psychpsyo (talk) 08:26, 24 October 2026 (UTC)Reply
💯👍 Rose Abrams (talk) 19:55, 24 October 2026 (UTC)Reply
Whether Marvel Comics characters/DC Comics characters pages want to show cosplay or not, should be their content decision to make. Having our cosplay images at P13632 instead of P18 allows them to make that choice.
The general idea is that a page like ChristianKl ❪✉❫ 18:31, 30 October 2026 (UTC)Reply

Items for arbitrary intersection categories

[edit]

What is the purpose of items like Category:St. Mark's Episcopal Cathedral, Seattle - exterior (Q141774454)? Is it our intent to create an item for every category that some sister project finds useful, including all of these intersections? In this case it's a Commons category I created, but I wouldn't think of it as a useful Wikidata item. - Jmabel (talk) 00:57, 23 October 2026 (UTC)Reply

You need it for properties like category for the interior of the item (P7561) as it requires these category items rather than linking to the category directly. Secretlondon (talk) 05:05, 23 October 2026 (UTC)Reply
It's a bit of a cludge, why can't we link to these categories directly? Secretlondon (talk) 05:21, 23 October 2026 (UTC)Reply
You can only have one commons sitelink on a specific item, so having more specific items is required for that. As far as I can tell pages on other wiki projects are always linked like that and not as values of statements. Kordishal (talk) 11:49, 23 October 2026 (UTC)Reply
They are always linked like this but could we change the software? We can have two commons sitselinks as the commons multilingual link could go to a gallery, and commons category always goes to a category. Secretlondon (talk) 10:36, 24 October 2026 (UTC)Reply
that would only partially solve the issue, when you have a category both for the interior and exterior youd still need that "work around". Kordishal (talk) 06:44, 25 October 2026 (UTC)Reply
Not if we could have multiple sitelinks. Secretlondon (talk) 10:30, 25 October 2026 (UTC)Reply
There being exactly one sitelinks is a key feature of the data model of Wikidata. ChristianKl ❪✉❫ 18:25, 30 October 2026 (UTC)Reply

facet vs part of for "history of" items

[edit]

I've been looking at the aspect of history (Q17524420) items, like history of California (Q1818043) which has facet of (P1269) California (Q99) and part of (P361) history of the United States (Q131110). This makes sense to me, fitting with the disjoint aspects of facet, and the direct part of. But if you look at the items, many have the "history of" as a facet, though very few have the region as a part of, and lots have neither. Before I rationalise them to the California approach, are there any arguments for not doing so? Vicarage (talk) 07:35, 26 October 2026 (UTC)Reply

 Support @Vicarage: Makes sense to me. ArthurPSmith (talk) 15:29, 2 November 2026 (UTC)Reply

Independent advice on notability — Eric Dunkel

[edit]

Hello,

I’m Eric Dunkel, the person concerned by this request. I have a conflict of interest and would prefer not to create a Wikidata item about myself.

I submitted two requests on 14 and 22 September 2026. Both were archived without a reply from another contributor.

Could an independent editor advise whether the available sources meet Wikidata’s second notability criterion, or explain what evidence is missing?

Previous request: https://www.wikidata.org/wiki/Wikidata:Requests_for_new_items/Archive/2026/09#Eric_Dunkel_2

Main sources:

I understand that these sources may have different evidentiary value. I am simply asking for an independent assessment, not automatic creation of an item.

Thank you for your time. ~2026-57193-08 (talk) 12:46, 27 October 2026 (UTC)Reply

This is not the place to ask, why not read the page header? Vicarage (talk) 13:06, 27 October 2026 (UTC)Reply
@Vicarage maybe we should just autodelete these kind of misfilled posts? @Vicarage ChristianKl ❪✉❫ 11:32, 2 November 2026 (UTC)Reply
I agree, but @Bovlb remonstrated with me on my talk page when I did. Vicarage (talk) 11:47, 2 November 2026 (UTC)Reply

Notability review request — SignalSumo (Q141898322)

[edit]

Hello Wikidata community,

I recently created SignalSumo, an SEO and AI search visibility software platform.

I am affiliated with SignalSumo and have disclosed this on my user page.

The item currently includes the official website and three publicly available references:

I would appreciate feedback on whether this item meets Wikidata's notability criteria and whether any additional sourcing or changes are necessary.

I understand that these sources may differ in editorial independence and reliability, and I welcome an independent assessment.

Thank you!

Signalsumo (talk) 08:07, 28 October 2026 (UTC)Reply

Have you not bothered to read the rest of this page, where we say over and over its not the place to ask Vicarage (talk) 08:40, 28 October 2026 (UTC)Reply
It's always the same text, I presume from AI. No reading or writing involved! Secretlondon (talk) 08:13, 29 October 2026 (UTC)Reply
Except by us, of course. We have to read it all. Secretlondon (talk) 11:50, 31 October 2026 (UTC)Reply

how to add circa to a qualifier?

[edit]

Florida State Road 94 had Loop Road as a part from 1945 until c. 1980. What's the correct way to represent this? Putting all three qualifiers at the same level doesn't seem correct. NE2 (talk) 16:03, 28 October 2026 (UTC)Reply

Use the qualifier sourcing circumstances (P1480) circa (Q5727902) ChristianKl ❪✉❫ 11:20, 2 November 2026 (UTC)Reply
That's what I did, but there's no indication that the circa applies only to 1980. --NE2 (talk) 17:25, 2 November 2026 (UTC)Reply
Unfortunately there's no way to do what you're wanting to do while keeping everything in one value. The only way would be to have two values of Loop Road (Q3259263), one with the start date, the other with the end date and circa. I'm not sure that would look any better than how it is set up now. — Huntster (t @ c) 18:05, 2 November 2026 (UTC)Reply

Including coaches in the players of a team

[edit]

Hello, I would like some opinions here -> Wikidata_talk:WikiProject_Sports#Players_of_a_team :-) thank you. --Superchilum(talk to me!) 20:33, 29 October 2026 (UTC)Reply

Missing timezone for islands in Europe

[edit]

Dutch Wikibooks, yesterday: 4 islands (Malta, Cyprus, Sark and Alderney) suddenly didn't have a timezone anymore. So I edited Wikidata (P421) and all seemed to be okay again, just like it had been for 10 months. But today 8 other islands showed the same error: Brecqhou, Herm, Jan Mayen, Jethou, Kreta, Madeira, Spitsbergen and Texel!! Why is this happening ? - Erik Baas (talk) 23:13, 29 October 2026 (UTC)Reply

CC @User:RVA2869 Bovlb (talk) 02:16, 30 October 2026 (UTC)Reply
Property talk:P421#Removing redundant values. Also Q233#P421 has daylight saving time and in Q193896#P421 it's missing and there is no qualifier. Peter James (talk) 11:01, 30 October 2026 (UTC)Reply
For the islands mentioned above, the time zone is redundant, as it is already covered at a higher administrative level.
+ Islands (in the geographical sense) should, in fact, not have a time zone. Time zones should only be applied to large administrative units. As mentioned in Property:P421#P2559. RVA2869 (talk) 11:16, 30 October 2026 (UTC)Reply
It doesn't sound redundant if it's being used in inboxes. Secretlondon (talk) 16:56, 30 October 2026 (UTC)Reply
Then those infoboxes should be fixed to fetch the value from items above it. Sjoerd de Bruin (talk) 23:12, 30 October 2026 (UTC)Reply
@Secretlondon Well, that’s not how redundancy works.
@Sjoerddebruin Yes, or (I’m not sure if this is possible) retrieve it from coordinate location (P625). I don’t have any experience with templates / Lua modules. RVA2869 (talk) 11:34, 31 October 2026 (UTC)Reply

Regarding the order of original works, TV anime, TV dramas, and films

[edit]

I would like to clarify whether existing QIDs should always be retained for original works, with newer QIDs assigned to their adaptations.

For example:

- **Kiki's Delivery Service:** The animated film (Q196602) has an older QID than the original novel (Q1768944). - **Neon Genesis Evangelion:** The manga (Q1977621) began serialization before the television anime aired, but the anime (Q662) has the older QID. - **Otoko wa Tsurai yo:** The television drama (Q141247650) preceded the film series (Q2037169), but the film series has the older QID. - **Only Yesterday:** The existing item (Q1045889) represents the animated film, while the original manga does not have a separate item.

Under the proposed approach, would these items also need to be reorganized so that the original or earlier work retains the older QID?

In the case of *Only Yesterday*, would we need to create a new item for the animated film, transfer its existing statements, external identifiers, and sitelinks to that new item, and then repurpose Q1045889 for the original manga?

Or would it be acceptable to retain Q1045889 for the film and simply create a new item for the manga? ならちゃん (talk) 08:44, 30 October 2026 (UTC)Reply

We never repurpose QIDs, and there is no significance in their order, so there is no need to do this. You always don't want to disrupt existing users of the item. So if splitting an item, always consider its main original purpose. When joining items, its generally common to merge into the older item, just because its more likely to be in use, but the other items becomes a redirect so the process is seamless. Vicarage (talk) 08:53, 30 October 2026 (UTC)Reply
Thank you for the clarification. I agree that QID order should not determine which item represents the original work or an adaptation.
My concern is specifically about cases where an existing item was originally created for a television series or film, and a separate item for the original work was created later. ならちゃん (talk) 09:21, 30 October 2026 (UTC)Reply
new items with a new purpose have new ids Vicarage (talk) 09:33, 30 October 2026 (UTC)Reply
If this is about what I raised on your talk page, those items weren't created for a television series, they were created because there's an existing Wikipedia article and it just accumulated TV series-related properties over time via automated edits; it was never modelled properly in the first place. —Xezbeth (talk) 14:00, 30 October 2026 (UTC)Reply

Completing the Tamulic / Tamili / Tamilian alias set on Q33311

[edit]

Hi everyone — Q33311 (Dravidian) already lists Tamulic as an English alias, and Glottolog has now merged the companion historical/endonymic spellings (Tamili, Tamilian, Tamulic) into master for node drav1251 (Glottolog PR #1398). Could an autoconfirmed editor please apply the pending request on Talk:Q33311 to add the remaining English aliases (Tamili, Tamilic, Tamili languages, Tamilian languages, Tamulic languages), Tamil aliases (தமிழிய மொழிகள், தமிழியம்), and named after (P138) (Q5885) alongside Tamulic? Thank you! ~~~~ Backnol (talk) 22:49, 30 October 2026 (UTC)Reply

rice paper (Q1066536)

[edit]

Hi. I discussed it more in detail in the talk page, but item rice paper (Q1066536) encompasses pages that discuss one or both of two separate topics that consistently share a name across languages, so the item is sort of a blur of both topics and their shared name even though on a formal, purely logical level those are three different topics. This is unsatisfying especially due to the inconsistency of which of those are covered in each language. I'm unsure what should be done, but if something is done at all it would require cross-project coordination, so I'd like to get feedback about this from other Wikidata editors.

I hope this all makes sense, if it doesn't please bear with me until I find time & energy to phrase things better when it's not 1:30AM. Arandomfolk (talk) 00:33, 2 November 2026 (UTC)Reply

So we have rice paper (Q1066536) which covers both edible paper made from rice, and thin craft paper. These are both known as rice paper. Our Wikidata item is also different from pith paper (Q111982540) and rice paper (Q15900793). It's not clear whether those are different again from the two meanings or one of the meanings. We only do Wikidata here. We need arguably three items - one for a disambiguation page (if it is one), one for the craft paper and one for the edible paper. The interwiki links can go wherever - we cannot make wikipedias change their articles.
Secretlondon (talk) 08:17, 2 November 2026 (UTC)Reply
rice paper (Q15900793) looks like nonsense. One link goes to google and doesn't differentiate between meanings, and the other is about non-specific calligraphy paper called rice paper. Secretlondon (talk) 08:21, 2 November 2026 (UTC)Reply
pith paper (Q111982540) appears to be a duplicate for pith paper (Q18603723). So, a subtype of the craft and writing paper. Arandomfolk (talk) 13:58, 2 November 2026 (UTC)Reply
Three items seems like the best course of action to me too, I think. And, we have no authority over the various Wikipedias but at least minimal coordination in the form of redirects (as mentioned by @ChristianKl) would be desirable to maintain interlanguage linking if we proceed with the split, wouldn't it? Arandomfolk (talk) 14:32, 2 November 2026 (UTC)Reply
It does make sense to separate it out. LLMs are very useful when it comes to deciding which existing Wikilinks should go where when you can't read the relevant languages.
https://www.wikidata.org/wiki/Wikidata:Sitelinks_to_redirects might be useful to still keep Wikilinks if some of the Wikipedia's mix topics while not having disambiguation pages. ChristianKl ❪✉❫ 11:31, 2 November 2026 (UTC)Reply

Proposal: mainpage improvements

[edit]

Hello, a week ago I posted a proposal for some changes to the Wikidata mainpage on its talk page. So far there hasn’t been any response, so I thought I’d share a link here to get wider feedback. Looking forward to hearing what the community thinks. Thank you! — Elisha Cohen (WMDE) (talk) 10:39, 2 November 2026 (UTC)Reply

It feels unclear to me to understand what your proposed changes are. Having a clear before-and-after image would make it easier to evaluate. ChristianKl ❪✉❫ 11:15, 2 November 2026 (UTC)Reply
There's a wireframe of the new layout included in the mentioned post. We should probably follow up there. ArthurPSmith (talk) 18:06, 2 November 2026 (UTC)Reply

megacity (Q174844) under city (Q515), while its members include metropolitan areas

[edit]

megacity (Q174844) is in the subclass tree of city (Q515); Its instances include cities (Tokyo (Q1490), Shanghai (Q8686)) and also metropolitan areas: Greater Mexico City (Q665894), New York metropolitan area (Q683705), Greater Buenos Aires (Q998798), Greater Rio de Janeiro (Q2720540); Those four carry metropolitan area (Q1907114), urban agglomeration (Q159313) or conurbation (Q245260) as well, so through megacity they count as cities in any query for "instance of city or a subclass": such a query returns both Mexico City (Q1489) and Greater Mexico City.

Should megacity stay under city? Or do these four want another class than megacity? I'd like to know the intended model (and any additional things worth noting) before changing anything. Trummler12 (talk) 10:55, 2 November 2026 (UTC)Reply

Having it under there seems to make sense to me, but I'm not sure we have a good intended model right now.
city (Q515) has as it's Wikiproject https://www.wikidata.org/wiki/Wikidata:WikiProject_Cities_and_Towns , so that page is a place to have a model. What's needed is probably a broader policy that thinks through the whole structure instead of just changes at one particular item. ChristianKl ❪✉❫ 11:27, 2 November 2026 (UTC)Reply

Removing bay (Q39594) from items that already are a gulf (Q1322134)?

[edit]

gulf (Q1322134) is a subclass of bay (Q39594), as is fjord (Q45776); According to Help:Basic membership properties#Transitive properties, an instance of gulf is therefore implicitly an instance of bay, with no general need for an explicit statement. That page doesn't say what to do when the explicit statement is already there, though.

Most items carry only the more specific class, but 69 gulfs have instance of (P31) bay beside gulf; 32 of those bay statements have a reference (none with a URL). For comparison, roughly 3 % of fjords also carry bay, 8 % of stratovolcanoes also carry volcano (Q8072), and 14 % of salt lakes also carry lake (Q23397).

Is the superclass simply redundant here and fine to remove, or is there a reason to keep it? Does the answer change where the statement has a reference? If removing is fine, would a batch for these 69 be welcome? Trummler12 (talk) 12:51, 2 November 2026 (UTC)Reply

Different languages categorize things differently, so some of these might be down to how these are classified in those languages. I say leave them, even though they seem redudant to some of us. - Yupik (talk) 07:46, 3 November 2026 (UTC)Reply

Values of ISO 3166-2 code (P300) outside the format: where do they belong?

[edit]

These values of ISO 3166-2 code (P300) break its format constraint; I can't tell where the information belongs, so I haven't touched them:

Should they move to another property, or simply go? Trummler12 (talk) 14:36, 2 November 2026 (UTC)Reply

Why not check what the value should be? We may have not done the format constraint properly. Secretlondon (talk) 15:49, 2 November 2026 (UTC)Reply
Thanks, I checked: the format constraint matches ISO 3166-2, and RVA2869 has since fixed or removed most of the list.
Three are left, and none of them has an ISO 3166-2 code to correct to: Kingdom of Denmark (Q756617) (DK, the country code, also in ISO 3166-1 alpha-2 code (P297)), Talensi-Nabdam District (Q1505271) (GH-UE-TN, a district, while ISO stops at Ghana's regions) and Ullern (Q174868) (NO-030106, a borough of Oslo).
If nobody objects, I'll remove those three.
Trummler12 (talk) 09:29, 3 November 2026 (UTC)Reply
@Trummler12 For Kingdom of Denmark (Q756617) and Denmark (Q35), it is a bit of a mixed bag. Kingdom of Denmark (Q756617) is the sovereign state, but it is often referred to simply as Denmark. RVA2869 (talk) 10:46, 3 November 2026 (UTC)Reply

Proposal: importing ~28,000 Mon (mnw) lexemes

[edit]

Hello,

I would like to add Mon language (Q13349, code mnw) lexemes to Wikidata. Mon currently has very few lexemes, and I have a word list of about 28,600 Mon lemmas with their lexical categories (noun 15,823, verb 9,547, adjective 1,834, adverb 1,245, and a few others).

Plan:

  • Only the lemma, language (Q13349) and lexical category will be added. No English glosses or definitions will be copied, so there is no copyright issue.
  • Before creating each lexeme, I will check that the same lemma + category does not already exist, to avoid duplicates.
  • I have manually created 10 test lexemes first: [list your L-IDs here]
  • After community feedback, I plan to request a bot flag and run the import slowly with a separate bot account.

Questions: 1. Is this import welcome? 2. Should senses or forms be added later, or is lemma + category enough for a start?

I am a native Mon speaker and can review spelling. Any advice is appreciated.

Thank you, Aue Nai (talk) 15:11, 2 November 2026 (UTC)Reply

@Aue Nai: I have several (possibly more?) questions about this import, which it seems you're trying to go ahead with:
  1. Where is this word list from? Are you able to cite this list as a source on the lexemes you are creating?
  2. Why are you (and your collaborators) creating the same lexeme more than once? I see, for example, the same word meaning "directly" existing as တပ်တပ် (L1716728), တပ်တပ် (L1569694), and တပ်တပ် (L1565411). There are hundreds, if not thousands, of lexemes like this (many of which will undoubtedly be evident from this query); please merge those lexemes and deduplicate their senses.
  3. Why are you not deduplicating senses themselves? ကရောတ် (L1778630) seems to have the same meaning of the word split over multiple senses; please combine those as well.
  4. Why are you not checking that the gloss matches the lexical category? ကရောတ် (L1778630) has a sense "East Indian arrow root" which looks more like the definition of a noun; please check that the senses you want to add match the lexical category of the word.
  5. Why are you not checking that the glosses are actual meanings of words? ကရောတ် (L1778630) has a sense "forbearing people do not complain" which does not sound like the definition of a word; if this is in fact a translation of a Mon sentence that uses that word, then consider adding that Mon sentence (with a reference!) as a usage example (P5831).
  6. Why are there a lot of "lexemes" which look more like phrases than individual words? I have a very hard time believing that the very long phrase မဆေၚ်စပ်ကဵုဘာ ပရေၚ်ပ္ကတ်ဗ္တောန်ပညာ ကဆံၚ်သၠုၚ် (L1566803) is actually what people say in Mon every time to indicate that something is "academic"; please provide for me a list of such "non-words" to delete, or indicate a heuristic by which I can choose such "non-words" to delete myself.
If you hadn't already begun this import right after raising the questions above, I would have insisted that these be addressed before attempting anything automatic, but alas I have to resort to the namespace block to prevent further additions of less-cleaned data. (If you have been getting better at English since April, congratulations! If you are using an LLM to clean up your written messages, please let us know that.) Mahir256 (talk) 19:20, 2 November 2026 (UTC)Reply
@Mahir256: Thank you for the detailed review, and I'm sorry for starting the import before your questions were answered. That was my mistake, and I accept the block until the data is cleaned up. To answer your last question first: yes, I use an AI tool (Claude) to help write my English messages. The content and decisions are my own.
  1. Source: The word list comes from the MonEng Dictionary app (© Saik Chan and Aung Nyan Lin, 2020; https://apps.apple.com/th/app/moneng-dictionary/id1509441935). Nai Saik Chan gave me permission to use it to help develop the Mon language. I have asked both copyright holders to release the word list under CC0 and to send a permission email to permissions-wikidata@wikimedia.org. I will post the ticket number here when they receive it. After that, I will add the dictionary as a reference ("stated in", with the reference URL) to the lexemes I created.
  2. Duplicate lexemes: The duplicates were created because the import did not check for existing lexemes first. I will go through the results of your query and merge the duplicates following Help:Merge, combining their senses.
  3. Duplicate senses: You are right. Where one meaning was split into several senses (as in Lexeme:L1778630), I will combine them into one sense.
  4. Glosses that don't match the lexical category: I will check every sense against the lexeme's lexical category, and fix or remove glosses like "East Indian arrow root" on a verb.
  5. Glosses that are not meanings: Some glosses were taken from example phrases in the dictionary, not from definitions. I will remove those glosses. Where I can cite the Mon sentence, I will add it as a usage example (P5831) with a reference.
  6. Phrases imported as lexemes: These entries were full explanations from the dictionary, not single words. I suggest this rule for finding them: a lemma that contains ၊ or ။, or that contains 2 or more spaces, or that is longer than 15 characters. I will put the full list on User:Aue Nai/Phrase lexemes so you can check it before anything is deleted.
My plan: (1) get the CC0 permission confirmed, (2) merge duplicate lexemes, (3) fix senses, (4) list the phrase lexemes for deletion, (5) add references. I will do this by hand, or with a script that I describe here first. I will not import anything new until the cleanup is finished and you or another admin agree. Aue Nai (talk) 19:44, 2 November 2026 (UTC)Reply
Dear Wikidata Admin,
Thank you very much for reopening it. Your guidance in pointing us back has helped us learn a great deal and has been very helpful.
We are volunteers with only a small number of people and limited capacity, working to keep our literature from disappearing. We have not had the opportunity to learn in a professional way, and we do things simply; if we have made mistakes, they are mistakes made in good faith.
Please allow me to continue maintaining this work. I will keep reviewing merges and rechecking them weekly. No one wants our literature to improve more than we do. We understand that this messy situation has made our literature work more difficult. We are students and young users who are gradually learning by ourselves and helping one another.
If possible, we would like access to training that could help us.
Thank you. Aue Nai (talk) 02:19, 4 November 2026 (UTC)Reply

Wikidata weekly summary #756

[edit]

False "no item" errors

[edit]

Over the last few days, I've been getting intermittent false "no such item" errors when adding values to statements manually (retrying usually finds the item on the second or occasionally third attempt), and today using QuickStatements (e.g. [1], where, if you select the "errors" tab, you can see failure reports for items that really do exist).

Is this a known bug? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 17:03, 2 November 2026 (UTC)Reply

Notability guidance for TechAmerica.ai (Q141975211)

[edit]

Hello Wikidata community,

I am affiliated with TechAmerica.ai, a technology news publication operated by TechAmerica.ai LLC, a company registered in Delaware, United States.

I recently created Wikidata item {{Q|141975211}} for the news publication. It currently includes an “instance of" statement identifying it as a news website and an official website statement.

Official website: https://techamerica.ai/

I understand that our own website and company registration do not, by themselves, establish Wikidata notability. I would appreciate guidance on whether this item meets Wikidata’s notability criteria and what additional independent sources or documentation would be needed.

I am disclosing my affiliation for transparency and am happy to follow the community’s guidance.

Thank you. Techamerica.ai (talk) 19:17, 2 November 2026 (UTC)Reply

this is not the place to ask, as you would have noticed from the page header Vicarage (talk) 19:56, 2 November 2026 (UTC)Reply
Thank you for the clarification. I apologize for posting my request in the wrong section. I will use the appropriate Wikidata page for further guidance. Techamerica.ai (talk) 20:07, 2 November 2026 (UTC)Reply

Request to merge Q125246428 and Q140038361

[edit]

hi NidaFatimaZaidi (talk) 21:44, 2 November 2026 (UTC)Reply

✓ Done Printstream (talk) 21:47, 2 November 2026 (UTC)Reply
Hello! My duplicate items have been merged into Q140038361. Could an editor please use these verified press features, professional profiles, and broadcast links to add references and external identifiers to the page? Thank you! NidaFatimaZaidi (talk) 22:22, 2 November 2026 (UTC)Reply

Connect zeawiki article to Q7809

[edit]

Hello! The article `UNESCO` on Zeeuws Wikipedia (zea.wikipedia.org) is not linked to Wikidata item Q7809. Could someone with edit rights please add the `zeawiki` sitelink? Thank you! ~2026-58121-03 (talk) 23:35, 2 November 2026 (UTC)Reply

✓ Done. --Wolverène (talk) 05:45, 3 November 2026 (UTC)Reply

Review requested Q137998537 and Q2903728

[edit]

I’ve posted sourced edit requests on Talk:Q137998537 and Talk:Q2903728. I’m a paid consultant for the subject, so I’d appreciate an uninvolved editor taking a look. Thank you. TheAuthorityExport (talk) 00:07, 3 November 2026 (UTC)Reply

So what's up here?

[edit]

Why are alpaca (Q81564) and Lama pacos (Q122181742) different pages? It looks as if w:alpaca only has four interlanguage links. ~2026-58412-24 (talk) 04:18, 3 November 2026 (UTC)Reply

Possible merge of "data visualization" with "data and information visualization"

[edit]

I'd like editors here to discuss whether to merge data and information visualization (Q133505171) with data visualization (Q6504956). ~2026-58412-24 (talk) 05:36, 3 November 2026 (UTC)Reply

The merging is almost certainly impossible because the mentioned concepts are different for the Wikipedias in Arabic, Japanese, and Korean (e.g. ja:データおよび情報の可視化(Q133505171) vs ja:データ可視化(Q6504956)). Regards, --Wolverène (talk) 05:49, 3 November 2026 (UTC)Reply

An unreferenced area of 11,418,174 km² on Taiwan (Q865)

[edit]

Taiwan (Q865) has two values for area (P2046): 36,193 km² with a reference, and 11,418,174 km² without a reference or qualifiers. The second looks like the territory historically claimed by the Republic of China, not the area it administers, though I have no source for that; Without a qualifier, anything reading the largest value takes it as the country's size.

Should this value get a qualifier saying what it covers, a lower rank, a source, or a move to another item? I'd rather ask than edit, given how sensitive this item is. Trummler12 (talk) 08:55, 3 November 2026 (UTC)Reply

labels for untranslated works - a candidate for mul?

[edit]

(posting here for widest visibility, will inform relevant projects)

For a work written in Czech with no English translation, what should we put in the English label, bearing in mind the WD principle that labels are for people, properties are for machines.

  1. Nothing - unless the user has Czech in their language tree, they get QXXXXXX
  2. A translation of the title, either done by manually by bilingual people or machine translation - helpful for the user, but might wrongly suggest the work content is available in that language, and should all translations be official.
  3. The Czech label - accurate, but just a jumble of letters for non Czech speakers. And do we duplicate for other languages
  4. nothing, but have the Czech label in mul, so its available to all Latin language users, but whether they get it depends on their preference for fallback/mul labelling.

My preferences in order are 4,2,3,1, what are yours?

(put aside non-Latin titles, where I could see both merit and confusion in having the mul label being that of a french edition of a Chinese work being helpful to an English speaker) Vicarage (talk) 09:51, 3 November 2026 (UTC)Reply

2,1,3-4 Pallor (talk) 10:41, 3 November 2026 (UTC)Reply
4,1,3,2 presupposing that all Latin script-default works should have a mul label (video games, albums, songs, films, TV shows, books?). —Xezbeth (talk) 10:52, 3 November 2026 (UTC)Reply
4, 3, 1, 2 Difool (talk) 11:09, 3 November 2026 (UTC)Reply
Many of these item are imported wrom czech wikisource, I can set my scripts to import czech label into mul: too for 4 JAn Dudík (talk) 12:24, 3 November 2026 (UTC)Reply
4,3 no own reseach. --Sabelöga (talk) 12:27, 3 November 2026 (UTC)Reply
4, Czech label in mul, preferably, though many times there are "informal" title translations used in discussions and those can be used too (like for example book is never officially translated but English works discussing it call it a translated title...). PARAKANYAA (talk) 17:19, 3 November 2026 (UTC)Reply
4, 1, 2, 3 ―Justin (koavf)❤T☮C☺M☯ 17:33, 3 November 2026 (UTC)Reply
Just do 4, that's what 'mul' is for. If there are official or common translations of the work name in other languages that's fine of course. ArthurPSmith (talk) 18:33, 3 November 2026 (UTC)Reply

So it looks like nearly everyone likes the mul approach, but it raises two subsidiary questions: Traditionally if we add a mul value, we remove all identical values from other labels. Now I'd say we should not do this for the Czech label, just because its presence makes it obvious that that it was the original language, without checking title (P1476) or language of work or name (P407). Do you agree? Also I often wince when people add English mul values for things that are not proper names, but that's OK here if we agree a Title is like a Proper Name, quoted in full, and don't apply the rule to mixed things, like "Heathrow Airport" Vicarage (talk) 18:58, 3 November 2026 (UTC)Reply

I would also leave the Czech label to make it clear. I think for works without official translation this is the best approach. Kordishal (talk) 19:11, 3 November 2026 (UTC)Reply
I don't think that matters much, if people have trouble figuring out the language of a mul label then the language specification on title (P1476) should resolve it. If the Czech name were used as an English, German, and French label, as well as Czech then it's not very informative about which is the "real" language anyway. ArthurPSmith (talk) 20:30, 3 November 2026 (UTC)Reply

Connect diq article to Q2813

[edit]

Hello! The article `Ford Motor Company` on Zazaki Wikipedia (diq.wikipedia.org) is not linked to Wikidata item Q2813. Could someone with edit rights please add the `zeawiki` sitelink? Thank you! Desiree Uzcategui (talk) 14:15, 3 November 2026 (UTC)Reply

Connect bat-smg wiki article to Q2813

[edit]

Hello! The article `Ford Motor Company` on Zemaiteska Wikipedia (bat-smg.wikipedia.org) is not linked to Wikidata item Q2813. Could someone with edit rights please add the `zeawiki` sitelink? Thank you! Desiree Uzcategui (talk) 14:17, 3 November 2026 (UTC)Reply

Hi @Desiree Uzcategui, could you provide the URL? I am unable to find the article.
+ Do not delete the message after it has been handled. It will be archived automatically.
(Earlier request for assistance) RVA2869 (talk) 14:40, 3 November 2026 (UTC)Reply

Hellenic Olympic Committee athlete ID (archived) (P4489)

[edit]

Hey, I'm not as savvy with this website (as one can see in my contributions), however for this identifier it appears as though it's now active again. It appears as though the intended input is a numeric of some sort, however athletes now appear as their names. I'm not sure what to do to adjust/fix. GauchoDude (talk) 18:57, 3 November 2026 (UTC)Reply

Nothing much. Is there a new property? This was for their former website. Secretlondon (talk) 19:10, 3 November 2026 (UTC)Reply
I'm not sure what that means. Their website on there was listed as hoc.gr and it is still the same website today. Would a new item/thing need to be created since they are mapped differently? GauchoDude (talk) 19:17, 3 November 2026 (UTC)Reply
@GauchoDude Yes, the website still works, but the numerical id's do not. This is usually due to a redesign of the website.
Q451077#P4489 -> https://www.hoc.gr/el/node/1148 If I open this link without the web archive, I get a 404 error.
But this does work (https://www.hoc.gr/athletes/bekatorou-sofia/)
So I suggest proposing a new property with the current/working url. RVA2869 (talk) 19:47, 3 November 2026 (UTC)Reply
Yes, that's why I came here as I'm not sure how to do any of that. I know that the new format is either "https://www.hoc.gr/athletes/IDENTIFIER" or "https://www.hoc.gr/en/athletes/IDENTIFIER" and that the old numeric system with the nodes no longer works. If it requires a new thing, I don't know how to do that. If it requires an adjustment to the current thing, I don't know how to do that either. GauchoDude (talk) 19:53, 3 November 2026 (UTC)Reply
Wikidata:PP RVA2869 (talk) 20:16, 3 November 2026 (UTC)Reply
Brother, I'm sure you meant this as helpful, but this whole part of the project is jibberish to me with the Q's and P's and whatever. I've done over 26,000 manual /non-bot edits on en.wiki over a dozen years and I've only barely touched on this side of the world. My involvement is basically only linking existing sports profiles (e.g. found at Olympics.com, Olympedia, World Gymnastics, etc.) into athletes' wikidata page(s). If you'd like to walk me through how to create this step by step, I'm more than happy to functionally hit the buttons, but that's about the extent of time I can contribute here. Even if it was created, I don't even know what happens after that and how things get actually loaded into it.
If someone would like to help, @ me, otherwise I'm just going to skip Greek Olympians as if this whole thing doesn't exist and continue working on other athletes that have these already created. GauchoDude (talk) 22:37, 3 November 2026 (UTC)Reply