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

Wikidata:Project chat

From Wikidata
Jump to navigation Jump to search

Raise echo limit to make ping project work again for bigger projects

Hi everyone, I propose to raise the configured limit ($wgEchoMaxMentionsCount ) for {{Ping project}} from 50 to 100 on this project. That way the ping works again for the bigger projects. Any objections? Multichill (talk) 19:53, 8 June 2019 (UTC)[reply]

I support this, just because the paintings project seems to have broken the ping barrier. Jane023 (talk) 23:55, 8 June 2019 (UTC)[reply]
Likewise, the Books project passed the limit long ago. --EncycloPetey (talk) 00:37, 9 June 2019 (UTC)[reply]
 Support, but this has been rejected on technical grounds before - I think there’s a Phabricator ticket. - PKM (talk) 18:56, 10 June 2019 (UTC)[reply]
I feel like any project that's grown so large should just be having its discussions on the Wikiproject talk page. I'm not sure there's as much use for mass-pings for such large projects. --Yair rand (talk) 18:57, 11 June 2019 (UTC)[reply]
I support the mass-pings. If a discussion about a property happens at the property page it's easier to find then when it happens at the Wikiprojects talk page for further users of the property. Property proposal are another area where we want the discussion to happpen at a place besides the Wikiproject talk page. ChristianKl15:38, 18 June 2019 (UTC)[reply]

Property proposal: "Authoritative country ISO 2 letter code for Nagoya Protocol regulations"

I would like to add the property "Authoritative country ISO-2-letter-code for Nagoya Protocol regulations" (data type: string, domain: country Q6256) to all country items on Wikidata. Afterwards, I would add the statements to all countries, for example "UK" as a value for the newly created property for Jersey Q2280052. It would be handy to create all these statements using the quick_statement tool instead of a bot, but I am unsure. Before I can use the quick_statement tool, the propert needs to be added to all country items.

AddNPBot (talk) 08:36, 13 June 2019 (UTC)AddNPBot 12th June 2019[reply]

I don't know how the Nagoya Protocol (Q1963613) specifically uses ISO 2 letter codes, so I might be missing something, but I would certainly hope that our existing property ISO 3166-1 alpha-2 code (P297) is accurate and authoritative enough for any use! I can't imagine needing a new property which is somehow "more authoritative" for just this one purpose. —Scs (talk) 14:00, 14 June 2019 (UTC)[reply]
You are correct, the ISO 3166-1 alpha-2 code (P297) is existent for all countries, however, I am not addressing the ISO code of the item itself, but the ISO 2 Code for the authoritative country that takes care of Nagoya Protocol matters. For example: Norway "NO" for Svalbard Svalbard (Q25231), "UK" for Jersey Jersey (Q785) and Guernsey Bailiwick of Guernsey (Q25230). That way one could be able to parse the database and get the ISO 2 Code of the country that actually manages Nagoya Protocol (Q1963613) regulations for that item. Wikidata stores some items which are entire countries but also items that are part of countries. The official Nagoya Protocol (Q1963613) signatories list, however, only consists of whole countries, it does not list external territories (like Svalbard, Jersey, etc). Therefore, it would be beneficial to create a link between these smaller territories to the actual authoritative country. I hope I am making sense. -AddNPBot (talk) 11:10, 17 June 2019 (UTC)[reply]

German (formal)

Why there is formal version only of few languages? Anyway why there is formal version of certain languages while we use here formal version instead of common language? Why PLbot is removing German (formal) but he is not removing for example Spanish (formal)? @Pasleim: Eurohunter (talk) 22:16, 14 June 2019 (UTC)[reply]

@Matěj Suchánek: Your bot just removed few formal versoins. Do you know something about it? Eurohunter (talk) 08:52, 15 June 2019 (UTC)[reply]
As Jura said. The answer probably is that es-formal occurred recently. --Matěj Suchánek (talk) 09:24, 15 June 2019 (UTC)[reply]

any Russian-speaking programmers here?

I want to merge repeat until (Q30278326) into do–while loop (Q3242594). But the Russian-language descriptions conflict. Can anyone confirm that they're more or less equivalent, pick the best one, and delete the other one? Thanks. —Scs (talk) 02:53, 15 June 2019 (UTC)[reply]

It doesn't seem to me. repeat until (Q30278326) has a statement that it is a part of Pascal (Q81571). I made it more clear with subclass of (P279). --Matěj Suchánek (talk) 07:26, 15 June 2019 (UTC)[reply]
You need to find Azerbaijani speaker to find out concept of this article: is it part of Pascal description or just generic programming construct in as series of Wikipedia articles. EugeneZelenko (talk) 13:51, 15 June 2019 (UTC)[reply]
These are different forms of cycle construction, Scs, why do you want to merge them? They have different condition of exit. --Infovarius (talk) 14:50, 21 June 2019 (UTC)[reply]
Yeah these look different, maybe should not be merged at all. Laboramus (talk) 23:47, 21 June 2019 (UTC)[reply]
Short answer: No, they probably don't deserve merging after all.
Longer answer: I was looking into our taxonomy of programming language constructs (that is, the individual syntactic elements that make up programming languages), and I was discovering that we don't have a very well refined taxonomy there yet.
We don't have instance entities for each construct in each programming language. (That is, we don't have entities for C if/else statement or Fortran computed goto or Haskell function. Nor do I particularly think we should.)
We don't even have a complete taxonomy of class entities for the various common types of programming language constructs, entities that the hypothetical C if/else statement entity could be instances of. We do have some class-like entities, like loop (Q8868615) and declaration (Q1183659) and goto (Q750997). But we're missing others -- there's no entity for if statement at all (the closest we've got is control flow (Q868299)), nor for the superclass programming language construct.
But we do have do–while loop (Q3242594) which might be thought of (and is!) a subclass of loop (Q8868615). And then we come to repeat until (Q30278326). It appears to be specifically about Pascal's repeat until loop, which is (or would be) an instance of do–while loop (Q3242594).
So if repeat until (Q30278326) were about a generic construct (as opposed to the Pascal-specific construct it is), it would be just another name for do–while loop (Q3242594), which is why I was thinking it needed merging. But it's not about a generic construct, so it can stay -- but it's odd, because it's the only example I've found so far of an entity about a specific construct in a specific language.
[Side note: It may well be that the reason that we "don't have a very well refined taxonomy" is that there isn't a good, single taxonomy that would apply to all programming languages. Me, I imagine there's one, but the one in my head might be too heavily influenced by my favorite programming language, might not be a good match for others.]
Anyway, that's my story. Comments on the larger question of a "taxonomy of programming language constructs" welcome. —Scs (talk) 13:03, 22 June 2019 (UTC)[reply]

reCh is not working

Sad news; reCh is down and Pasleim is away. Can we fix the gadget somehow? Bencemac (talk) 12:50, 16 June 2019 (UTC)[reply]

One of the queries the tool makes needs to be migrated to the newly introduced actor table (here in line 46); technically this is a relatively simple fix. However, this needs either Pasleim's interaction, or we need to adopt or usurp his tool according to this wikitech policy. I have tried to contact Pasleim via wikimail regarding another issue a few days ago, but he did not reply yet. —MisterSynergy (talk) 19:48, 16 June 2019 (UTC)[reply]
Thanks for your answer MisterSynergy! I hope we will see Pasleim soon. My biggest problem is that I cannot patrol label/description edits in Hungarian without reCh. Is there any alternative? Bencemac (talk) 07:16, 17 June 2019 (UTC)[reply]
You could try User:Yair rand/DiffLists.js. Once added to your common.js, you have additional filter options for terms and languages in the Wikidata UI, including Special:RecentChanges. This is in my opinion not as comfortable as reCh for partolling, but it is something... :-) WD:CVN lists some more CVN-related tools, but I am not sure whether any of them is helpful for you. --MisterSynergy (talk) 07:30, 17 June 2019 (UTC)[reply]
@Bencemac: The Wikidata vandalism dashboard tool can also show you unpatrolled Hungarian label/description/alias edits. --Lucas Werkmeister (WMDE) (talk) 10:47, 17 June 2019 (UTC)[reply]
Thank you! Not that comfortable as reCh was, but better than nothing. Bencemac (talk) 18:35, 23 June 2019 (UTC)[reply]

Aviation Safety Network accident ID and IWM memorial ID

For Property:P1755 and Property:P3038 should I change the restrictions to allow the IDs to be added to people or should it stay only when we have an entry on the accident? https://www.iwm.org.uk/memorials/item/memorial/57382 For most early aviation accidents with one or two seat planes we only have entries for the people involved, not an entry for the accident. The same for the war memorial, should I allow it for people, instead of an entry on the memorial itself? See the person at Edward Hotchkiss (Q64676328) for one example. --RAN (talk) 14:21, 16 June 2019 (UTC)[reply]

My feeling is that we should only use the IDs for the event/memorial, not the person. If we don't have the event/memorial, that's okay; we don't need to represent absolutely everything within Wikidata. But mixing them up, when the identifier is very much for the "thing" and not the person it's connected to, is going to get confusing. Andrew Gray (talk) 22:07, 19 June 2019 (UTC)[reply]

Mobile view improvements

For items with a usual number of statements (e.g. < 30, except identifiers), I think the mobile view is much like an infobox. It's more compact than the desktop view, possibly because the sitelinks are at the end.

One thing I find odd is that all references are displayed by default (which isn't the case for the desktop view). This isn't much of an issue if it says reference (0) or a reference that is limited to a source or page, but people seem to get carried away. Maybe the mobile view shouldn't display references by default either.

When starting from mobile view on Wikipedia, there seems no way to get to Wikidata. Do I keep missing it or should that be added? --- Jura 18:06, 16 June 2019 (UTC)[reply]


For the above, I created the following tickets in phabricator:

Please comment there. --- Jura 11:32, 18 June 2019 (UTC)[reply]


  • Interesting find: apparently, it's thought that only advanced Wikipedia contributors (who log-in to edit) should be able to navigate to Wikidata on mobile.
Personally, I don't think it's particularly useful to edit Wikidata on mobile, but it should be possible to view its pages without log-in. Even more so actually.
The discussion in phab:T226009 could probably benefit from more Wikidata user input. --- Jura 07:11, 19 June 2019 (UTC)[reply]

Multiple languages

I have noticed it is possible to add "mul" code to title to achive multiple languages (Q20923490). Is there way to achieve "Two languages" and list them yet? Eurohunter (talk) 18:56, 16 June 2019 (UTC)[reply]

Subsequent question: As I understand it "mul" should be used if the text is written in more than one language like: "His last words were 'Mehr Licht!'" What about cases like Aydın (Q27229572), a family name existing in more than one language, at least in Turkish and Azerbaijani. Currently the tag of native label (P1705) is only "tr", I've used "zxx" in such cases. What is the recommended solution? Ping @Jura1 , Harmonia Amanda as biggest human users of the property and editor here. Thanks in advance --Marsupium (talk) 17:01, 21 June 2019 (UTC)[reply]

For names, if the same exact string is used for several languages (which is nearly all cases for Latin-script, since you'll have immigrants and regional languages), then the code should be "mul" and all relevant languages listed in language of work or name (P407). --Harmonia Amanda (talk) 17:05, 21 June 2019 (UTC)[reply]
Thank you! So like this and this!? I've tried to clarifiy this in Help:Monolingual text languages#Special language codes – perhaps not the best words, any improvement is welcome! --Marsupium (talk) 18:57, 21 June 2019 (UTC)[reply]

Is there a property for public transport to a place?

Many articles on Wikipedia, such as en:Madison Square Garden and en:Museu do Ipiranga, list all public transport available near a place. I was wondering if we can list all metro stations and bus lines using Wikidata. Thanks! Tetizeraz (talk) 19:20, 16 June 2019 (UTC)[reply]

This sounds interesting and useful, but it might require a certain amount of work developing or refining a transit-related infrastructure within Wikidata at all, in order to hook up to.
There's a ton of transit-related data already curated in the various Wikipedias (most metro and intercity rail lines, most stations), but I'm not aware of any systematic attempt to model it in Wikidata yet. (But if I'm missing something, someone let me know!)
Are you thinking of rail transport, or also buses, ferries, airports, etc.?
I suppose as a start we could do something similar to the existing property for located in or next to body of water (P206). —Scs (talk) 22:23, 19 June 2019 (UTC)[reply]
We do have place served by transport hub (P931), which links a transport hub to the place it serves, but basically you're asking for a property that points in the other direction, from the place back to the transport hub. —Scs (talk) 11:48, 20 June 2019 (UTC)[reply]

Proposal

Hello! There are statements for work period (start) (P2031) but no any statment for work period (end) (P2032) in some items aboud died people. As a result Wikidata exports to different Wikipedia projects wrong information that dead people are still active in there profession. For example, Ayn Rand (Q132524) (died in 1982) is still active in French Wikipedia, F. Scott Fitzgerald (Q93354) (died in 1940) is still active in Spanish and Ukrainian Wikipedia, Joseph Conrad (Q82925) (died in 1924) in Russian. As soon as work period (end) (P2032) is not the same date of death (P570) it shouldn't be fixed by bot. So my proposal is just to make Property constraint for items with statements: instance of (P31) - human (Q5), date of death (P570), work period (start) (P2031) and have no statement for work period (end) (P2032). There are over 5.000 such items as we found out in Russsian project chat so if somebody will join to me for adding this statement I'll be glad. P.S. I beg Yuor pardon for my English. --Ksc~ruwiki (talk) 21:14, 16 June 2019 (UTC)[reply]

Cenomani

Cisalpine Gauls (Q3253132), Aluerci Cenomani (Q859382), and Cenomani (Q1254768) need to be sorted out. There are two peoples named "Cenomani", one in Cisalpine Gaul and one in Gallia Celtica, and there seems to be a lot of Wikipedia articles connected to the wrong items. I'm not very Wikidata savvy; if someone could help merging/moving items that would be great. Julia (talk) 03:10, 17 June 2019 (UTC)[reply]

I've done some work on this, but more is needed. Most of the articles state that the Cisapline Cenomani "separated" from the Cenomani in Gaul (EN wiki questions this based on 1911 EB). Anyway I've separate out "Cisalpine Gauls" from "Cenomani (Gallia Cisalpina)", so you'll see a name change and some migrated site links. More to come... - PKM (talk) 23:37, 17 June 2019 (UTC)[reply]
@Julia: I think this is sorted for now. I've followed FR Wikipedia (and the Pleiades database) in calling these Aluerci Cenomani (Q859382) (in Gallia Celtica) and Cenomani (Q1254768) (in Cisalpine Gaul) in English. Most Wikis have one article that covers both groups, and I have linked those to Aluerci Cenomani (Q859382) as the "parent" tribe (again following FR Wikipedia, which has recent sources). Articles specifically about the Cisalpine group are linked to Cenomani (Q1254768). Let me know if this looks better to you, or if I've missed anything. - PKM (talk) (Edited to add Pleiades database.)
PKM Everything looks in order; thanks for the help. Julia (talk) 02:45, 18 June 2019 (UTC)[reply]

Scoped item by country

Hello, I’m trying to make a scoped version of hotel rating (Q2976556): while Q2976556 represents hotel rating in general I’m trying to make a sub-item that represents hotel rating in France (hotel rating in France (Q64685494)) and in Italy. I tried setting subclass of (P279) but it gives me a warning saying Q2976556 itself is missing a P279 entry (same warning with instance of (P31)). The reason of this is I want to fix the WP interlinks: in WP:fr the page describes the French hotel rating system rather than the concept of hotel rating itself. Same issue in WP:it where the page describes the Italian system. How can I do that? Thanks in advance! -- Okhjon (talk) 09:41, 17 June 2019 (UTC)[reply]

hotel rating (Q2976556) seems to represent hotel rating systems in general, of which many seem to exist, so it should be a subclass of classification scheme (Q5962346), not an instance. Then a specific hotel rating system can be an instance of that. hotel rating in France (Q64685494) should have some information about how the rating system operates, e.g., which organisation administers it and probably a URL. Ghouston (talk) 10:38, 17 June 2019 (UTC)[reply]
Thank you, I just did that. -- Okhjon (talk) 12:11, 17 June 2019 (UTC)[reply]

Stylized name

How to add stylized name ("stylized as")? For example "BassHunter" would be stylised name for Basshunter or "myspace" for Myspace. Eurohunter (talk) 10:51, 17 June 2019 (UTC)[reply]

The official name (P1448) should point to the name in the preferred spelling. If you want to explicitely store that something is a stylised name you might use a construction with object of statement has role (P3831) stylised name. Apart of that object named as (P1932) can be used in many cases to specify how a given source writes a name. ChristianKl07:16, 19 June 2019 (UTC)[reply]
@ChristianKl: I did as you told and created stylized name (Q64732482). Thanks. Eurohunter (talk) 07:00, 20 June 2019 (UTC)[reply]

Display problem on P118

If this is a known problem or has a cause that I am unaware of, apologies for posting.

I've noticed multiple instances where the label being displayed on P118 is incorrect for some values. For example on this page: Dario Vidošić (Q361040) under the league section, the 1st value is Liga mx, however the link is to Bundesliga (Q82595).

If you click it, it goes to Q82595 which is the German Bundesliga (which is correct), nowhere on that page is Liga Mx an alias. If you edit or go to the page and come back it will revert to the proper label.

This is the 5th or 6th time I have seen this for the German Bundesliga, I've also seen it on other teams (New England Patriots is one I have seen it on) -- 13:25, 17 June 2019 CanadianCodhead

I'm not sure if this is an actual issue, because I'm looking at the article right now and it seems to display correctly? Circeus (talk) 16:49, 17 June 2019 (UTC)[reply]

The display corrects as soon as you edit or add an item on the page. I cant figure out if I can embed a photo here or not, but assuming no one updates the page in the interim, here is another page showing the problem : Q107365

Is something wrong with my merge, or are just the servers rather slow?

Yesterday, I used the merge gadget for merging Q64682095 (with two wikipedia sitelinks) into Q9910661 (with four). As many things yesterday, I had to wait longer than usual for responses, but it seemed to work (when I looked at the wikidata items). However, the interwikilinking didn't work for the sites linked to. Today, I've checked through all six sites, and at the moment three of the old Q9910661 sites display all five other sites, but the last one (w:uk:Категорія:Європейські омбудсмени) only display the other three old Q9910661 sites, and the two old Q64682095 sites (w:en:Category:Ombudsmen in the European Union and w:sv:Kategori:Europaombudsmän) only display each others.

Did I do something wrong, or is something the matter with the gadget; or is this just an unusually slow adjustment of the database to the changes? (Waiting a couple of minutes is normal; this isn't.) JoergenB (talk) 14:14, 17 June 2019 (UTC)[reply]

@JoergenB: Hi, I purged the affected pages, and the problem should be fixed now. You did nothing wrong. Sometimes Wikipedia pages need to be purged or otherwise changes won't show up. --Shinnin (talk) 15:07, 17 June 2019 (UTC)[reply]
@Shinnin: Thanks! I should learn a little about purging, I guess. (I suppose the purged pages were the sitelink targets, not the wikidata items, which appeared quite OK.) JoergenB (talk) 19:45, 17 June 2019 (UTC)[reply]

Wikidata weekly summary #369

Bots are perpetuating stupid spelling error on Q20880935

On VII. De español y morisca, albino (Q20880935), as far as I can figure out what happened, bots have carefully preserved a stupid spelling error and introduced it into a new project ("Morsica"[sic]). As was discussed on Wikimedia Commons when these files were first uploaded, the so-called experts at LACMA had very little idea what they were doing when they attempted to translate the titles of Casta paintings from Spanish into English (that's why I renamed the main image files to File:VII. De espanol y morisca, albino (Casta painting) LACMA M.2011.20.1 (1 of 6).jpg, File:X. De espanol y torna atras, tente en el aire (Casta painting) LACMA M.2011.20.3 (1 of 6).jpg, and File:IX. De espanol y albina, torna atras (Casta painting) LACMA M.2011.20.2 (1 of 5).jpg) but now it seems that all the LACMA errors and translation infelicities are to be preserved into the indefinite future by bots... AnonMoos (talk) 15:18, 17 June 2019 (UTC)[reply]

Long as the bots leave title (P1476) alone, it should be fine? I mean, I thought the item "names" were mostly for convenience and the actual data was in the statements? Circeus (talk) 17:03, 17 June 2019 (UTC)[reply]
I'd really like to get rid of the semi-incompetent LACMA attempted translations into English completely, but I have no idea whether I'll be getting into an edit war with bots if I attempt to change the relevant nodes... AnonMoos (talk) 00:50, 18 June 2019 (UTC)[reply]
If a bot does something you believe to be wrong, the general idea is to go to the talk page of the bot and raise the issue on that venue. You can also ping the people responsible for the bot. ChristianKl11:22, 18 June 2019 (UTC)[reply]
There are at least two bots on the history of that page; I have no real idea which one is responsible for which aspects of the page's current state, or whether they'll come back if I attempt to change things. What they do is probably beneficial most of the time, but in the particular unusual case of these three particular paintings, they're restoring to prominence errors and awkward strained unfortunate translations which I previously attempted to minimize on Commons.... AnonMoos (talk) 14:14, 18 June 2019 (UTC)[reply]
if you do not like the LACMA spelling errors, maybe you need to talk to them. edit warring about file names or item names is a waste of your time. (they could be in italian, as a lot of the Louvre images are). these are intermediate back of the house signifiers that no one will see; rather, readers will see the image and the text of the article, and the metadata. Slowking4 (talk) 12:26, 18 June 2019 (UTC)[reply]
The Casta paintings are about the Spanish colonial empire, so of course their original titles are in Spanish. "Morsica" is an Italian surname, and is not a meaningful word in the Spanish language. In any case "Morsica" and "morisca" are both simultaneously present in Q20880935, which creates a glaring discrepancy -- and if you go to File:VII. From Spaniard and Morsica, Albino (De espanol y morisca, albino) LACMA M.2011.20.1 (5 of 6).jpg you can read the word "morisca" yourself.
Spanish colonial "casta" classifications are a highly-specialized niche subject. The LACMA people could have a far greater fluent command of the Spanish language and a far greater general knowledge of art history than I do, but when they applied such general background knowledge to the highly specific special area of casta classifications, they made a botch of it... AnonMoos (talk) 14:14, 18 June 2019 (UTC)[reply]
And when people go to the image description page commons:File:VII. De espanol y morisca, albino (Casta painting) LACMA M.2011.20.1 (1 of 6).jpg they'll see the nonsense word "Morsica" in kind of a large font size (in my browser) directly below the summary heading, so it is not an esoteric Wikidata-only thing. AnonMoos (talk) 14:14, 18 June 2019 (UTC)[reply]

SourceMD jobs that are on hold

Hoi, we have a situation regarding performance and when asked it is said that jobs that add to / change the database are very much needed, all changes will find their way into the database. That said, admins have put SourceMD jobs on hold. SourceMD jobs run serially, only one job at a time, they are well behaved, Magnus has done a lot of work recently to make it perform even better. So I am OK when admins put a job on hold, I am not OK when they do not release the jobs afterward. My jobs run for a purpose, I comment on the jobs that I run on twitter and elsewhere.

My point is that well behaved jobs may be put on hold but when the situation permits they have to be released. At this time the database has room for these jobs. Thanks, GerardM (talk) 06:08, 18 June 2019 (UTC)[reply]

Gadget curation

Is there interest in a project about gadget and tool management? there has been some discussion about which gadgets should be on by default, and which are breaking. we need a process to evaluate, migrate, and maintain gadgets and tools. and some FYI's for new editor on boarding, with tutorials for gadgets. Slowking4 (talk) 13:20, 18 June 2019 (UTC)[reply]

Having a Wikiproject for them would make sense. ChristianKl07:46, 19 June 2019 (UTC)[reply]
I'm interested. - PKM (talk) 20:41, 19 June 2019 (UTC)[reply]

List of headers (beta) Couldn't resolve language abreviation

When beta will end? It's broken for months or maybe even years. It is very basic feature and how it can be left like that? It should be fixed long time ago. What we can do? Eurohunter (talk) 15:49, 18 June 2019 (UTC)[reply]

  • ✘ Error :
  • Couldn't resolve language abreviation (olo) sent by the database
  • ✘ Error :
  • Couldn't resolve language abreviation (abs) sent by the database
  • ✘ Error :
  • Couldn't resolve language abreviation (ady) sent by the database
  • ✘ Error :
  • Couldn't resolve language abreviation (aeb-latn) sent by the database
  • ✘ Error :
  • Couldn't resolve language abreviation (atj) sent by the database
  • ✘ Error :
  • Couldn't resolve language abreviation (awa) sent by the database
  • ✘ Error :
  • Couldn't resolve language abreviation (ban) sent by the database
  • ✘ Error :
  • Couldn't resolve language abreviation (bgn) sent by the database
  • ✘ Error :
  • Couldn't resolve language abreviation (btm) sent by the database
  • ✘ Error :
  • Couldn't resolve language abreviation (bto) sent by the database
  • ✘ Error :
  • Couldn't resolve language abreviation (din) sent by the database
  • ✘ Error :
  • Couldn't resolve language abreviation (dty) sent by the database
  • ✘ Error :
  • Couldn't resolve language abreviation (es-419) sent by the database
  • ✘ Error :
  • Couldn't resolve language abreviation (gcr) sent by the database
  • ✘ Error :
  • Couldn't resolve language abreviation (gom) sent by the database
  • ✘ Error :
  • Couldn't resolve language abreviation (kea) sent by the database
  • ✘ Error :
  • Couldn't resolve language abreviation (kjp) sent by the database
  • ✘ Error :
  • Couldn't resolve language abreviation (krl) sent by the database
  • ✘ Error :
  • Couldn't resolve language abreviation (mni) sent by the database
  • ✘ Error :
  • Couldn't resolve language abreviation (mnw) sent by the database
  • ✘ Error :
  • Couldn't resolve language abreviation (nys) sent by the database
  • ✘ Error :
  • Couldn't resolve language abreviation (sdh) sent by the database
  • ✘ Error :
  • Couldn't resolve language abreviation (ses) sent by the database
  • ✘ Error :
  • Couldn't resolve language abreviation (shn) sent by the database
  • ✘ Error :
  • Couldn't resolve language abreviation (shy-latn) sent by the database
  • ✘ Error :
  • Couldn't resolve language abreviation (sje) sent by the database
  • ✘ Error :
  • Couldn't resolve language abreviation (skr) sent by the database
  • ✘ Error :
  • Couldn't resolve language abreviation (smj) sent by the database
  • ✘ Error :
  • Couldn't resolve language abreviation (smn) sent by the database
  • ✘ Error :
  • Couldn't resolve language abreviation (sms) sent by the database
  • ✘ Error :
  • Couldn't resolve language abreviation (tay) sent by the database
  • ✘ Error :
  • Couldn't resolve language abreviation (uz-latn) sent by the database
  • ✘ Error :
  • Couldn't resolve language abreviation (ady-cyrl) sent by the database
  • ✘ Error :
  • Couldn't resolve language abreviation (aeb) sent by the database
  • ✘ Error :
  • Couldn't resolve language abreviation (ase) sent by the database
  • ✘ Error :
  • Couldn't resolve language abreviation (gom-deva) sent by the database
  • ✘ Error :
  • Couldn't resolve language abreviation (nod) sent by the database
  • ✘ Error :
  • Couldn't resolve language abreviation (skr-arab) sent by the database
  • ✘ Error :
  • Couldn't resolve language abreviation (uz-cyrl) sent by the database
  • ✘ Error :
  • Couldn't resolve language abreviation (zgh) sent by the database
  • ✘ Error :
  • Couldn't resolve language abreviation (zh-my) sent by the database

Eurohunter (talk) 15:49, 18 June 2019 (UTC)[reply]

If you complain about a bug, you could start by writing a decent bug report that says how the bug you are concerned about can be reproduced. The ideal place for a bug report would be phabricator. ChristianKl12:02, 19 June 2019 (UTC)[reply]
I read that last as "only people with technical sophistication and serious involvement in the project should report bugs." Have I misunderstood? - Jmabel (talk) 16:08, 19 June 2019 (UTC)[reply]
No, I see no reason for nontechnical people to report bugs on Phabricator. You don't need to be a developer to describe exactly what you did to generate an error message. ChristianKl16:12, 19 June 2019 (UTC)[reply]
@Eurohunter: Where is this "List of headers" feature that's not working? It sounds interesting, but I've never heard of it. —Scs (talk) 22:17, 19 June 2019 (UTC)[reply]
He is talking about the labelLister gadget. --Kam Solusar (talk) 22:27, 19 June 2019 (UTC)[reply]
@Eurohunter: Can you describe why you feel the current labelLister gadget doesn't work for your purposes and why you consider having the List of headers version to be so important? ChristianKl10:27, 20 June 2019 (UTC)[reply]
@ChristianKl: It's impossible to add these languages with List of headers so that's big problem. Eurohunter (talk) 12:21, 20 June 2019 (UTC)[reply]
As long as the gadget is in beta, the only big problem about it is the "beta" flag. Issues can be reported at MediaWiki talk:Gadget-labelLister.js/beta.js. --Matěj Suchánek (talk) 13:03, 20 June 2019 (UTC)[reply]

MetroLyrics ID (P2624) generates error if linked to correct artist page. Format [a-z0-9-']+-lyrics-[a-z0-9-]+ should be for lyrics id and [a-z0-9-']+-lyrics for lyrics id. It seems that two formats can't be added there. Eurohunter (talk) 16:03, 18 June 2019 (UTC)[reply]

Wikimedia Toolforge Recoin

Wikimedia Toolforge Recoin doesn't works? Eurohunter (talk) 20:33, 18 June 2019 (UTC)[reply]

https://tools.wmflabs.org/recoin/getmissingattributes.php?lang=en&subject=Q15074414&n=10
https://tools.wmflabs.org/recoin/getmissingattributes_id.php?lang=en&subject=Q15074414&n=10
See Wikidata talk:Recoin#Outage. --Jklamo (talk) 12:18, 19 June 2019 (UTC) :see[reply]

wb_terms migration to start this week

Hello all,

This is a quick update regarding the beginning migration of wb_terms table replacement solution.

We are about to start migrating property terms this week. The original planned date was 19th of June. Due to WMF US Staff holiday, there will be no deployments today. Therefore, we are going to switch the migration on (write both stage) of property terms one day later than planned, on Thursday the 20th of June. All other dates regarding migration remain the same for the moment.

You can find more information regarding those dates and how to prepare for them in this task, and we have dedicated a board to receive and help with any questions from tool builders that need to update their tools accordingly.

Thanks, Lea Lacroix (WMDE) (talk) 08:43, 19 June 2019 (UTC)[reply]

Currently the links to non-English language pages in the article w:Family tree of the Greek gods are embedded on the page, could someone who knows what they are doing please add them to WikiData and remove them from the page? -- PBS (talk) 10:48, 19 June 2019 (UTC)[reply]

I removed those interwiki links which duplicated Wikidata or went not existing pages. I left he:אלים אולימפיים pointing to the Hebrew article for Twelve Olympians (Q101609) which seems to include a family tree of the Greek gods. --Dipsacus fullonum (talk) 20:51, 19 June 2019 (UTC)[reply]

I was editing the entry for Battle of Waterloo (Q48314) and was surprised to see an "English" and "British English" entry. I have trawled the archive to this page and came up with these discussions:

The ignorance of some of the contributors to the previous conversations are surprising, how for example can someone not be aware that there is a dialect of English called w:Indian English? I find the discussions surprising and some of the comments bigoted, particularly as these were issues addressed more than 10 years before the first archive entry above and was settled inclusively and harmoniously.

Either the two outliers English-GB and English-CA need to be scrapped, or all of the different types of English need to be included. This includes the English used in the USA at the UN and within the EU. (The English used by the UN and EU are different but based on variants of British English).

As has been pointed out in the previous conversations English on Wikipedia is dialect neutral until a dialect word is introduced at which point that dialect spelling or word becomes the default version of the language used for that subject.

It is not as if the data within articles often provides this information:

Or in the case of some where the version of English is obvious to native speakers, other templates that can be indicative for machine reading:

There is a list of the use English dialect templates at w:template:Use X English. If there seem to be too many consider using w:Use Commonwealth English and incorporate into that all the other dialects apart from American and Canadian English.

This is supposed to be a database project, adding or removing attributes ought to be easy, why has this issue not been addressed?

-- PBS (talk) 12:33, 19 June 2019 (UTC)[reply]

We probably should add more types of English labels; there are 12 variants of Chinese available here. Though written (and spoken) Chinese probably varies considerably more than English does. To see the list of available languages for labels, try creating a new item and look at the language dropdown. The process of adding languages to the list however is a bit complex right now. Items do exist for American English (Q7976) and other varieties though. ArthurPSmith (talk) 19:22, 19 June 2019 (UTC)[reply]
There was a very sparsely attended RFC on this way back in 2013 - Wikidata:Requests for comment/Labels and descriptions in language variants. My personal feeling is that we should just get rid of English variants. It can very occasionally defuse an argument in some items, but in practice it's just more maintenance overhead 99.99% of the time. Andrew Gray (talk) 20:18, 19 June 2019 (UTC)[reply]
Thanks for writing this! I agree that more variants should be supported. I'll be happy to support requests for that. --Marsupium (talk) 17:44, 21 June 2019 (UTC)[reply]

Municipal building

Q25550691 and Q543654 relate both to a municipal building?--Susanna Giaccai (talk) 13:04, 19 June 2019 (UTC)[reply]

Seems Rathaus (Q543654) is intended to be the subclass of town hall (Q25550691) specifically to towns and cities, whereas the umbrella class is for all municipalities. But at least the German Wikipedia article linked to the umbrella class is wrong, as it only refers to the municipality offices in Switzerland. So a bit of a mess to clear this one up. And if you like more confusion - in Thailand there's a local government which is not a municipality, but covering a whole province, but its not the province administration itself. So the current English description does not include this special cases, and I guess there may be further in other countries. Ahoerstemeier (talk) 16:45, 19 June 2019 (UTC)[reply]
Indeed. In Sweden (and Swedish), I would say that "rådhus" used to be a kind of municipal building in larger cities which also included the local court. If I remember correctly, the mayor was not only the highest offical in the city, but also in the local court. In Sweden today, we have "Stadshus", "Kommunhus", "Landstingsstadshus". Also the counties and regions have administrativ buildings, but I cannot recall their names now. Sextvå.tvånoll.ettsjunoll.sjufyra (talk) 17:51, 19 June 2019 (UTC)[reply]

Since yesterday, graphs are longer showing with this template. Can someone solve the issue please? Thanks. Ayack (talk) 13:37, 19 June 2019 (UTC)[reply]

Looks to be linked with WDQS query service troubleshoot [Graph:Lines having the same trouble]. Yurik has been aware of this and asked for patience. Bouzinac (talk) 13:43, 19 June 2019 (UTC)[reply]

License data for files on Commons

Hello all. Currently there is a property copyright license (P275) that is mostly used by softwares. I understand that there are some structured data for Commons files at the moment. Would it be possible to develop a bot to migrate license information to WikiData? -Mys 721tx (talk) 13:55, 19 June 2019 (UTC)[reply]

If the property can already be entered to images, and we have a clear translation from the current license templates to the corresponding Q-id's on Wikidata, such a bot-script should be possible indeed. Edoderoo (talk) 05:58, 20 June 2019 (UTC)[reply]
License are attached to a file stored on Commons. They shouldn't be imported to Wikidata because items are mainly about the work (painting for example), and not the digital representation of it (the photo). Ayack (talk) 10:53, 20 June 2019 (UTC)[reply]
Right now, there is some cross-over functionality between Commons and WikiData. So nothing will be imported to WikiData, but something will be made machine-readable on Commons. Technically that is possible, but I'm not sure if anything else than P180 can already be added to Commons. But I believe this would be a great next property to be added to Commons. Edoderoo (talk) 21:18, 20 June 2019 (UTC)[reply]
Very complex to model correctly. For the same image, this can vary from country to country, and we want to model the rationale, not just the [purported] license. There has been quite a bit of discussion of this on Commons; it's not a simple issue. - Jmabel (talk) 01:07, 21 June 2019 (UTC)[reply]
you could model multiple licenses, for the derivative, especially for sculptures. Slowking4 (talk) 19:34, 22 June 2019 (UTC)[reply]

How can one customize permissions in a wikibase instance?

I would like to know how to customize permissions on a wikibase instance created from docker. Is it possible? Any hint to some documentation?

What I would like is to have allow some groups of users to edit some items, while allowing other groups of users to only visualize/query the data.

 – The preceding unsigned comment was added by Jelabra (talk • contribs).

How can I import properties from an ontology in a wikibase instance created with docker?

Is it possible to import properties from an external ontology so I could use them in my own wikibase instance?

For example, if I wanted to use the property owl:disjointWith from OWL in my own wikibase instance, how could I do it?

I saw that I could create my own properties, but I would also like to use other properties from external ontologies.

 – The preceding unsigned comment was added by Jelabra (talk • contribs).

Glossary of topics on how to structure data

Excuse me if this was asked before, or if this is a silly question. Do we have a page or dedicated WikiProject where volunteers could host the most accepted way to structure data (properties, values, qualifiers, etc) for a given subject item? For example (basing on facts shown in the respective infoboxes), the most accepted way to store building data for buildings (floors, height etc), book data (publisher, date, pages, etc), a power station (capacity, fuel, commission date, etc), a disease, a company, a sports club, TV channel, and so on. A place where volunteers can refer when unsure of what information the item should ideally have, and how it should look like... Rehman 12:41, 20 June 2019 (UTC)[reply]

@Rehman: I think the Wikidata:Showcase items are more or less what you’re looking for? --Lucas Werkmeister (talk) 15:07, 20 June 2019 (UTC)[reply]
Also Help:Modeling and the pages it links to directly and indirectly. - Jmabel (talk) 16:10, 20 June 2019 (UTC)[reply]
We should perhaps make a real effort to increase the number of showcase items available --SilentSpike (talk) 23:36, 20 June 2019 (UTC)[reply]
Thanks, Lucas, Jmabel, SilentSpike. Help:Modelling/Other domains is close, and Wikidata:Showcase items may not be practical in my personal opinion. To create a fully or near-fully completed item such as those shown in the Showcase, would take a lot of effort and time, something that would almost surely discourage volunteers as certain information is easily available on one item but not the other - making the task of filling one perfectly quite a challenge.
I was thinking of table like this or this, arranged in a similar fashion like those mentioned in Showcase items, but instead linking or uncollapsing to show the table. Interested volunteers from various WikiProjects/interest areas could then simply add their topics/items, outlining what information a completed item should ideally have.
Thoughts? Rehman 03:17, 21 June 2019 (UTC)[reply]
Perhaps you'll be interested in Wikidata:WikiProject ShEx? --Stevenliuyi (talk) 07:48, 21 June 2019 (UTC)[reply]
Improving accessibility along the lines you are thinking is something I've been interested in for a while (even if just to have a handy reference for myself). The ShEx project does capture that kind of information, though not in an easily accessible way as of yet. --SilentSpike (talk) 10:15, 21 June 2019 (UTC)[reply]
I agree. While it does seem interesting, I don't see how ShEx can help in my problem, at least not in an average volunteer-friendly way. Rehman 14:59, 21 June 2019 (UTC)[reply]
How about a Listeria list of model item (P5869)? I'd like to see "model items" used more widely and made more available to new editors. - PKM (talk) 18:48, 21 June 2019 (UTC)[reply]

Category:Jan Matejko Academy of Fine Arts faculty

Category:Jan Matejko Academy of Fine Arts faculty Q25209935 is identical with articles listed in Q14330581, and therefore should be merged into it. Francesco 13 (talk) 20:48, 20 June 2019 (UTC)[reply]

Ranks mass editing

Since QuickStatements and OpenRefine don't support ranks editing, is there a way to do it without writing a bot? Thanks. Ayack (talk) 15:38, 21 June 2019 (UTC)[reply]

Who is ranks, and why do you want to edit him? But I think you need a tool like PetScan to do such a job. Edoderoo (talk) 16:48, 21 June 2019 (UTC)[reply]
Is this a real question? If so I'm talking about these ranks. Elsewhere, sorry but I don't understand the joke...
How do you change ranks in Petscan? You can only add or remove statement for what I see. Ayack (talk) 18:42, 21 June 2019 (UTC)[reply]
Petscan cannot edit ranks. To the best of my knowledge, you need bot code for "mass editing" of ranks. If you don't have such code by yourself, you could try to request a task at Wikidata:Bot requests. —MisterSynergy (talk) 19:34, 21 June 2019 (UTC)[reply]
Depending on the task you might seek User:PreferentialBot's assistance. --Marsupium (talk) 20:23, 21 June 2019 (UTC)[reply]
@MisterSynergy, Marsupium: Thanks for you answers. I'll try User:PreferentialBot. Ayack (talk) 06:28, 22 June 2019 (UTC)[reply]

How to express possession?

We have owned by (P127). But how to express possession? For example Portrait of a Young Man (Q2422889) was stolen and then in possession of Hans Frank (Q60087) and Adolf Hitler (Q352), but we wouldn't say they owned it after having stolen it. How should we state that information? Thanks in advance, --Marsupium (talk) 18:24, 21 June 2019 (UTC)[reply]

private collection (Q768717) qualified with the collector? - PKM (talk) 18:45, 21 June 2019 (UTC)[reply]
Hm, one can probably speak of a collection in the example above. I meant to ask more generally where this doesn't work I think. Another example would be the ship MV Danica White (Q6719433) which was in possession of pirates while they didn't own it and we probably can't say it was in their private collection (Q768717). --Marsupium (talk) 21:19, 21 June 2019 (UTC)[reply]
One option is operator (P137). --Shinnin (talk) 21:24, 21 June 2019 (UTC)[reply]
Hm, yes, this works in many other cases and still this is different. --Marsupium (talk) 00:41, 22 June 2019 (UTC)[reply]
How about 'held by'? This could apply to many situations. Abductive (talk) 00:13, 23 June 2019 (UTC)[reply]

Common.css clean up

Hey, With introduction of TemplateStyles, there is no need to put CSS of all templates like Navbox in Mediawiki:Common.css anymore, You can simply put them in a page like Template:Navbox/styles.css and inject those into DOM when needed (that makes lots of sense for templates with limited usage because Common.css is loaded on *every* page). So I started a big clean up of the common.css page and now 8 kilobyte is removed from there, with minification and gzip compression that's around one kilobyte less in every request which adds up to around 4 Terabyte of data every month (not to mention CPU usage in our infra to minify and compress the given CSS).

If you see any template misbehaving, let me know. It might be caused by this cleanup. Amir (talk) 18:52, 21 June 2019 (UTC)[reply]

Multilanguage label

Hi, all. I have an idea to add new feature: language-independent (or multiple-language) label. We have many items which have such labels but they are spread now across all languages, as labels or more often as aliases. I am talking about persons (which have original names), names themselves, creative works, some scientific stuff like chemical elements and even articles. Now it is tradition to add such labels in all possible languages (random example) which is overkilling in my opinion. I know we have title (P1476)/native label (P1705), name in native language (P1559)/birth name (P1477) but I am talking about label which can help in suggestions and search. Introducing such label we might replace labels in many languages with one ("Wikidata-way", isn't it?). --Infovarius (talk) 20:51, 21 June 2019 (UTC)[reply]

Sounds like it could be a good solution. Latin script languages could default to a mul-Latn label just like en-GB defaults to en. --Marsupium (talk) 00:37, 22 June 2019 (UTC)[reply]

Mask and Wig (Q3297279)

This entry is for a historic building; but the enwiki and frwiki articles it links to are both about the club which the building houses. I suspect the right way to proceed is to create a new Item for the club, and attache those two articles to it instead; but it's a while since I created a Wikidata item, and I think things have changed a bit. --ColinFine (talk) 23:04, 21 June 2019 (UTC)[reply]

I think you're correct. It's commonplace to conflate the structure and the occupying organisation/business, but they are & should be distinct entities. --Tagishsimon (talk) 09:56, 22 June 2019 (UTC)[reply]

Non-notable spouses of notable people

Hi!

I am seeing some weird modeling for recording spouses of notable people who are not notable by themselves and do not have Wikidata entry. I've seen putting first name item or last name item as spouse (P26) (clearly wrong), putting "no value" (also wrong), or "unknown value" (slightly more right but still not completely since it is not really unknown). Also for recording the name of the spouse properties like author name string (P2093) or married name (P2562) are used as qualifiers, which also seems wrong and also non-translatable. Examples: Alexander Gordon (Q1961223) and Nana Kiknadze (Q4220426), probably many more. So, I wonder what to do here?

  1. Remove bad data and leave the spouse name unrecorded
  2. Create an item for the spouse, even if no good sources exist for anything but name, for example, and they by themselves are not notable
  3. Create a property that is specifically for recording spouse names
  4. Use some existing property that I missed but actually works for spouses (unfortunately, values can not be multi-lingual...)
  5. Use one of the properties mentioned above is just fine and I am misunderstanding their meaning - e.g. maybe married name (P2562) is ok and I am misunderstanding it
  6. Some other ideas?

Laboramus (talk) 23:42, 21 June 2019 (UTC)[reply]

  • I thought we were doing #2. --- Jura 00:21, 22 June 2019 (UTC)[reply]
  • I think #2 i best option, it takes just slightly longer than filling in a text string that would contain the spouses name in a new field. --RAN (talk) 01:24, 22 June 2019 (UTC)[reply]
  • 2 seems correct to me, aren't they by definition notable for wikidata as per criteria 3 --SilentSpike (talk) 09:37, 22 June 2019 (UTC)[reply]
  • Maybe I should note that I use #2 for people who died some time ago and there is some interest in doing so given their family relations. I doubt there is much benefit in doing the same for living people (it might even appear a bit "odd"), especially for people who are hardly known beyond a publication of some paper.
    I don't know the two sample people mentioned by Laboramus, but, as start and end dates are unknown, it doesn't look like information worth including. For living people, I'd tend to proceed per #1. --- Jura 09:56, 22 June 2019 (UTC)[reply]
  • As somebody who tends to use the "unknown value" option: Creating an item for the spouse (if still living) is in my opinion a bad idea for privacy reasons (even if the creator only includes the name and no other personal information: who is going to watch potentially thousands of items for non-notable spouses for unsourced additions of personal information?). I also dislike the removal of "unknown value" statements at it is at least notable that the person is or was married, maybe even how often and from when till when. I agree that "unknown" is not completely true, but I still consider a person of that only the name and the fact that she is married to x is known as relatively unknown. I generally agree with the way it is modelled at Alexander Gordon (Q1961223) (apart from some missing references), but to record the name I tend to use name (P2561) (there is also object named as (P1932)).
For the cases with first/last name as the value: I agree that these statements should be deleted or converted. Valentina.Anitnelav (talk) 11:29, 22 June 2019 (UTC)[reply]
@Valentina.Anitnelav: As you say, <unknown value> is not true. Please stop putting untrue data into wikidata. It's really a very wrong thing to do, for the obvious reason that it is not true. Whatever your privacy concerns, it is not acceptable to assuage them by damaging wikidata. --Tagishsimon (talk) 07:49, 24 June 2019 (UTC)[reply]
@Tagishsimon: It's common practice to use <somevalue> with qualifier object named as (P1932) to record somebody or something which is known but doesn't have a Wikidata item -- eg a creator of a work, a publisher, etc. It allows full data from the extraction to be included here, with the ability to return and create items at a later time.
The error is using the name <unknown value> for <somevalue>. Jheald (talk) 10:54, 24 June 2019 (UTC)[reply]

Q6227624

Can someone look at John Crichton, 4th Earl Erne (Q6227624). The property Property:P2015 requires that a person be listed as a "member of parliament" and we have him listed as "Member of the 22nd Parliament of the United Kingdom" which is a subclass of "member of parliament". Can someone adjust the restrictions to allow the proper subclass? --RAN (talk) 01:27, 22 June 2019 (UTC)[reply]

I've experimentally added a complex constraint and removed the simple constraint for the P39 value in Property talk:P2015 ... either there's some bot latency before it gets picked up, or it's a fail. we'll see. --Tagishsimon (talk) 09:50, 22 June 2019 (UTC)[reply]

Same place?

This data and this data seems to be about the same city in Brazil. However, it seems that there are duplicate articles at the sv.wiki and the ceb.wiki. What do you people think?  – The preceding unsigned comment was added by SirEdimon (talk • contribs) at 22. 6. 2019, 01:33‎ (UTC).

A distinction is being drawn between the municipality (Q996763), and the main settlement/town within the municipality (Q22015573). None of the three language wikis I looked at (en, de, pl) seem to apprehend the distinction, but it seems reasonable from a) looking at openstreetmap - there's a town within a much larger rural area and b) support from geonames for the two as distinct entities, one nested within the other. Ceb (and maybe sv) seem mainly to be bot-written distillations of geonames and operate at a higher level of granularity than many of us are comfortable with; but discomfort is probably good for us. --Tagishsimon (talk) 02:22, 22 June 2019 (UTC)[reply]
There are mixed feeling about these on svwiki. We have two articles in Sweden, but that is because the municipality today (almost) always is much much larger than the populated place naming the municipality. Some users think we should follow the same principle about non-Swedish sites as we do to Swedish. Most users agree about the principle as such. But what should we fill the articles with? In Sweden we have good statistics about the populated places. But outside the Nordic countries, it is hard for us to find such statistics. And be aware! Geonames is a terrible source for verifing that there is a place with a specific name. They are (fairly) good at administrative entities as municipalities, but awful on populated places. Sextvå.tvånoll.ettsjunoll.sjufyra (talk) 08:02, 22 June 2019 (UTC)[reply]
That makes no sense. Here, in Brazil, the city and the municipality are the same entity. Check this date from the IBGE (Brazilian Institute of Geography and Statistics): [1].--SirEdimon (talk) 03:06, 23 June 2019 (UTC)[reply]
Perhaps these two pieces of data should be merged.--SirEdimon (talk) 03:08, 23 June 2019 (UTC)[reply]
That makes fine sense. A municipality is an administrative unit covering an area of land. A settlement is a continuous group of houses which often covers a lesser area than a municipality, but in some cases may cross a municipality border. A merging would be wrong. --Dipsacus fullonum (talk) 06:51, 23 June 2019 (UTC)[reply]
@SirEdimon: Also in Sweden, a city is a subclass of a municipality so it is almost the same thing. But as @Dipsacus fullonum: describes, a Settlement is not the same thing as a municipality. A settlement may have a school, but it does not legally own or run the school since it is not a juridical person like the municipality is. The city/municipality is an organisation who (often) serve a well defined geographic area. A settlement is not an organisation or person, but always a geographic area, which sometimes is well defined but often has fuzzy borders. What makes it confusing, is that settlements who do not are organisations, sometimes are named "city" or "town" without being an organisation or person. In English they sometimes call such things an "unincorporated city/town", but that does not describe a typical Swedish settlement since, as far as I know, all areas in the Nordic countries are incorporated in a municipality with the exception of a military base in Denmark. Sextvå.tvånoll.ettsjunoll.sjufyra (talk) 07:43, 23 June 2019 (UTC)[reply]
I think it's similar in many countries, certainly in Australia, the UK and the Netherlands you can have several towns administered by the same local government. In these cases, it's obvious that the towns and the administrative area are different entities. It's more confusing when they overlap to a large extent, as for the urban area of a city, e.g., Amsterdam (Q727) vs Amsterdam (Q9899). Using either type of thing to identify locations can be problematic, since town boundaries are not always well-defined, and can change with new construction. Administrative areas are prone to boundary changes and amalgamations. Ghouston (talk) 10:56, 23 June 2019 (UTC)[reply]
Conversely, in the U.S.: I'm wondering about how this model works for, say, Ruston (Q1507715) and Tacoma (Q199797). Ruston is an enclave in Tacoma; unless there is a sign on the street you are on, you'd never know when you are passing from one to the other. For all intents and purposes they are a single urban area, but years ago Ruston was an ASARCO (Q4654057) company town, and it was never letally integrated into Tacoma. - Jmabel (talk) 18:04, 23 June 2019 (UTC)[reply]
We used to have different laws for different types of municipalies here. There were rural municipalities, with limited services and also less taxes. A city had more services and higher taxes. A rural municipality could have a lower tier municipality within itself. Those could give complementary services, like city planning, fire fighting etc. Today all municipalities have to provide the same kind of services. To make it cheaper, municipalities often cooperates. Firefighting in my municipality is for example provided in cooperation with two neighbour municipalities. Sextvå.tvånoll.ettsjunoll.sjufyra (talk) 19:49, 23 June 2019 (UTC)[reply]

Could this item be (semi)protected ? The English label is being repeatedly changed by anons to some particular date of birth ? -- Kpjas (talk) 07:11, 22 June 2019 (UTC)[reply]

✓ Done. I noticed that all the ip's seem to be from India. Any idea why this is happening? Multichill (talk) 09:37, 22 June 2019 (UTC)[reply]

Membership in a military unit

Is there a way to designate membership or service of a person in a military unit, such as a brigade (Q102356), military division (Q169534)?

Some related properties are employer (P108), military branch (P241), commander of (DEPRECATED) (P598), and allegiance (P945), but none of them is quite right:

I looked at items about several notable soldiers (Alexander Matrosov (Q468094), Nikolai Gastello (Q2997156), and Lenina Varshavskaya (Q16629269) and couldn't find anything like that. I was surprised somewhat, given that there are a lot of Wikipedians who love military history, and it's quite easy to find references for membership in units.

If there is no appropriate property, does it make sense to add one? --Amir E. Aharoni (talk) 08:50, 22 June 2019 (UTC)[reply]

member of (P463)? --Tagishsimon (talk) 09:53, 22 June 2019 (UTC)[reply]
I've done a few with member of (P463) as a qualifier of military branch (P241). It doesn't seem popular:
SELECT ?person
WHERE {
  ?person p:P241 ?s.
  ?s pq:P463 ?unit.
}
Try it!
. Ghouston (talk) 10:58, 22 June 2019 (UTC)[reply]
I wasn't suggesting Member Of as a qualifier - sorry, should have been clearer. --Tagishsimon (talk) 12:34, 22 June 2019 (UTC)[reply]
Here are the results of a query to find the most common property used to connect items with occupation (P106) = some instance or subclass of warrior (Q1250916) with items in subclasses of armed organization (Q17149090):
Looking at some of the top results:
Hope this helps, Jheald (talk) 11:32, 22 June 2019 (UTC)[reply]
member of (P463) indeed looks like the closest thing, but it's also not perfect. It's a membership in an organization, and a military unit is not quite the same as a club or a youth movement. --Amir E. Aharoni (talk) 11:49, 22 June 2019 (UTC)[reply]
It's more of an employment relationship, but the unit isn't the employer, in the way that a university department probably wouldn't be an employer. I suppose that's why it seemed logical to me to make the unit a qualifier of the main relationship. Ghouston (talk) 12:39, 22 June 2019 (UTC)[reply]
Looking at the talkpage, it seems I suggested using member of (P463) for this back in 2014, and had completely forgotten about it! Ooops :-) I think either this or a dedicated property would be a reasonable approach. I am not keen on the qualifier-to-P241 approach because this could potentially change a lot over time, and things might get complicated with multiple sets of qualifiers. In some countries/contexts, you might also get people from different P241s in the same unit, which would make searching for a list a bit confusing. Andrew Gray (talk) 13:22, 22 June 2019 (UTC)[reply]

Need a merge

Probably not the right place, but the last time it goes (very) quick this way, so....

The item Q1905167 with [nl:Nederlands softbalteam (mannen)] + [hr: Nizozemska softbolska reprezentacija] should be merged with item Netherlands men's national softball team (Q16238071) with [en:Netherlands men's national softball team]. Again, thanks for do so! Kind regards, Pucky (talk) 09:20, 22 June 2019 (UTC)[reply]
Done; thanks. --Tagishsimon (talk) 09:42, 22 June 2019 (UTC)[reply]

La fin prématurée et le regroupement des hôpitaux en France ?

Ces temps ci,beaucoup de services ferment dans les hôpitaux.Serais ce la fin de certains hôpitaux et l'augmentation du taux de chômage?Exemple:l'hôpital de Boscamnant ferme très probablement dans trois ans car le patrons crée des embrouilles entres les médecins.Trois sur cinq médecins ont démissionné .Les employés sont peu à peu commencés à être transférés sur Jonzac.

procedural side question

Is it appropriate to move a question like this to Wikidata:Bistro? —Scs (talk) 22:23, 22 June 2019 (UTC)[reply]

It's not even at all wikidata related whatsoever. It's just rambling about the French healthcare system. Circeus (talk) 03:38, 23 June 2019 (UTC)[reply]

Problem with value type constraint

I added the statement Q64778853 carries (P2505) footpath (Q3352369) for a footbridge, but it gives a value type constraint: "Values of carries statements should be instances of one of the following classes (or of one of their subclasses), but footpath currently isn't:

  • thoroughfare
  • watercourse
  • transport line"

footpath (Q3352369) is a subclass of road (Q34442) which is a subclass of thoroughfare (Q83620), but I suppose it want an instance of footpath rather than the class. Is it necessary to create an item for "the footpath carried by the bridge Høllingers Bro" to statisfy the constraint? I would feel it was a little foolish as the item wouldn't have any new information. What do you say? --Dipsacus fullonum (talk) 23:41, 22 June 2019 (UTC)[reply]

This is because the relation (P2309) is instance of (Q21503252), switching it over to instance or subclass of (Q30208840) should generate the behavior you were expecting (after however long it takes for such a change to propagate). See Help:Property_constraints_portal/Value_type for the details. Circeus (talk) 03:44, 23 June 2019 (UTC)[reply]

Shouldn't there be properties for other alphabets too or different variations like for names in Lithuanian or Azerbaijani? Eurohunter (talk) 07:48, 23 June 2019 (UTC)[reply]

This is not meant for western names, but for transcription of Japanese name (basically en:Furigana) Circeus (talk) 18:48, 23 June 2019 (UTC)[reply]

duplicates from BD Gest' import

It looks as though a recent MnM import for BD Gest' author ID (P5491), circa 28 May, may have created a number of duplicate items.

The database has separate IDs for pseudonyms, eg [2], identified as such in the fiche and linked to other entries for each author. New items seem to have been created via MnM for pseudonyms that MnM could not name-match to Wikidata authors.

I've found quite a few of these on the report page for people with matching dates of birth and death; but this will only catch authors who are (i) dead, and (ii) have full (day-specific) dates of birth and death.

Duplicates may also have been created where the name in the database was not an exact match for name(s) we have here; but these may be harder to catch.

I have a bit too much to do at the moment to go in in depth and clean this up, so if somebody could step in and sort it out I would be grateful. Jheald (talk) 13:34, 23 June 2019 (UTC)[reply]

Came across a somewhat similar problem with Encyclopedia of Science Fiction ID (P5357) as the encyclopedia too has separate entries for pseudonyms and pen names (though they are often little more than "pen name used by author X"). Which led me to wonder in which cases it might make sense to create separate items for such pseudonyms and pen names. I guess for pen names used by just one person it's not necessarily neeeded, but we'd need to have a way to model which pseudonym the ID refers to. But there are also pen names shared by several authors or owned by a publisher, where I think it might be better to create separate items. --Kam Solusar (talk) 15:30, 23 June 2019 (UTC)[reply]
A applies to name of subject (P5168) qualifier can be added to the identifier statement. Ghouston (talk) 02:58, 24 June 2019 (UTC)[reply]
@Ghouston: Thanks. I'd been adding subject named as (P1810) to the multiples I was finding. I can see that P5168 is useful as a qualifier for eg named after (P138), but I somewhat prefer P1810 for identifiers because for many identifiers people add it anyway for all items. Jheald (talk) 09:29, 24 June 2019 (UTC)[reply]
@Kam Solusar: Agreed that for eg house pseudonyms shared by multiple authors, or eg Nicolas Bourbaki (Q190529), in such circumstances it may well make sense to have a particular item. But not sure how one would link eg both the house pseudonym item and the actual author item in a author (P50) statement. The usual object named as (P1932) used to indicate the pseudonym that an author used for a book lets one specify a string, but not an item. Jheald (talk) 09:38, 24 June 2019 (UTC)[reply]

Film poster

At https://www.wikidata.org/wiki/Q2709440 I added the image File:Poster for Jules Massenet's La Navarraise with Emma Calvé in the rôle of Anita.jpg. It complains that the value should be "film poster" not "image".

This is not a film poster, it's a poster for a theatrical performance. The check is clearly wrong; calling it a film poster would be misleading. If the value was changed from "film poster" to "poster" it would be accurate, but this sort of auto-correct, "The value for image (Poster for Jules Massenet's La Navarraise with Emma Calvé in the rôle of Anita.jpg) should match “please use P3383 ("film poster") instead” (regex: (?i)((?!\b(poster)).)*)." - is just bad programming, if there's no checks it's a film.

And why use something specific like "film poster" anyway? A more generic term would be far, far more useful. Adam Cuerden (talk) 10:44, 24 June 2019 (UTC)[reply]


On the subject of images, shouldn't we allow "featured picture" or "Valued image" as a reference type? Adam Cuerden (talk) 10:49, 24 June 2019 (UTC)[reply]