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

Wikidata:Project chat

From Wikidata
Jump to navigation Jump to search

Allowed-entity-types constraint

[edit]

Hi everyone, I am new-ish to wikidata and describing commons uploads on wikidata. What is the allowed-entity-types constraint? For example on File:2022 Australian federal election Wright alluvial diagram.svg and commons:File:World War II Allies to Axis GDP Ratio.svg.

On the alluvial diagram pages (one for every seat) I have office contested (P541): member of the Australian House of Representatives (Q18912794), with qualifier electoral district (P768): Wright (Q2594455) (or whatever seat it is)

On the allies to axis chart, I have category combines topics (P971): World War II (Q362) & economics (Q8134)

Both of these say allowed-entity-types constraint, saying "The property should not be used on this type of entity, the only valid entity type is Wikibase item.". Can someone explain? I have tried reading the help pages, although I don't really understand still. Is it because they are images not items? How would I otherwise describe these in a structured data way, or should I just be not going that deep with it? MarkiPoli (talk) 15:02, 30 November 2024 (UTC)[reply]

@MarkiPoli: I don't understand why you're getting that error, but maybe somebody with more experience with the Commons structured data should comment. But to answer the question on entity types - it's basically within Wikidata determined by the prefix letter. Qxxx is a Wikibase item, Pxxx is a Wikibase property, Lxxx is a lexeme, etc. ArthurPSmith (talk) 16:00, 2 December 2024 (UTC)[reply]
Properties have statements indicating where and how they are intended to be used. Properties like creator (P170) or copyright status (P6216) have the statements property constraint (P2302)allowed-entity-types constraint (Q52004125) with the values Wikibase item (Q29934200) (use on Wikidata items) and Wikibase MediaInfo (Q59712033) (use in Structured Data on Commons). The properties you used on those files, on the other hand, weren't created or intended to be used on Commons to model the content of files. So they don't have the Wikibase MediaInfo (Q59712033) value and throw an error when used there.
category combines topics (P971) for example is intended for use on Wikidata items about categories, not on files. You'd probably have to ask over on Commons (commons:Commons talk:Structured data) about how they want to model this kind of file content. It's indeed possible that the Commons community didn't think about modelling the contents in such a detailed way. --2A02:810B:581:C300:FD46:81F6:126F:B70E 07:19, 4 December 2024 (UTC)[reply]

Merge of Q74524855 and Q71538638

[edit]

Recently, User:Daask merged most frequent value (Q74524855) (before: "most frequent value") and most frequent value (Q71538638) (before: "generally used form"). I wonder if that was right since Q7452455 was defined as being a facet of (P1269) point estimation (Q1192065), while Q71538638 was a facet of (P1269) name (Q82799). What do you think? Dorades (talk) 16:48, 30 November 2024 (UTC)[reply]

I don't know if point estimation (Q1192065) should have been there, but Q71538638 was originally only about forms of a name, not for other values, although it was being used in other ways, in some cases where Q74524855 would have been better. Peter James (talk) 20:48, 30 November 2024 (UTC)[reply]
I feel like both have the same meaning as Wikibase reason for preferred rank (Q71533077) and can't think of an example where it's worth distinguishing the two concepts. ChristianKl15:50, 4 December 2024 (UTC)[reply]

This conversation should also cover generally used form (Q112627455), of which I was previously unaware, but seems largely identical to the pre-merge Q71538638. The statement generally used form (Q112627455)subclass of (P279)role (Q4897819) seems wrong in any case. @عُثمان: Pinging item creator for their input, but looking at the page history it seems like a duplicate created in a different language.

Returning to the remarks above, I don't see any utility in having a separate item specifically for name (Q82799) or personal name (Q115642094), if that's the issue.

Let's consider some of the ways these items are used on Wikidata:

Description of meaning Examples
These are typical uses of "most frequent value". These are preferred because they are most commonly used in the way a value for this property is typically used (not in databases and records, unless that is the typical use for this property). They are used on items where a single value is expected to some degree.
Uses where there are multiple different values for a property which accepts multiple values, but one or some of these values are significantly more commonly used in the way a value for this property is typically used. I'm not sure this use of preferred rank is appropriate. I've started a discussion about given name (P735) of John Coltrane (Q7346) at Wikidata talk:WikiProject Names § Marking commonly and uncommonly used given names.
These mean something like "other statements are true, but would be misleading by themselves because this/these preferred statement(s) are the overwhelming majority. I feel like this should be a new item, but I'm not sure what to call it. I'm not sure what "use" would mean for the values of these properties, although they are intuitively similar to the last group.
A case where the description of "generally used form" seems apt, where there are two versions of what is regarded as the same name. In Wikidata terms, the values of the property could be linked together using said to be the same as (P460) and another database might merge them, but Wikidata has chosen to have separate items for the separate forms. I think "most frequent value" is appropriate for this meaning, but a separate item "most common form among related values" would be more precise. This could be a case for reverting the merge.
Uses for a personal name in the sense of "most frequent value" where the alternatives are not alternative forms of the same name and "most common form among related values" would not be appropriate.
These database records are "most frequent value" in the sense that they are most frequently used in the referenced external database itself, which is, I suppose, the way a Open Library subject ID (P3847) is typically used. "generally used form"/"most common form among related values" in the sense described above also makes some sense. However, I think most complete record (Q105749746) and/or most linked record (Q131399043) is most appropriate for these, and all Open Library subject ID (P3847) items using "most frequent value" should be replaced with those.

(most complete record (Q105749746) and most linked record (Q131399043) are essentially synonymous in this case, where the record is entirely generated from record linkages. When the record includes both metadata and linkages, they are sometimes different. Even with purely generated records, most linked record (Q131399043) could also include incoming links to the record from external sources in its consideration.)

This is about most widely linked/frequently used value on Wikidata/Wikipedia. I think this is an improper use of any of the items or meanings we've discussed, but I'm not sure what would be. Should we use most complete record (Q105749746) where the object isn't an external record but is a Wikidata item?
This seems to mean something like "conventional level of precision". In my opinion, this would be a different item than any of the aforementioned meanings. However, while it's conceptually coherent and distinct, I don't think this is actually a reason for preferred rank that we should use on Wikidata, and instead would make the alternative the preferred rank using most precise value (Q71536040) in every case. It appears on a number of items, though, so obviously others disagrees with me.
I just replaced a number of uses of most frequent value (Q71538638) with best referenced value (Q98386534), where editors seem to have understood it as "most frequently used in known sources"

I'm not sure what I recommend about all this, but don't want to delay sharing my thoughts and findings any longer. Daask (talk) 23:02, 6 December 2024 (UTC)[reply]

Do we have this Wikidata:Property proposal/role named as but for movies?

[edit]

I was recently notified about Wikidata:Property proposal/role named as which is about video game credits. Do we already do something like this for movie cast in how their roles appear in the movie credits? SuperUltraHardCoreGamer (talk) 10:21, 1 December 2024 (UTC)[reply]

No Trade (talk) 16:47, 6 December 2024 (UTC)[reply]

Date of Women and Men vote suffrage

[edit]

We can probably use Wikidata to store the date when women+men suffrage was introduced by each country.

How to do that? Where to discuss this?

At the moment I'm proposing something like this.

To say Australia=1902 and Switzerland=1990 we could do:

Thanks for your opinion dear Wikidata hackers --Valerio Bozzolan (talk) 13:28, 1 December 2024 (UTC)[reply]

P.S. thanks to "Nikki" for the above tip from Wikidata Telegram chat https://t.me/c/1224298920/137467 Valerio Bozzolan (talk) 13:30, 1 December 2024 (UTC)[reply]
There are a lot of event that you could possibly store on the items of countries, but Wikidata is not doing well with having thousands of statements. I would rather have an item about the introduction in a given country and give that item the relevant statements. ChristianKl01:13, 2 December 2024 (UTC)[reply]
Introducing 200 new items seems less efficient than 200 statements. But it might be better adding those statements to introduction of universal suffrage for men and women (Q131367891) with country (P17) qualifiers than start a trend for adding events to countries, which could be huge and make the item unreadable Vicarage (talk) 01:30, 2 December 2024 (UTC)[reply]
@Vicarage: What property do you suggest? --Valerio Bozzolan (talk) 06:59, 2 December 2024 (UTC)[reply]
introduction of universal suffrage for men and women (Q131367891) point in time (P585) 1902 applies to jurisdiction (P1001) Australia (Q408) as its a legal change Vicarage (talk) 07:53, 2 December 2024 (UTC)[reply]
@Vicarage 200 statements to a single item is certainly better than adding it to individual countries.
It's worth noting that universal suffrage for men and women means "all man in women" and many countries. That does include prisoners and many countries do not allow them to vote, Ireland for example only allowed that in 2006. The US does not have it.
If you want to focus on the date where women where allowed to vote, women's suffrage (Q205204) is the better item. The personhood of prisoners is worth respecting. ChristianKl11:42, 2 December 2024 (UTC)[reply]
Its certainly a can of worms. https://commonslibrary.parliament.uk/research-briefings/cbp-7461/ show that even as late as 2018 England (but not Scotland)
were changing the rules. But better to record the broad brush details than not at all. Devolution to Scotland shows why applies to jurisdiction (P1001) is better than country (P17) Vicarage (talk) 11:59, 2 December 2024 (UTC)[reply]
"It's worth noting that universal suffrage for men and women means "all man in women" Depends whom you ask Trade (talk) 16:48, 6 December 2024 (UTC)[reply]

Rotten Tomatoes and Wikidata

[edit]

When filling in the "Critic's response" in a film's en.wikipedia article, I update the Wikidata for the film, then use the following in the WP article: {{RT prose|{{RT data|score}}|{{RT data|average}}|{{RT data|count}}|prose prose prose prose|ref=yes|access-date={{RT data|date}}}}

Short and sweet, very very convenient, automatically updates the WP article if some user later updates the Wikidata fields.

A challenge is that, if the information for the Rotten Tomatoes average rating has "/10" included in the Wikidata field, it results in a double "/10/10" appearing in the WP article. For example, for the 2021 film Oxygen https://en.wikipedia.org/wiki/Oxygen_(2021_film), putting 6.8/10 in the Wikidata field results in the en.wikipedia article displaying:

... of 106 critics' reviews are positive, with an average rating of 6.8/10/10.

The only way to avoid this is to not include the "/10" when filling in the Wikidata field, resulting in the en.wikipedia article properly showing:

... of 106 critics' reviews are positive, with an average rating of 6.8/10.

While this "workaround" resulted in a nice output for en.wikipedia articles, it has been brought to my attention, by de.wikipedia editor Eiragorn, that leaving out some of the extra detail in the cross-language shared Wikidata is resulting in issues for the templates used in the WP articles in other languages. The "workaround" to make the en.wikipedia template work is hurting other ill.wikipedia templates.

I should point out that, until very recently, this "double display" issue would also happen if the Tomatometer score, in the Wikidata file, had the "%" symbol included, resulting in a double "%%" appearing in the en.wikipedia article. For the Oxygen example, this produced:

On the review aggregator website Rotten Tomatoes, 90%% of 106 critics' reviews...

It appears this has been fixed in the en.wikipedia template. In fact, it is "beyond fixed", as you can now do a Wikidata input with the digits by themselves (90), or the digits and the symbol (90%), and the result in always a single "%" appearing in the en.wikipedia article. For the Oxygen example, this now always produces:

On the review aggregator website Rotten Tomatoes, 90% of 106 critics' reviews...

I checked with an en.wikipedia administrator today, who recommended discussing this with you good folks at Wikidata first, and asking here what the proper format for recording the information is in Wikidata. They pointed out that Wikidata might have some different way of recording the /10 denominator and that it was best to check if a user should - or shouldn't - include it in the Wikidata field. It was mentioned that you folks would also have the ability to introduce constraint violations or make mass edits to enforce the proper format. Once that's done, each of the Wikipedias would then work with that as a baseline.

If I have placed this discussion item on the wrong Wikidata page, please let me know and I will redo at the proper spot. Thank you, in advance, for your help and direction. Jmg38 (talk) 01:31, 3 December 2024 (UTC)[reply]

review score (P444) usage seems to be X/Y for Rotten Tomatoes, and there is no constraint applied on the input to limit the characters used, so I think the onus is on WP to accept that as is. Clearly you could have a special WD review property "TripAdvisor stars", forced to 1-5, and WP formats that to add a '*', but that's not the case here, and I doubt we'd want lots of separate properties. Vicarage (talk) 10:31, 3 December 2024 (UTC)[reply]
@Jmg38: Doesn't this work better: {{RT data|prose|consensus=prose prose prose prose|ref=yes|access-date={{RT data|date}}}} - Difool (talk) 13:27, 3 December 2024 (UTC)[reply]
Thank you, Vicarage and Difool. And a thank you to Indagate, who also pointed out that the long clunky nested templates I came across years ago were unnecessary, with just one minor reduction from the already significant improvement that Difool included above: {{RT data|prose|consensus=text text text…|ref=yes}} Overall, another terrific outcome from the wiki community. Thank you all. Jmg38 (talk) 19:01, 3 December 2024 (UTC)[reply]
The examples of review score (P444) all are worded like X/Y. Wikipedia templates should be able to handle that. ChristianKl16:04, 4 December 2024 (UTC)[reply]

'Founder of' property or similar

[edit]

Hello everyone! I am scratching my head and can't come up with a reasonable alternative to 'founder of', which doesn't exist as a property presently. 'Founded by' already exists, so I am looking for its opposite.

Before I propose a new property, I wondered what alternatives there are? eg. Octavia Hill would be 'founder of' the National Trust; Alexander Keiller would be 'founder of' the Morven Institute of Historical research; Wallace Heaton would be 'founder of Wallace Heaton Ltd; Ivison Macadam would be 'founder of' the National Union of Students...

With thanks! Medievalfran (talk) 10:14, 3 December 2024 (UTC)[reply]

We generally don't record symmetrical properties, as the query system makes it easy to query ?founded wdt:P112 ?founder to find the relation both ways. It keeps the number of statements down and reduces clutter. Vicarage (talk) 10:22, 3 December 2024 (UTC)[reply]
This is previously proposed six times: 2013, 2016, 2016, 2017, 2023, 2024.--GZWDer (talk) 15:25, 3 December 2024 (UTC)[reply]
If something's been proposed six times, that might be an indicator that we need it. DS (talk) 03:06, 6 December 2024 (UTC)[reply]
Counterpoint: if something has been proposed and rejected 6 times, that might be an indicator it's not needed. William Graham (talk) 04:36, 6 December 2024 (UTC)[reply]

P31 = numeric identifier on Wikidata properties

[edit]

Hello all friends of Wikidata properties! See my proposal regarding moving numeric identifier (Q93868746) from instance of (P31) to has characteristic (P1552) on Wikidata talk:WikiProject Properties. Thanks. Samoasambia 22:03, 3 December 2024 (UTC)[reply]

✓ Done. Apologies for floodig your watchlists. Samoasambia 00:21, 9 December 2024 (UTC)[reply]

Adding (Ancient) Egyptian lexemes from Thesaurus Linguae Aegyptiae

[edit]

The Thesaurus Linguae Aegyptiae (Q122748326) project seeks to donate about 15T of approx 40T lexical entries of the Egyptian (Q50868) language in Leiden Unified Transliteration/Transcription (Q131362896) and Egyptian hieroglyphs (Q132659) to Wikidata. This is part of a cooperation project funded by the consortium Text+ (Q98271443) of the German National Research Data Infrastructure (Q61658497).

In a first batch, we are focusing on the main parts of speech, largely excluding proper noun (Q147276), title (Q216353), and epithet (Q207869). Examples: ḥꜣ.tï/𓄂𓏏𓏭𓄣 (L1391335), sw/𓇓𓅱 (L1385334), ẖr.ï/𓌨𓂋𓏭 (L1391360), ky/𓎡𓇋𓇋 (L1391327) wḏꜣ/𓅱𓍑𓄿𓂻 (L1385371); selected frequent proper nouns and titles, e.g. Wsꞽr/𓊨𓁹 (L1391321), Ppy (L1391324), nb-Tꜣ.wï/𓎟𓇾𓇾 (L1391331), ẖr.ï-ḥꜣb.t/𓎛𓌨𓃀 (L1391337); see also: https://situx.github.io/paleordia/language/?q=Q50868&qLabel=Egyptian, https://ordia.toolforge.org/language/Q50868.

We also created a language modeling page for Egyptian.

We are currently requesting a bot flag for our ThesaurusLinguaeAegyptiaeBot (talkcontribslogs), so that we can perform maintenance tasks more efficiently in the future: Wikidata:Requests_for_permissions/Bot.

Any comment and support is very welcome.

Dwer (talk) 13:04, 4 December 2024 (UTC)[reply]

[edit]

Are Wiktionary sitelinks in items for Unicodes allowed? Since they are inherently translingual/mul, would a sitelink to wikt:℥ in (Q87523885), along the other interwikts, be fine? LIrala (talk) 03:38, 5 December 2024 (UTC)[reply]

As far as I see, it's not one of the expections that currently in https://www.wikidata.org/wiki/Wikidata:Wiktionary/Sitelinks , but I currently can't think of a problem that would come with adding an expection for it. ChristianKl11:28, 5 December 2024 (UTC)[reply]
Aren't Wiktionary sitelinks handled by Cognate? I'm not familiar with it, but I'd advise not to add any sitelinks unless it can't be handled by the existing mechanism. Infrastruktur (talk) 21:25, 5 December 2024 (UTC)[reply]
But there is no way (property) for linking from wikidata to wiktionary entry, so existing mechanism isn't working here. JAn Dudík (talk) 09:07, 6 December 2024 (UTC)[reply]
@LIrala: Why are sitelinks requested in the first place though? Is there a need to fetch data from Wikidata for the entries?
@LIrala: Forgot to sign. Infrastruktur (talk) 14:15, 6 December 2024 (UTC)[reply]
Wikidata doesn't require it unless it's for things outside mainspace, such as categories. However, for a Wikipedia article, it can be useful. fr:♌ vs wikt:fr:♌, w:🔞 vs wikt:🔞, pt:♀ vs wikt:pt:♀. Unicode items usually don't have non-redirect sitelinks to Wikipedia, there are a few. They would show at Wikipedia in the same Wikiquote and Commons are shown. LIrala (talk) 01:17, 7 December 2024 (UTC)[reply]
Wikidata's data can be used without sitelinks, you just have to specify which entity you want to use. For example, incubator:Wp/sms/Kolari has an infobox generated from Kolari (Q543882) (even though sitelinks are not supported for Incubator) and wikt:bn:হৃদয় is generated entirely from হৃদয় (L301993) (even though lexemes don't support sitelinks at all). - Nikki (talk) 15:21, 7 December 2024 (UTC)[reply]
No, they're not allowed. Wikidata:Notability excludes the main namespace and there is an abuse filter that tries to stop people from adding them. Wikidata:Notability/Exclusion criteria also excludes soft redirects like w:en:🔞.
The main namespace in Wiktionary uses Cognate, not Wikidata, so adding them to Wikidata won't have any effect on Wiktionary pages. Wiktionary pages in the main namespace are also about specific text strings, whereas Wikidata items are about concepts. Wikidata does not support adding the same sitelink to multiple items, nor adding multiple sitelinks for the same wiki to the same item. For example, some people might want the Wiktionary page "♀" to be linked to (Q87526780), but others might want it to be linked to (Q13405286), and we can't do that.
- Nikki (talk) 15:08, 7 December 2024 (UTC)[reply]
Notability is only for item creation/deletion criteria, the items will exist (unless we mass delete all rule-basedly non-notable emojis and Unicode items). And they do have effect on Wiktionary pages, but only on desktop, such as the page we are at now (Project:Village pump (Q16503)). That filter isn't as strong as /doc or User: namespaces anyways. LIrala (talk) 23:51, 8 December 2024 (UTC)[reply]

Large number of new editors associated with Q47213994 creating items for themselves

[edit]

I've noticed that within the last couple hours, more than a dozen users have registered accounts to create items about themselves, indicating they are members of mainzed (Q47213994). Is anyone aware of editor outreach or similar events happening with participants from Mainz University? William Graham (talk) 17:15, 5 December 2024 (UTC)[reply]

I received a reply at User talk:Elisabeth Pilhofer. If anyone else wants to take a go at counseling this group of editors. William Graham (talk) 19:09, 5 December 2024 (UTC)[reply]

Annual Exhibition of the San Francisco Art Association

[edit]

Hi, I have noticed that there are many items for these, but I can't find a generic one which would match the Commons category: c:Category:Annual Exhibition of the San Francisco Art Association. Should such an item be created, linking all the individual ones?

Idem for Annual Exhibition of San Francisco Women Artists, and c:Category:Annual Exhibition of San Francisco Women Artists. Thanks, Yann (talk) 11:18, 6 December 2024 (UTC)[reply]

This user seems not aware the multilingual nature of Wikidata labels, but I don't know what can be done.--GZWDer (talk) 12:41, 6 December 2024 (UTC)[reply]

Is there any way to curate suggested units?

[edit]

It's always bothered me whenever i use "data size (P3575)" and type "gb" into the unit field that gigabyte (Q79738) is at the bottom. Is it really necessary to include the United Kingdom as one of the suggestions at all?

I just want a way to customize it so it fits to how i use the property (read; megabyte and gigabyte). Trade (talk) 16:51, 6 December 2024 (UTC)[reply]

I'm not familiar with any script that adjusts this list, I share the same annoyances and am surprised it has such a low priority. Sjoerd de Bruin (talk) 10:06, 7 December 2024 (UTC)[reply]
Currently we do have entity suggestions based on one-of constraint (Q21510859) and allowed qualifiers constraint (Q21510851) of the property. Adding a similar functionality to allowed units constraint (Q21514353) which is present on data size (P3575) would be a good idea. Samoasambia 11:02, 7 December 2024 (UTC)[reply]
This is phab:T312962 (previously phab:T110673). - Nikki (talk) 15:27, 7 December 2024 (UTC)[reply]
[edit]

As stated, I've noticed and cleaned articles that are related to Mexico or Mexican politics to have been vandalized by IP users. They're basically changing the name of articles to a non-sequitur name or to politicized names. TepeyacPilgrim (talk) 19:29, 6 December 2024 (UTC)[reply]

Gathering ideas for a Wikidata challenge for (Dutch) Wikipedians

[edit]

Hi all! I am an active member of the gender gap working group on Dutch Wikipedia. We sometimes do small time-constrained challenges and activities, with a small reward (e.g. a book voucher) (example). Most of these challenges have been on Wikipedia itself, but we have been branching out to Wikiquote in the past year, participating in the international SheSaid challenge. There's a nice group of sympathetic Wikipedians on Dutch Wikipedia who actively participate in these.

Being mostly a Wikidatan myself, I am thinking of organizing a small challenge on Wikidata in 2025 around the Dutch-language gender gap (note that this is not only relevant for the Netherlands, but also other regions in the world where Dutch is spoken: Flanders, Suriname, etc.). I haven't organized any Wikidata challenges before and am curious if anyone has experiences and ideas.

I am already tracking the project's relevant Wikidata items via the on focus list of Wikimedia project (P5008)gender gap on Dutch Wikipedia (Q60687720) statement (incomplete, of course, but it's a start).

My current thoughts about such a challenge:

  1. It shouldn't take much time to organize and manage and track (for selfish reasons: I will be really busy next year)
  2. I'd like it to target Dutch-language Wikipedia editors who are sympathetic towards and curious about Wikidata. I would like to use the challenge as a springboard for them to learn more about Wikidata, and increase their skills and confidence contributing to Wikidata.
  3. I'd like the challenge to focus on improving existing Wikidata items (i.e. not creating new items). Adding and improving sourced statements, adding sources, improving sitelinks... mainly because I notice that this still needs a lot of work! We have so many items with barely any references, and I personally always discover items that can and should be improved.

But I welcome other ideas, taking into account that point #1 is really important :-)

My current questions:

  • Has anyone here done a similar thing, and would like to share experiences?
  • How could we track participation, contributions, and the quality of the contributions - specifically e.g. adding references? I know the Program and Events Dashboard allows some tracking of edits to Wikidata items, but in my experience it's very rough (I think it doesn't allow to track contributions to results of a specific Wikidata query, but I may be mistaken)

Any tips, ideas, suggestions and input welcome. Best, Spinster 💬 08:11, 7 December 2024 (UTC)[reply]

I'm quite interested in this topic. Improving these items would give a good indication of notability for articles on Wikipedia as well. Wikidata:WikiProject Women/Wiki monitor/nlwiki has a few reports. Sjoerd de Bruin (talk) 10:53, 7 December 2024 (UTC)[reply]

Texas Tower Three

[edit]

My husband was assigned to Texas Tower Three. I live in St Charles County Mo and they have a Veterans Museum. I would like to use the pictures I have of the Tower and tell the story do I have permission to copy the facts about TT3? to go along with the story about my husband's 20 years in the USAF. Whiteglovelady (talk) 15:15, 7 December 2024 (UTC)[reply]

@Whiteglovelady Hi! Wikidata does not accept pictures, but you can contribute them to Wikimedia Commons. We don't accept stories either, but your photographs might be a good addition to en:Texas_Towers. Bovlb (talk) 19:56, 7 December 2024 (UTC)[reply]

Wikidata recentchanges replica incomplete?

[edit]

For the popular items section on the main page, my bot queries the replica recentchanges table on Toolforge. Recently, the list was not updated anymore because the replica does not seem to contain any revisions beyond 2024-12-02, 10:12:17:

MariaDB [wikidatawiki_p]> SELECT rc_id, rc_timestamp, rc_namespace, rc_title FROM recentchanges ORDER BY rc_timestamp DESC LIMIT 3;
+------------+----------------+--------------+------------+
| rc_id      | rc_timestamp   | rc_namespace | rc_title   |
+------------+----------------+--------------+------------+
| 2351040105 | 20241202101217 |            0 | Q51785014  |
| 2351040104 | 20241202101217 |            0 | Q95947147  |
| 2351040103 | 20241202101217 |            0 | Q131375221 |
+------------+----------------+--------------+------------+

Did I miss some technical change to the database schema, or is something broken here? Special:RecentChanges does work without flaws and it does contain revisions up to now. —MisterSynergy (talk) 09:11, 8 December 2024 (UTC)[reply]

Is this possibly connected to the lag reported on https://replag.toolforge.org/? --Dorades (talk) 10:26, 8 December 2024 (UTC)[reply]
Yes it is, good to know. Has this been reported anywhere already? I wasn’t able to spot a related task in Phabricator, unfortunately. —MisterSynergy (talk) 10:28, 8 December 2024 (UTC)[reply]
See this announcement on the cloud-announce mailing list. Sjoerd de Bruin (talk) 08:45, 9 December 2024 (UTC)[reply]
It was also mentioned in the weekly summary (twice, like the cloud-announce email, because of the unexpected delay), though I don’t know how many people saw it there. But Dorades and Sjoerd are correct, and there’s not much that you can do other than wait for the schema change to finish and replication to resume (unless you can switch your use case to the API, which just like Special:RecentChanges is not affected). Lucas Werkmeister (WMDE) (talk) 10:35, 9 December 2024 (UTC)[reply]

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]
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]

Wikidata weekly summary #657

[edit]

Temporary Accounts - introduction to the project

[edit]
A temporary account notification after publishing the first edit

The Wikimedia Foundation is in the process of rolling out temporary accounts for unregistered (logged-out) editors on multiple wikis. The pilot communities have the chance to test and share comments to improve the feature before it is deployed on all wikis in mid-2025.

Temporary accounts will be used to attribute new edits made by logged-out users instead of the IP addresses. It will not be an exact replacement, though. First, temporary users will have access to some functionalities currently inaccessible for logged-out editors (like notifications). Secondly, the Wikimedia projects will continue to use IP addresses of logged-out editors behind the scenes, and experienced community members will be able to access them when necessary. This change is especially relevant to the logged-out editors and anyone who uses IP addresses when blocking users and keeping the wikis safe. Older IP addresses that were recorded before the introduction of temporary accounts on a wiki will not be modified.

We would like to invite you to read the first of a series of posts dedicated to temporary accounts. It gives an overview of the basics of the project, impact on different groups of users, and the plan for introducing the change on all wikis.

We will do our best to inform everyone impacted ahead of time. Information about temporary accounts will be available on Tech News, Diff, other blogs, different wikipages, banners, and other forms. At conferences, we or our colleagues on our behalf are inviting attendees to talk about this project. In addition, we are contacting affiliates running community support programs.

Subscribe to our new newsletter to stay close in touch. To learn more about the project, check out the FAQ and look at the latest updates. Talk to us on our project page or off-wiki. See you! NKohli (WMF) and SGrabarczuk (WMF) (talk) 00:00, 10 December 2024 (UTC)[reply]

[edit]

Hello, in my watchlist I noticed a Wikipedia Library link used as reference url P854 (diff). In my opinion, the Wikipedia Library is very useful to found sources and access paywalled pages, but it is not to be used as a link for referencing items, because the link should be directly to the source, without the wikimedian access. I am right or it has never been discussed before? However, in this specific case I can't found a different link to the source, so I don't know what is best to do. (I notify also @RabbitFromMars who added the source.) Una tantum (talk) 11:10, 10 December 2024 (UTC)[reply]