Shortcuts: WD:PC, WD:CHAT, WD:?

Wikidata:Project chat

From Wikidata
Jump to navigation Jump to search

Edit

Latest label removals gone wrong?

[edit]

Hi, @JnpoJuwan removed all 'Wikidata' labels from Wikidata (Q2013) and instead added a default label 'for all languages' (this is a new wikibase feature). In effect, only a few languages now have their own special label. I don't mind this but... my default language settings are Czech and I am now getting a Slovak label 'Wikiúdaje' as the item name on top of the Wikidata item page. Can this be customized so that the first preferred item label to display on top of the page is the 'default' version of the label? Vojtěch Dostál (talk) 19:54, 8 December 2024 (UTC)[reply]

@Vojtěch Dostál oh dear, that is something weird. I do not have enough experience in the technical aspects of Wikidata, so please ping other users who are more knowledgable. JnpoJuwan (talk) 20:46, 8 December 2024 (UTC)[reply]
Similarly, removing the English label from an American company like this made third-party reusers of the data showing raw Qids. Sure, they should perhaps update to fall back to mul, but I think it is reasonable to expect a label in the language of the item even if it is the same as mul. I suggest restoring all those labels (and always keeping one would help us track why the mul one was chosen). Ainali (talk) 09:33, 9 December 2024 (UTC)[reply]
The point of having "mul" is that we can save store space by not needing to save a label in every language. ChristianKl ❪✉❫ 15:20, 14 December 2024 (UTC)[reply]
I know. My point is that we should keep it in exactly one (1) language beyond mul, not every other label. That could still remove hundreds of labels. Ainali (talk) 21:07, 14 December 2024 (UTC)[reply]
MediaWiki fallback chains
The Slovak label is presented due to MediaWiki language fallback chains where Slovak and Czech fall back on each other and only after that to the default label (mul). To my understanding these are defined for the whole MediaWiki software and not specifically for Wikidata. In most cases this fallback makes sense (e.g. if there is no Czech label for a person who's native name is writen in non-Latin characters, it makes more sense to present the Slovak translitterated label than the non-Latin default label) but in some cases like with Wikidata (Q2013) it may lead to unwanted results. I think a simple solution for these rare cases would be the best: just add a Czech label "Wikidata" to override the Slovak label and maybe add a short comment to the talk page explaining the reason for this action. Samoasambia ✎ 21:06, 8 December 2024 (UTC)[reply]
@Samoasambia Yes, I thought it's something like that, but shouldn't we set the fallback in a way that it first falls back on the default mul label, and only then on the Slovak label? Vojtěch Dostál (talk) 08:31, 9 December 2024 (UTC)[reply]
That sounds problematic when two linked languages are much closer to each other than mul, say those with different alphabets to mul. I'm not sure they've thought about this, the chain idea was new to me. Vicarage (talk) 08:42, 9 December 2024 (UTC)[reply]
We discussed whether the mul fallback should come before or after the final, implicit en fallback (and decided that it should be mul before en – except for languages that explicitly fall back to en, such as en-gb), but I don’t remember if we even considered putting mul before the language’s explicit fallbacks… to me that sounds like a strange idea. If the mul label has to be overridden in Slovak, then clearly it’s not suitable for all languages (which is fine, that’s why it can be overridden) – why should Wikibase assume that Czech speakers would be better served by the mul label than by the Slovak label, when MediaWiki says that Czech messages should normally fall back to Slovak translations (and vice versa) before English?
In the case of Q2013, I think the Czech label should not have been removed: labels should only be removed in favor of mul if that doesn’t change the displayed label, and in this case it did cause a change. If the removal was done by a bot, I’d say the bot code has to take the fallback chains into account (available in the API, by the way), though in this case it looks like it was actually done manually. Lucas Werkmeister (WMDE) (talk) 10:44, 9 December 2024 (UTC)[reply]
@Lucas Werkmeister (WMDE) All right, that sounds like a long-term solution. Let's not remove labels if the fallback chains cause Wikidata to display a different string. Vojtěch Dostál (talk) 11:13, 9 December 2024 (UTC)[reply]

Don't remove labels, we don't have any consensus for doing so and breaks stuff. Multichill (talk) 21:23, 9 December 2024 (UTC)[reply]

@LiMrBot by @LiMr seems to be doing that too, perhaps a proper bot request should be started for that instead. Vojtěch Dostál (talk) 10:58, 10 December 2024 (UTC)[reply]
a proper bot would be very appreciated. if the unintended errors by mul are patched, please request that! JnpoJuwan (talk) 11:14, 10 December 2024 (UTC)[reply]
A proper bot, or just a proper discussion and policy on this in general, even if it changes again in the future. I expect currently many integrations and tools, and data reuse by data reusers will be broken if labels in know and or expected languages are removed in any mass way or at any speed. Not to mention the issues it has and will cause with bot, scripts and people adding data. And even more so as 99% of all other wikibases do not have this code yet. ·addshore· talk to me! 16:12, 10 December 2024 (UTC)[reply]
I would note though that labels were also mass-added in many instances by bots (for example, for disambiguation pages), and there is nothing wrong with removing those. stjn[ru] 00:33, 21 December 2024 (UTC)[reply]
I have an idea to add checkboxes to each language which would affirm if that language can use mul or not. We will have economy of resources nevertheless (boolean/char/number vs. string) and correct labels with full info at the same time. --Infovarius (talk) 19:14, 22 December 2024 (UTC)[reply]

How to quickly see items that are a subclass?

[edit]

For example, when viewing or querying cannibalism (Q44595), it would show cannibalism in animals (Q908508) and Cannibalism in Africa (Q124758790).

A way to conveniently and quickly (easily so even for people new to the site) items that are a subclass of the current item would be quite useful both for the Web UI and any queries like those of the Listeria bot. Maybe this is already possible or if not there already is a proposal somewhere to add such functionality. To be clear, I'm not referring to some search query or sparql query but when it comes to the Web UI either a button or something that can be expanded to load the items directly on the page with a click. Prototyperspective (talk) 11:29, 11 December 2024 (UTC)[reply]

Maybe this relateditems (Q102435390)? It's a gadget. RVA2869 (talk) 13:07, 11 December 2024 (UTC)[reply]
Thanks, however after enabling the gadget I don't see any button on the item pages. The documentation of the gadget consists of one sentence This gadget displays related items on an item page. so that's not helpful either. How to use it? Moreover, if that enables that it's still only a gadget but I think this would a be useful as a default functionality (e.g. also for people new to the site as a key way why Wikidata and its subclasses item organization can be useful). Prototyperspective (talk) 13:42, 11 December 2024 (UTC)[reply]
@Prototyperspective If you have it enabled, then a “show derived statements” button should appear at the bottom of the page. RVA2869 (talk) 14:44, 11 December 2024 (UTC)[reply]
Okay I've suspected it may be that but that button disappears when the page is loaded. I saw it a few times before it disappeared, maybe it's because of some other gadget that hides it. Prototyperspective (talk) 14:50, 11 December 2024 (UTC)[reply]
Now I see the button after disabling the WikidataComplete script. It's an interesting gadget but it doesn't show items that have [subclass of this item] set. Prototyperspective (talk) 14:55, 11 December 2024 (UTC)[reply]
M2k~dewiki (talk) 13:54, 12 December 2024 (UTC)[reply]
Thank you! The first link is a separate site but I'm looking for something that I can directly see in the item with just a click. It also seems to require specifying things so this isn't accessible, e.g. to people new to the site or not interested in a subject enough to spend a minute just to see some related items. (Btw it rotates and I don't know how to make it stand still.)
I can't use the tool of the second link and the its site of the third link is down.
The fourth link is interesting and probably a tool that's too unknown/underused but it doesn't show subclasses of this item but only the other way around. Same for fifth link (I'm looking for the other way around). Lastly for the sixth link it's the same tool and I'm looking for something that's accessible in the sense of directly integrated/able into the item page and seeable with one or two quick clicks. I was kind of surprised that this isn't yet possible on Wikidata given how you can navigate categories on Wikipedia and the mw:Extension:CategoryTree to see subclasses directly on the page without even leaving the page. Prototyperspective (talk) 16:08, 12 December 2024 (UTC)[reply]
I have something like that for a limited set of items with my User:Jean-Frédéric/ExLudo: on video game genre (Q659563) items, the subgenres are displayed, two-level deep (as defined via P279) − see File:Wikidata user-script ExLudo.js example - genres.png. You might be able to do something like that (but I guess for some things it would be a loooong list). Jean-Fred (talk) 15:48, 19 December 2024 (UTC)[reply]

Why is Christianity low on the list when inputting "Christianity"?

[edit]

This is a question about using the web interface with English set as the current language.

On any item, when I add the property religion or worldview (P140), if I type "Christianity" into the property value, I see the following list (in order) as suggested values:

  1. Methodism (Q33203)
  2. Reformed Christianity (Q101849)
  3. Presbyterianism (Q178169)
  4. Protestantism (Q23540)
  5. Christianity (Q5043)
  6. history of Christianity (Q235329)

Questions:

  1. Why is Christianity so far down the list? Is it because these other items are more commonly used for this property, or are more widely linked on Wikidata?
  2. Why are these other items shown at all? I would expect to see an alternative label in parentheses to the right of the primary label. Indeed, for the last item, history of Christianity (Q235329) I see "history of Christianity (Christianity history)". Yet I don't see an alternative label starting with "Christianity" for these first items, so why are they displayed when I type "Christianity"?

Daask (talk) 17:07, 12 December 2024 (UTC)[reply]

The way the completion list works is a bit of mystery to most of us, and I can never find any documentation on it.
You might get a better response by asking at Wikidata:Report a technical problem. Bovlb (talk) 19:10, 12 December 2024 (UTC)[reply]
@Daask I can't reproduce what you are describing. The suggestions you mention appear BEFORE anything is typed and they are suggested based on constraint provides suggestions for manual input (Q99460987) at Property:P140. After I type "Christianity", all these suggestions are replaced by search result suggestions. Vojtěch Dostál (talk) 06:21, 19 December 2024 (UTC)[reply]
@Vojtěch Dostál: Interesting. This isn't a fluke for me. I have consistently seen this same list in the same order for at least several months, if not years. Before I type in "Christianity", Methodism (Q33203) appears way down the list. I wonder what could be causing me to experience this and not you?
That said, I think you helped me figure out what is likely causing the problem. It seems the suggester lists all items for constraint provides suggestions for manual input (Q99460987) before other search results. That makes sense. Perhaps the suggester is somehow recognizing that those items in the constraint provides suggestions for manual input (Q99460987) list are related to Christianity (Q5043), even if "Christianity" isn't in their label, and therefore is including them in the suggestions list even if their label isn't otherwise a match. Daask (talk) 20:47, 19 December 2024 (UTC)[reply]

Add label in your language

[edit]

I don't know if it's a good idea and how many people will read it, but add label in your language at and (Q12364761). Eurohunter (talk) 13:11, 14 December 2024 (UTC)[reply]

✓ Done (eo, fr) CasteloBrancomsg 17:45, 14 December 2024 (UTC)[reply]
Should this not be a lexeme instead of an item? RabbitFromMars (talk) 12:16, 16 December 2024 (UTC)[reply]
Ideally, there should be a Wikidata lexeme for every language. This item serves as "the meaning" for those lexemes. Notice that there are also some Wikipedia pages on the matter. --Matěj Suchánek (talk) 18:22, 16 December 2024 (UTC)[reply]
@RabbitFromMars: @Matěj Suchánek: There are articles in two languages and probably there could be a few redirects. Eurohunter (talk) 21:17, 17 December 2024 (UTC)[reply]
How would you like this to be disambiguated and translated for languages that have different "ands" depending on if it comes between nouns or verbs and for languages that do this using a non-independent word such as affixes? - Yupik (talk) 09:57, 22 December 2024 (UTC)[reply]

Google Knowledge Graph ID (P2671)

[edit]

How to deal with existing Google Knowledge Graph ID (P2671) entries when changing the name of an item? It seems to me that the Google Knowledge Graph ID (P2671) link has the name of the item encoded and does not work any more when the name is changed.

  • do not care (a bot will come along and fix it)
  • delete it
  • fix it (but how?)

best --Herzi Pinki (talk) 19:32, 16 December 2024 (UTC)[reply]

AFAIK it's not connected to the names and should update at their side at some point. Sjoerd de Bruin (talk) 22:29, 16 December 2024 (UTC)[reply]
I changed the name 5 days ago [1], still Google Knowledge Graph ID (P2671) resolves to the old name. best --Herzi Pinki (talk) 15:13, 21 December 2024 (UTC)[reply]
We don't have any knowledge of how often Google updates their data, that is out of our reach. Sjoerd de Bruin (talk) 15:28, 21 December 2024 (UTC)[reply]

nameGuzzlerOption.js

[edit]

How to use nameGuzzlerOption.js? I don't see any button. Eurohunter (talk) 21:18, 17 December 2024 (UTC)[reply]

I can be found by the names:
  • VIP's-Labels (en)
  • Etiquetas VIP (es)
  • Libellé de VIP (fr)
  • VIP-Bezeichnungen (de)
in the left navigation; also see User:Jitrixis/nameGuzzler.js -> title M2k~dewiki (talk) 17:47, 18 December 2024 (UTC)[reply]
When click on the ...VIP... link you get a popup like in the screenshot at d:Q23727110 M2k~dewiki (talk) 17:49, 18 December 2024 (UTC)[reply]
@M2k~dewiki: Thanks. Item nameGuzzler (Q23727110) could be linked somewhere at User:Jitrixis/nameGuzzler.js? Eurohunter (talk) 21:55, 25 December 2024 (UTC)[reply]
@Eurohunter: also see
With the introduction of
in July 2024 the single mul-label and aliases (multiple languages) could be used instead of the nameGuzzler. M2k~dewiki (talk) 22:02, 25 December 2024 (UTC)[reply]

Creating second statement with the same property and value but with different qualifiers

[edit]

I've been using QuickStatements to add described by source (P1343) with pairs of URL (P2699) and title (P1476) qualifiers. But I can't use it to add a second described by source (P1343) with a different pair of qualifiers as you'd want if a subject is described at 2 places at the same source (eg the 2 sides of the Battle of Antietam (Q719252)). Help:QuickStatements#Limitations states it cannot 'add a second statement with the same property and value but with different qualifiers, since additional qualifiers will be added to the first statement'. Is there another way of doing this automatically? Vicarage (talk) 10:51, 18 December 2024 (UTC)[reply]

@Vicarage OpenRefine has three matching modes (https://openrefine.org/docs/manual/wikibase/schema-alignment#matching-strategy); perhaps one of them would be suitable for you? Vojtěch Dostál (talk) 06:14, 19 December 2024 (UTC)[reply]
Wikibase-CLI using the add-claim command in batch mode would be an option. Infrastruktur (talk) 19:28, 19 December 2024 (UTC)[reply]

Anachronisms. Sort of …

[edit]

I created today a template on frwiki that generates a link to histropedia with all the items with articles on frwiki with "date" or "begin data" / end date". This gives links like these :

It's a bit slow for countries with a lot of articles like the USA, but it works (not all the time).

Anyway do we agree that items with "begin date" with a value beforre year -1000 like these one https://w.wiki/CTQg should definitively have no country (P17) View with SQID statement for sure and that we should mass remove them ? Maybe we could find another property to link geological entities to where they are relevant / found geographically now ? author  TomT0m / talk page 17:15, 18 December 2024 (UTC)[reply]

A good first step might be to deprecate the country statements with a reason for deprecated rank (P2241) with value contemporary constraint issue (Q74557669) or similar. Then create queries on those deprecated statements as part of a cleanup project. Can you link to some items that contain anachronistic statements so I can better understand your concerns? William Graham (talk) 18:46, 18 December 2024 (UTC)[reply]
@William Graham Just click on the query above or this one with labels, items with begin dates < -1000 and a "country" statement. For example Q17640515, a geological era 66 millions ago, with country (P17) View with SQID "France", which does not make any sense.
I'm not sure the deprecation step is needed as it seems mainly automated imports from enwiki as a source, from infoboxes, without checking, or anachronisms. author  TomT0m / talk page 20:00, 18 December 2024 (UTC)[reply]
I don't read French and the interface on that website is very confusing to me. William Graham (talk) 20:07, 18 December 2024 (UTC)[reply]
@William Graham The query is on the query service, I did not mean one of the queries I posted initially, there are links in my comments (the blue one).
Anyway, I translated one of a query with not a lot of items : timeline of articles on enwiki (by their titles) which are about north Korea or North Korea participated in I chose the country because there are not much articles, so it should be easier to understand (and the query is fast). Drag and drop to move the timeline before/after (or click on the arrow buttons). Zoom in/out (or click on the magnifier) on the with the mousewheel to change the scale and get more details about a period of time. More article should appear and the time scale should get shorter. The articles are prioritized, the more sitelinks their items have, the earlier they shows.
But it's not very convenient when there are articles with like "66 millions years ago" because the initial zooming is at a geological scale, so to get to relevant information you have to go to present time and zoom a lot, which can be indeed very confusing. The ticks "event category" on the left let you filter event types, a bit, guessed by the query. clicking on "event category" itself let you chose by type of sport, for sports events, instead. author  TomT0m / talk page 20:27, 18 December 2024 (UTC)[reply]
EDIT: Query corrected, sorry, made some typos when adapting to english correctly. author  TomT0m / talk page 20:30, 18 December 2024 (UTC)[reply]
Why not replace country (P17) with located in the present-day administrative territorial entity (P3842)? I had a long argument with people about Wikidata:Requests for comment/Current or contemporary location and country for events. I think country (P17) should have a strong contemporary constraint imposed, but its a huge task as its been so abused, and my opposition were intractable. Vicarage (talk) 22:40, 18 December 2024 (UTC)[reply]
Yes that should be a good solution in some cases. Not sure about the geological eras however, as this could mean "we can find rocks/sols created at the time on the country". author  TomT0m / talk page 15:07, 19 December 2024 (UTC)[reply]

Could use some help setting up a schema

[edit]

This is my first time setting up a schema within Wikidata and could use some help. It concerns Wikidata:Schema proposals/virtual tour I myself am not sure which properties I should add and which value/qualifiers I should use for certain properties. Through Wikidata:Requests for comment/Schema virtual tour, I have already tried to get help but without success for now. Could one of you help me create the schedule for the virtual tour? Brechtd (talk) 11:34, 19 December 2024 (UTC)[reply]

iTunes genre items

[edit]

Hello, is Textbooks > Engineering > Computer Science (Q110593679) correct modelling suitable for Wikidata? From my point of view, this concept should just be merged to computer science (Q21198). Instances of iTunes Textbooks genre (Q110592261) do not belong to Wikidata, it's a bit as if we'd be making items for Amazon product categories. For example, we don't create items which are instance of 'Quota Topic', instead, we add the Quora topic ID (P3417) to normal items. Ping @Germartin1, creator of the item. Vojtěch Dostál (talk) 14:54, 19 December 2024 (UTC)[reply]

 Support. author  TomT0m / talk page 15:05, 19 December 2024 (UTC)[reply]
I don't see a reason for these types of items to exist. Ideally topics and genres would have sales platform agnostic items only of the last tuple (i.e. "computer science"). William Graham (talk) 15:42, 19 December 2024 (UTC)[reply]

Merge Sailor Moon video game pages

[edit]

Hi, Sailor Moon (Q30314507) and list of Sailor Moon video games (Q291058) should be merged. They talk about the same thing. Edo999 (talk) 15:02, 19 December 2024 (UTC)[reply]

A topic (the Sailor Moon game series) and a Wikimedia list item (list of Sailor Moon video games) are distinct concepts. One item sitelinks to encyclopedic prose articles on the topic and the other item sitelinks to Wikipedia list pages. I don't think that they should be merged. William Graham (talk) 15:30, 19 December 2024 (UTC)[reply]

Penalty score

[edit]

Hi! How to specify the penalty score for a football match (Q268567, Q55659738)? Maybe we should suggest a new property for the score? Mitte27 (talk) 16:53, 19 December 2024 (UTC)[reply]

From Special:WhatLinksHere/Q2691960 I found Q55350317#P1363 where match interval (P6887) is a qualifier for points/goal scored by (P1363). For the score I found Q4597128#P1923 but I'm not sure about that as score method (P1443) only works as a qualifier for one of the number of points/goals/set scored (P1351) qualifiers, not for the participating team (P1923). Peter James (talk) 17:13, 19 December 2024 (UTC)[reply]
I think @Mitte27 has asked about the second usage, the score — unfortunately I think this example is not viable, because there score method (P1443) is a qualifier for Nigeria men's national football team (Q181930) and Cameroon men's national football team (Q175309) values, and not a qualifier for the number of points/goals/set scored (P1351) qualifier's second value. Well very well (talk) 11:49, 20 December 2024 (UTC)[reply]

Possible interaction restriction

[edit]

Kind regards. Given previous and lengthy cross-wiki disputes between User:WMrapids and I, as well as interaction restrictions in some cases, I wanted to ask about the possibility about endorsing one here. Whether this would be voluntary or not, I don't know. Kind regards, NoonIcarus (talk) 19:27, 19 December 2024 (UTC)[reply]

I will agree to an interaction ban if this is possible. Apologies for the interaction on one of the items, I forgot that you had made it! WMrapids (talk) 03:53, 20 December 2024 (UTC)[reply]

Fallback language view

[edit]

in the current Wikidata editor, fallbacks should be more obvious when viewed in editor mode. firstly, the fallback languages should be more easily accessible when viewing the page in other languages which fallback to it. take for example, viewing Wikidata in Brazilian Portuguese (pt-br): it by default fallbacks to Portuguese (pt), but the view it shows currently is:

  • Brazilian Portuguese
  • English
  • Translingual
  • (other languages with codes between a–p) ...
  • Portuguese
  • (other languages) ...

secondly, when a description or alias falls back to another language, it should likely be shown in grey (as currently happens for labels). without these, it makes it harder for multilingual editors to check what falls back to what and how to fix these. Juwan (talk) 14:56, 20 December 2024 (UTC)[reply]

Font for translingual text

[edit]

the current font for the translingual (mul) labels and aliases does not match the defaults for a given user. I have all my defaults as Noto fonts and translingual shows up as a jarring Arial. some users have implemented some personal fixes but this should ideally be implemented globally. Juwan (talk) 14:59, 20 December 2024 (UTC)[reply]

Default values for non-Latin names

[edit]

regarding the default values for all languages, how should names in non-Latin scripts be managed? currently, I have been setting the most common Latin transcription as the main label and other transcriptions and the original script as aliases. I am sure that other people may disagree, so I wish to ask for comment. Juwan (talk) 21:52, 20 December 2024 (UTC)[reply]

The help page says for people: "Use the name in native language and native script as the default value". Please do not add Latin transcriptions as mul labels for persons whose native language name is non-Latin. Samoasambia ✎ 22:19, 20 December 2024 (UTC)[reply]
@Samoasambia my mistake! I have overlooked that, I will correct that going forth. I assume that transcriptions should be fine in the alises, however, right? asking as you reverted those edits at Zhu Xi (Q9397). Juwan (talk) 22:26, 20 December 2024 (UTC)[reply]
I don't think we have any consensus about non-native mul aliases of people, and that's why I would avoid making any large changes for now. The only point of aliases is to help items to be found with different search queries, and for search it does not matter in which language the alias is in. Also, mass removal of non-mul labels is discouraged as it may cause some issues in some languages, see: this earlier discussion. Samoasambia ✎ 22:40, 20 December 2024 (UTC)[reply]
@Samoasambia I was part of the previous discussion, so I got familiar with that. for right now, I wish to gather more consensus on how to continue with the translingual values. as you have more knowledge than me, would you mind starting a larger discussion (or RFC) about this? cheers! Juwan (talk) 22:47, 20 December 2024 (UTC)[reply]
Since there will be minor differences in latin transcriptions would that not defeat the purpose of putting them in the mul aliases? Instead would it not be proper for each transcription to go to their language's aliases? Infrastruktur (talk) 23:20, 20 December 2024 (UTC)[reply]
@Infrastruktur transcriptions are supposed to be for the given language, not in any another language. the differences come from there existing different systems. pinyin and Wade-Giles are both transcription systems for Mandarin Chinese and both are commonly used (typically pinyin for newer subjects and WG for older ones). unless, you are suggesting adding Latin transcription to the Chinese fields. Juwan (talk) 23:41, 20 December 2024 (UTC)[reply]
I suggest adding transcriptions to the translingual fields as these may be more easily edited by others and trickle down to other languages automatically. so instead of having them all in the English field and many copies in other languages, they are stored more centrally.
to connect back to the start of this thread, if there was a consensus to add Latin script to the label, this would also permit using up less space for most languages using Latin script, as names are typically just transcribed and shared between langauges. Juwan (talk) 23:47, 20 December 2024 (UTC)[reply]
The current guidance seems to be slightly bad on this point. Only Latin languages have a uniformity between in them in how certain names are rendered. Even Cyrillic, which is mostly used in the former Soviet Union, has a lot of differences, especially for non-Russian names. It doesn’t make sense to tie this exclusively to native language/script, since for most of names in non-Latin languages, they are not going to be multi-language labels. stjn[ru] 00:36, 21 December 2024 (UTC)[reply]
 Agreed with this. Juwan (talk) 03:32, 21 December 2024 (UTC)[reply]
I don't really understand what you mean. What is your suggestion? D3rT!m (talk) 17:36, 21 December 2024 (UTC)[reply]
The aim of mul is to reduce duplication. And the big source of duplication is in the latin alphabet formulations shared across so many languages. So while a name that is natively in Chinese, Cyrillic etc should be fully recorded, the mul version should be a Latin one. Vicarage (talk) 18:15, 21 December 2024 (UTC)[reply]
The default label should never be a transliteration. If you want it to be a Latin-only label then that's what it should have been called in the first place. —Xezbeth (talk) 06:14, 22 December 2024 (UTC)[reply]
Default labels from Wikidata’s standpoint are and will always be in English anyway (so, in most cases, transliterations), so this sort of objection is a bit moot. stjn[ru] 11:34, 24 December 2024 (UTC)[reply]
The term "default values" should have been replaced with something like "default values for Latin script" or a more specific term. Since "default" is a general term, it can cause misunderstandings for editors working with non-Latin scripts. Afaz (talk) 23:39, 24 December 2024 (UTC)[reply]

Luigi Mangione (Q131411648)

[edit]

It's rather pointless to have an item about this person if editors keep statements related to the killing without explanation. Can we at least discuss it before removing statements? Trade (talk) 01:23, 21 December 2024 (UTC)[reply]

Most people will probably not read the talk page, only thing that helps is reverting or protecting the item. Sjoerd de Bruin (talk) 12:22, 21 December 2024 (UTC)[reply]

Wikidata connection for pam: Wikipedia

[edit]

Could somebody time run a bot at pam: Wikipedia? There are a lot of biographical articles without interwiki. There are no manual interwiki links, but maybe one could found them with scripts (as articles' names are identical as at en.wikipedia). Hugo.arg (talk) 20:52, 21 December 2024 (UTC)[reply]

Should be a quick round of Duplicity (I think you meant pamwiki) Sjoerd de Bruin (talk) 21:02, 21 December 2024 (UTC)[reply]

Yes, sorry, it's :pam Wikipedia. But I can not see how this tool makes it faster than doing it manually. Hugo.arg (talk) 07:50, 22 December 2024 (UTC)[reply]

The first result should be most of the time the item you need, so it's just a quick visual check and then hit the button that is always on the same place without leaving the page. Sjoerd de Bruin (talk) 08:50, 22 December 2024 (UTC)[reply]

But in this case I don't check them anyways - it's enough to see an interwiki list to understand is it about the same subject. If the program could work from the list of unconnected pages, without needing to copy page names or opening something, just clicking 'connect', then it would be very helpful. Hugo.arg (talk) 14:55, 22 December 2024 (UTC)[reply]

But it does work by just clicking "connect" (at least for me). Amir E. Aharoni {{🌎🌍🌏}} talk 23:06, 23 December 2024 (UTC)[reply]
(I mean, just clicking "Add to Qnnn", but it's the same thing.) Amir E. Aharoni {{🌎🌍🌏}} talk 23:07, 23 December 2024 (UTC)[reply]
I wrote the previous message about 20 minutes ago, and since then I added about 40 sitelinks using this tool. Some of them were very quick, with one click. For some others, I had to invest some thought or manual searching or to do a bit of extra cleanup. The funniest case was that the tool's first suggestion for Douglas Adams was Douglas Adams (Q28421831) and not Douglas Adams (Q42). Check my contributions to pamwiki and to Wikidata. I honestly cannot think of anything more efficient than this.
@Sjoerddebruin: Thanks for the link, it's a very good tool.
@Hugo.arg: I hope you try it again ;) Amir E. Aharoni {{🌎🌍🌏}} talk 23:34, 23 December 2024 (UTC)[reply]
Ah, finally I got how it works. Now it's easy. Thank You! Hugo.arg (talk) 08:04, 24 December 2024 (UTC)[reply]

Commons categories and notability

[edit]

Under our current notability criteria, it's sufficient (for a non-category item) to have a single sitelink to a Commons category. This means that those wishing to create items about themselves simply have to find or upload personal photographs to Commons, add a category tag, and create the category. To delete the resulting Wikidata item, we have to first get all of those photographs deleted, and then the category. This takes a lot of time and effort from volunteers. Is this how we intend the system to work? How could it be improved? Bovlb (talk) 22:05, 21 December 2024 (UTC)[reply]

Thanks for bringing this up, I think we should change this. Could we just delete this criterion regarding Commons categories? --Dorades (talk) 22:35, 21 December 2024 (UTC)[reply]
It would be more like adding a new exclusion to N1 (or rewriting N1.4). Bovlb (talk) 23:09, 21 December 2024 (UTC)[reply]
This is basically what Commons users have lobbied for a few years ago, quite intensively, when they rolled out the fully automatic Wikidata infobox to the majority of category pages.
The remaining open point (for years) is that there is no coordinated effort to get these situations resolved with a mutual deletion of unwanted material, because here we claim that there is notability as long as there is usage at Commons, and at Commons they claim there is notability because the media is being used at Wikidata. If there was a suitable process to deal with these cases, and both Wikidata and Commons participate in this process, then I think the situation would be much more bearable. —MisterSynergy (talk) 22:36, 21 December 2024 (UTC)[reply]
Imagine that we had some mechanism to tag an item as "this only qualifies as notable because of its sitelinks". This could be used in the Commons case, and also in the related case where people add spam articles to smaller Wikipedias. This tagging would indicate to other projects (say Commons) that they should not preserve things on their side for the benefit of Wikidata. We could also have some process for detecting that a tagged item has no sitelinks left so it could become a candidate for deletion. Bovlb (talk) 23:08, 21 December 2024 (UTC)[reply]
We could also have some process for detecting that a tagged item has no sitelinks left so it could become a candidate for deletion. Dexbot kind of does that, cf. Wikidata:Requests for permissions/Bot/Dexbot 13. --Dorades (talk) 12:57, 22 December 2024 (UTC)[reply]
According to the criteria Q91949506 and Q93303092 should not have been deleted, as they had Commons sitelinks and links from other items. Commons:Category:William Little Brown only has pages from the census but looks like it will be kept. A Commons sitelink should be enough if the category is in scope for Commons and is not just used for Wikidata. "at Commons they claim there is notability because the media is being used at Wikidata" - any evidence? Would the inclusion of a link to a Wikidata deletion request in the Commons deletion request be enough to overcome this type of objection? And I think that if there is a change, the exclusion to notability should only apply to certain types of subject (similar to en:WP:A7) - those that are likely to be out of scope for Commons or are hoaxes. Peter James (talk) 12:33, 22 December 2024 (UTC)[reply]
commons:Commons:Category inclusion criteria (as essay) says: "Get the Wikidata item deleted for failing Wikidata:Notability (remember 2 or 3 may still be satisfied) but if the 1st step isn't done (or fails) the Wikidata item will not be deleted. If its pointed out at the deletion request for the Wikidata item that the topic has a Commons category and some images then point to this section explaining the deletion of the WD item needs to happen first.". This explicitly requires the Wikidata item to be deleted first, whereas our notability criteria require the Commons category to be deleted first. Bovlb (talk) 00:15, 23 December 2024 (UTC)[reply]
That's only an essay, and it's advice rather than requirement. There is commons:Commons:INUSE for files, but a Wikidata item often only needs one file so a category with only Wikidata is unlikely to have many INUSE files. I don't know if there is a similar policy or guideline for categories. Peter James (talk) 01:23, 23 December 2024 (UTC)[reply]

Splitting a property in two

[edit]

I started a discussion on the talk page of this property P12379 (protected heritage site in Brussels (web version) ID) about splitting the item up into a buildings ID and streets ID property. Jhowie Nitnek 12:28, 22 December 2024 (UTC)[reply]

Trying to get a consensus on English label for Q30 -- "United States of America" vs "United States"

[edit]

Currently the label for United States of America (Q30) is "United States of America", which is the official name, however the wide usage is simply "United States". There has never been a consensus established in spite of several edit wars and a couple of attempts to establish consensus.

Background

[edit]
  • At the dawn of time the label was entered as "United States", but was changed in Feb 2013 (without consensus) to the official title, "United States of America"
  • Since then there have been multiple edits made between the two titles, including an apparent edit war in 2017 followed by an edict issued (without consensus) on the talk page to "Stop shortening English label", which was further followed by a (not particularly productive) discussion here on the Project page that also failed to reach consensus
  • It appears another minor edit war broke out in 2020 and (not counting vandalism) some smaller skirmishes pop up occasionally
  • In Dec 2023, a topic was posted on the talk page with a desire to shorten the label to "United States" and so far it was three additional "Support" comments and no "Oppose", but I think given the scope of the disagreement a more public discussion here on the Project Page is warranted so it can then be referred to on the talk page
  • To be clear, there has never been a consensus on the label either way -- despite the visibility of the topic, the length of time it has been kept as "United States of America", the persistence of the reversions back to "United States of America", and the edict issued (without consensus) on the talk page, there has never been a consensus on "United States of America" or "United States", as evidence by the amount of good faith edits (not vandalism) that have occurred over the label since the item's inception nearly 15 years ago

Proposal

[edit]

While trying to get a clear consensus, I am proposing to change the label to the shorter and more commonly used "United States" over the "United States of America" on the basis that it overwhelmingly better follows Wikidata's general principles for labels:

  • "Reflect common usage" -- "United States" is far more common than the official name "United States of America"
  • "Labels can be ambiguous" -- it has been pointed out that the shortened "United States" label could potentially be confused with the "United States of Mexico" or "Republic of the United States of Brazil", etc., however the labels for those countries are not the fuller versions themselves to avoid ambiguity with the United States of America, instead they are their common referred to names of Mexico (Q96) and Brazil (Q155). It has even been mentioned "United States" is too similar to "United Kingdom", although that's a stretch someone would need to specify "of America" to avoid confusion between the two.
    • In the vast majority of contexts, "United States" is not ambiguous
    • But even to the extent that it could be ambiguous, the reference is usually obvious (there are many examples of an ambiguous title with an obvious reference, such as London (Q84))
    • And furthermore, even if it was ambiguous, the label guidance explicitly states "Disambiguation information belongs in the description", so the label is not the appropriate place to disambiguate anyway
      • As an aside, would the following exchange be anything short of humorous (if not frustrating)? You -- "I visited the United States this past summer"; Me -- "of Brazil, of Mexico, or of America? Or did you mean United Kingdom?"
    • Summary -- In the vast majority of contexts "United States" is not an ambiguous reference in the least, but even if it was the label is not the proper place to disambiguate
  • "Wikimedia page title may give orientation" -- while not required to be the Wikipedia title, the clear bias is toward the Wikipedia title itself rather a variation of the Wikipedia title
    • "To figure out the most common name, it is good practice to consult the corresponding Wikimedia project page (for example, the title of a Wikipedia article). In many cases, the best label for an item will either be the title of the corresponding page on a Wikimedia project or a variation of that title"
    • Over 20 years ago this same issue was settled in favor of "United States" through consensus at Wikipedia for many of the same reasons that are being offered here
    • While the Wikidata label does not have quite the same criteria as a Wikipedia title, Wikipedia's article title guidance of 1) Recognizability, 2) Naturalness, 3) Precision, 4) Concision, and 5) Consistency are all satisfied with "United States" and those are solid criteria to use for this particular decision as well
    • The edit history has misplaced the defense of the label -- the label should be "United States" by default unless a consensus was reached to adopt the "United States of America" variation, which never occurred
      • The favored label should have been the Wikipedia title ("United States") and it should have been the label from the beginning (and it was...)
      • All subsequent changes of the label to "United States of America" have been made without consensus, even if the label currently stands at "United States of America"
      • The lack of consensus should mean reverting to the Wikipedia title and the original item label, which is "United States"
    • Summary -- both "United States" and "United States of America" technically fit this criterion, but the Wikipedia title ("United States") should prevail unless the advocates of the variation ("United States of America") make the compelling case for consensus otherwise, which has not been done aside from tirelessly preserving the change from "United States" to "United States of America" made (without consensus) in 2013

Discussion

[edit]

Please reserve discussion for below and indicate either  Support (change label to "United States") or  Oppose (keep label "United States of America"), preferably with brief rationale if needed.

This may have many comments, so please indicate either  Support or  Oppose so that a consensus can clearly emerge visually.

I think the norm is to let this simmer for a couple of weeks (which would be Jan 6, 2025) before concluding what the consensus is or whether one was reached.

However -- if anyone here is more familiar with how consensus is normally reached, please correct me! Lorenmaxwell (talk) 16:26, 23 December 2024 (UTC)[reply]

 Support I was going to support the fuller USA title, but your argument is very convincing and it makes sense to match/defer to Wikipedia's title anyway. I am in favor of using "United States". Nicereddy (talk) 18:23, 23 December 2024 (UTC)[reply]
 Support As I generally use State, United States in a place located in the country, I don't think it should be different for the label. --Fralambert (talk) 19:04, 23 December 2024 (UTC)[reply]
 Support and I routinely trim "of America" off of English descriptions of U.S.-related items as I encounter them. Most of them were added by bots based on the United States of America (Q30) label. Minh Nguyễn 💬 23:14, 23 December 2024 (UTC)[reply]
 Oppose For me it takes longer for my brain to parse when the word "America" is removed. --NoInkling (talk) 23:30, 23 December 2024 (UTC)[reply]
 Support. The label should be the common name, not a disambiguated name, and clearly ‘United States’ is a common name here (since it is the name of the page in Wikipedia etc.). stjn[ru] 11:35, 24 December 2024 (UTC)[reply]
 Support as the common name. Nikkimaria (talk) 14:35, 24 December 2024 (UTC)[reply]
 Support Well reasoned nom, match long established enwiki title, preferable to display. Hameltion (talk) 20:46, 25 December 2024 (UTC)[reply]

Wikidata weekly summary #659

[edit]
Here's your quick overview of what has been happening around Wikidata in the
week leading up to 2024-12-23. Missed the previous one? See issue #658

Discussions

Events

  • Ongoing: Wikidata Cleanup 2024 - Romaine continues his initiative, "Wikidata Cleanup," to coordinate community efforts in addressing the problem of items missing basic properties during the last ten days of 2024, when many users have extra time due to holidays. The aim is to improve data quality by focusing on ensuring all items have essential properties like "instance of" (P31) or "subclass of" (P279), adding relevant country and location data, and maintaining consistency within item series.
  • Upcoming events: Data Reuse Days - online event focusing on projects using Wikidata's data, 18-27 February 2025. You can submit a proposal for the program on the talk page until January 12th.

Press, articles, blog posts, videos

Tool of the week

  • Flying Dehyphenator is an Ordia game. Given the start part of a word, use the spacebar to move the word and hit the next part of the word. Only hyphenations described with the Unicode hyphenation character work.
  • Want a wrap of your Wikidata activities in 2024? Wiki Year In Review has it for you! (use www.wikidata.org for the project URL)

Other Noteworthy Stuff

  • Wikibase/Suite-Contributing-Guide: Wikibase Suite's contributing guide has been published. This guide aims to help anyone who wants to contribute and make sure they are equipped with all the relevant information to do so.

Newest properties and property proposals to review

You can comment on all open property proposals!

Did you know?

Development

  • With the winter holidays upon us, the development team is taking a break, and there will be no deployments for Wikidata during this time.

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

Wikidata languages (in particular Tigre)

[edit]

How is it decided/changed which languages are available on Wikidata? I tried to make a link to Tigre Wikipedia (Q131443928), but it seems that Tigre (Q34129) is not available on Wikidata. At least, not in the list of Wikipedias. - Andre Engels (talk) 19:11, 23 December 2024 (UTC)[reply]

I think you might be better to raise that at WD:Report a technical problem Bovlb (talk) 19:42, 23 December 2024 (UTC)[reply]
Something like this?
https://www.wikidata.org/w/index.php?title=Q131443928&diff=2290841214&oldid=2290839975
I don't know if the translation is correct. (I used google translate) RVA2869 (talk) 19:43, 23 December 2024 (UTC)[reply]
The Tigre Wikipedia is new and not fully set up yet - phab:T381379. - Nikki (talk) 09:32, 24 December 2024 (UTC)[reply]

Request for Oversight

[edit]

As required by Wikidata:Oversight, I am notifying the community that a new request for oversight has been filed. Please see the request at Wikidata:Requests for permissions/Oversight/Ameisenigel. Thanks, --Ameisenigel (talk) 22:16, 23 December 2024 (UTC)[reply]

Merge help requested

[edit]

Item:Q23137558 and Item:Q69493382 (Richmond Public Library System) need to be merged, but I am not sure how to go about that. Any assistance would be appreciated. JuxtaposedJacob (talk) 16:24, 24 December 2024 (UTC)[reply]

 Not done. Richmond Public Library Main Library (Q23137558) is an individual library branch, while Richmond Public Library (Q69493382) is the library system. — Huntster (t @ c) 16:53, 24 December 2024 (UTC)[reply]
[edit]

Hello! Wikidata items for years ranging from 1 to 2030 should be updated so that the shwiki sitelink contains a dot at the end. For example:

  • 2020 (shwiki, redirect) -> 2020. (shwiki, article)

I tried to do it manually, but the Wikidata user interface couldn't recognize my edit. I tried QuickStatements as well, with no result. The only way I could update the sitelink manually was by removing the old link and adding the updated one subsequently, just like here. That's really strange.

Thanks in advance, Aca (talk) 13:21, 25 December 2024 (UTC)[reply]

Retrieved from "https://www.wikidata.org/w/index.php?title=Wikidata:Project_chat&oldid=2291377348"