Shortcut: WD:PC

Wikidata:Project chat: Difference between revisions

From Wikidata
Jump to navigation Jump to search
Browse history interactively
← Older editNewer edit →
Content deleted Content added
VisualWikitext
Be..anyone (talk | contribs)
436 edits
Crowegian (talk | contribs)
11 edits
Line 515: Line 515:
Hi,
Hi,


I'm a researcher in the Biomedical Informatics Research Program at Stanford University and we are interested in incorporating drug-target information from [http://www.drugbank.ca/ DrugBank] to Wikidata. Specifically, we would like to add to Andrew Su's work on importing drug/proten data. Also, because DrugBank contains information about drugs and their targets we would be able to add relational data to both items. Best-Oliver
I work with the Dumontier Lab in the Biomedical Informatics Research Program at Stanford University and we are interested in incorporating drug-target information from [http://www.drugbank.ca/ DrugBank] to Wikidata. Specifically, we would like to add to Andrew Su's work on importing drug/proten data. Also, because DrugBank contains information about drugs and their targets we would be able to add relational data to both items. Best-Oliver


== The last of MediaWiki ==
== The last of MediaWiki ==

Revision as of 12:53, 24 April 2016

Wikidata project chat
Place used to discuss any and all aspects of Wikidata: the project itself, policy and proposals, individual data items, technical issues, etc.
Please take a look at the frequently asked questions to see if your question has already been answered.
Also see status updates to keep up-to-date on important things around Wikidata.
Requests for deletions can be made here.
Merging instructions can be found here.

IRC channel: #wikidataconnect
Start a new discussion
Edit
On this page, old discussions are archived. An overview of all archives can be found at this page's archive index. The current archive is located at 2024/07.
SpBot archives all sections tagged with {{Section resolved|1=~~~~}} after 1 day.

gsw - Alemannic/Swiss German in labels and descriptions?

Possibly Harry Canyon has already brought up this issue somewhere here, but as I couldn't find a discussion... Well, there is a recent discussion in German-language Wikipedia dealing with the meaningfulness of offering Wikidata labels/descriptions in Swiss German (gsw). Some background:

  • One of the four national languages of Switzerland is German.
  • There is a Swiss variant of Standard German, called Schweizer Hochdeutsch, Schriftdeutsch, or Swiss Standard German in English. The IETF language tag for that is de-CH. Its differences to the Standard German of Germany (de-DE) and that of Austria (de-AT) are comparable to the differences between British English and American English (slightly different vocabulary and spelling, probably most notably the absence of the letter ß which is represented by ss).
  • There is also a variety of Alemannic German dialects in Switzerland that are grouped together as Schweizerdeutsch, Schwyzerdütsch, or Swiss German in English. The ISO 639-2 code for Swiss German is gsw, which however encompasses actually all Alemannic dialects including the Alsatian dialect. As Swiss German is no single dialect, but a group of Alemannic dialects, there are notable differences e.g. between Bernese Swiss German and Basel Swiss German. There isn't a "Standard Swiss German", so the same words are written in totally different ways by different people depending on dialect. For example, a simple word such as "window" ("Fenster" in Standard German) might be written as Faischter, Fentschier, Finschter, Föischter and in many more variants, and all of them are Alemannic, or Swiss German (gsw).
  • There is an Alemannic Wikipedia. Its community has decided that authors can write in their own dialect. So, Alemannic Wikipedia contains articles e.g. in the Alemannic dialect of Southwest Germany, but also in Alsatian, and in many variants of Swiss German.

Wikidata offers Swiss German (gsw) for labels and descriptions. Given the above, I (as a person from Switzerland) think that doesn't make much sense. There is currently no Swiss German label and description for Q35473 (window) - what should we add? Personally, based upon my Swiss German dialect, I would write Fänschter, and translate the English description transparent or translucent opening maybe as en Öffnig, wo duursichtig isch oder öppis duureschimmere lood. My neighbour most probably would write it completely differently. My opinion therefore is:

  • Don't offer labelling/describing in generic gsw. Writing in many dialects may work in a Wikipedia, but I think it's a nightmare for a database such as Wikidata, where a label in gsw would be in a random, unpredictable dialect, and if a would prefer a different dialect of gsw, who says which one should be chosen?
  • It might, however, be possible and somewhat meaningful to offer Swiss Standard German (de-CH). For example, Fussball instead of Fußball, or Abwart instead of Hausmeister. But I'm not sure that it's really needed.

Anyway, my proposal is to remove gsw from Wikidata for the time being. Is there some other, more official way than this page? Whou should be notified? And, of course, I would love to read reasons for keeping it here, and ideas on how to proceed in that case given the variety of dialects encompassed by gsw. To start, I will notify some users involved in the previous discussion on German-language Wikipedia. Gestumblindi (talk) 20:15, 8 April 2016 (UTC)[reply]

Gestumblindi - Does the same issue apply to the 'als' language label (there is an 'als' wiki but no 'gsw' wiki, so are they the same thing or not quite?) One solution here without removing 'gsw' might be to use the "Also known as" labels for spellings in different dialects; that way searches will find the entries however the main label is spelled. If there could be a default (most common?) dialect selected for the main labels that would be nice but it sounds like that might not be an option here? ArthurPSmith (talk) 21:21, 8 April 2016 (UTC)[reply]
ArthurPSmith Yes, they are the same thing, for all practical purposes. If I remember correctly, the Alemannic Wikipedia is using als instead of gsw as a label for historical reasons (because they started as an Alsatian Wikipedia) and probably because gsw, although officially encompassing all Alemannic dialects (including those from the neighbouring regions in Germany, France, and Austria), looks too much like "Switzerland-only" (German-Swiss). But Holder who is the expert for Alemannic Wikipedia can probably say more regarding that or may correct me (I already notified him of this thread). To complicate matters, als is actually the ISO 639-3 code for Tosk Albanian, but we don't have a Tosk Albanian Wikipedia as yet... - No, I don't see a "most common" dialect as an option here. There is no such Alemannic dialect. And apart from this, even if you stay with one dialect, people spell words differently. A person from Basel might feel inclined to spell "window" as Fänschter, but Fänster would also be possible, for example (the pronunciation in both cases being the same). So, it wouldn't help much to add "Also known as" for Basel German, Zürich German, Walliserdeutsch, Alsatian etc., because there is no fixed spelling for any of them (there are attempts at standardisation, but even e.g. the Alsatian Orthal isn't an attempt to create an unified Standard Alsatian, but a standardised way of describing regional variants). As I see it, the "Also known as" approach would result in a list of arbitrary spelling variants for a gsw entry (potentially dozens each) which still would be likely to not contain the actual spelling variant which a random user would choose to search for. Gestumblindi (talk) 21:46, 8 April 2016 (UTC)[reply]

Dear all.

Today the code gsw is the most important language code of Alemannic language (there are three other codes for some special variants of Alemannic). Alemannic Wikipedia has been created on als.wikipedia.org instead of gsw.wikipedia.org for historical reasons because there have been several revisions of the language code gsw. In the first revision gsw was the code for Swiss German. In 2003 als.wikipedia.org was created as Alsatian Wikipedia (Alsatian is part of Alemannic but no part of Swiss German) and in that year gsw didn’t include Alsatian. But after some revisions of Ethnologue now gsw includes also Alsatian and some other Alemannic variants (unfortunately not all of them).

Since about ten years there are discussions on moving als.wikipedia.org to gsw.wikipedia.org. But as also Norwegian (Bokmal) Wikipedia has to be moved from no.wikipedia.org to nb.wikipedia.org there are huge technical difficulties that haven’t been solved. On translatewiki gsw was used for Alemannic from the beginning and also on Commons and meta gsw ist used for Alemannic translations. And also on Wikidata!

So since about ten years we have this contradiction: als code in in the URL of Alemannic Wikipedia and gsw in the software for all Alemannic translations. So please don’t remove gsw from Wikidata!

--Holder (talk) 04:06, 9 April 2016 (UTC)[reply]

That a language does not have a well defined or consistent orthography (Q43091) does not look as a good reason to exclude them from Wikidata. Such a rule could potentially exclude many languages from Wikidata. Even some languages with a well defined orthography can have a set of words with more than one accepted spelling. Take for example a look in the Swedish (sv) spelling of  Support in our templates here at Wikidata compared with those on Commons. Both are right, and we do not have to be consistent between two different projects. The Swedish language has two language academies, one in Sweden and one in Finland. I have proposed that Wikidata should support also the Finnish version (sv-fi). I would not oppose support for Estonian and Ukrainian Swedish, but I have not come across one single user who talks or writes those languages. -- Innocent bystander (talk) 06:07, 9 April 2016 (UTC)[reply]
Innocent bystander: Swedish orthography is well defined, I think - there are variants, but all of them well defined, and one can choose one of them. Just like de-DE and de-CH - both the Standard German of Germany and Swiss Standard German are well defined; a person from Switzerland writes "Fussball" whereas German and Austrian people use the spelling "Fußball", no problem. The case of Alemannic dialects is different. Actually, to support gsw, Wikidata would need something like a three- to four-tiered structure for it, for example again "window" ("Fenster" in Standard German):
  • Alemannic (gsw)
    • Swiss German
      • Basel German
        • Basel German spelling variant 1: Fenschter
        • Basel German spelling variant 2: Fänschter
        • Basel German spelling variant 3: Fänster
        • Basel German spelling variant ...
      • Luzern German
        • Luzern German spelling variant 1: Fönschter
        • Luzern German spelling variant 2: Fünschter
        • Luzern German spelling variant 3: Faischter
        • Luzern German spelling variant 4: Feischter
        • Luzern German spelling variant ...
    • Alsatian
      • Mulhouse German
        • Mulhouse German spelling variant 1: Fënster [not sure about that, just as an example]
    • Vorarlberg German
... and so on. And you don't have an academy that defines spelling variants. Every Swiss person, when writing Swiss German, just writes as they think the word sounds in their dialect. Being from Switzerland myself, I don't think this is realistically compatible with Wikidata. And I would never actually look for anything here in Swiss German, as Swiss German is a widely spoken language that, however, is not usually written in a formal context (such as a knowledge database). The Alemannic Wikipedia is a project that didn't originate in Switzerland and, for a long time, it was hard for me to even understand its purpose. I see now its value as a cultural project especially for the regions of Alsace and southern Germany where the existence of Alemannic dialects is threatened (in the German-speaking part of Switzerland, all speak it everyday, but use it in writing only in informal context such as in mobile phone messages or personal e-mails). But trying to use a language/dialect with all its sub-dialects and a myriad of possible spellings for each word for a database such as Wikidata... can that work? Gestumblindi (talk) 13:42, 9 April 2016 (UTC)[reply]
You know Gestumblindi, that is the same problem as writing encyclopedic articles on Alemannic Wikipedia. We have different dialects with several possible spellings for every dialect. And have a look at alswp: that works! It's a wiki. Everybody can write his/her own dialect with his/her own spelling. Why shouldn't it also work on Wikidata? Of course there will be different dialects with different spellings (not myriads but some). But what's the problem with that? --Holder (talk) 15:17, 9 April 2016 (UTC)[reply]
Holder Well, yes, I think it's different... Alemannic Wikipedia's headwords (lemmata) are in Standard German, after all. For example, the article about television is als:Fernsehen. The title is displayed in an Alemannic dialect as "Färnsee" using the template {{Titel|Färnsee}}, but the actual article headwords are all maintained in Standard German. So, even Alemannic Wikipedia is using Standard German for the "technical backend", so to speak. And what else is Wikidata? A more sophisticated technical backend, a collection of structured data used for generating and linking content, that needs to contain predictable data following clear criteria. Just as you decided to use Standard German for the headwords in Alemannic Wikipedia - I suppose for practical purposes of feasability - we should look at what is really feasible in Wikidata. As I tried to outline above, we have basically two choices here: Either let gsw stand as it currently is (but, I think you would agree, rename it from Swiss German to Alemannic?), and let people just enter labels and descriptions in their respective dialect, arbitrarily. So, the "window" entry for gsw might contain either "Fenschter" or "Feischter" or whatever, and I assume we would simply stick with the first variant entered. I have to say that this approach doesn't really convince me. The other approach, with finely tuned attributions such as "Zürich German", "Alsatian" etc., would be very complex, and - at least it seems to me - of little practical use. Gestumblindi (talk) 15:56, 9 April 2016 (UTC)[reply]
Gestumblindi, well, that's also different :-)). The headwords are written in Standard German because thus the articles are easier to find per search function. But what actually should be the practical use of such descriptions?
Another point is: would you exclude all languages from Wikidata with different variants and without a well definied spelling because of this problem? Then most languages in the world would be excluded. --Holder (talk) 17:43, 9 April 2016 (UTC)[reply]
Holder: I think (Wikidata experts, please correct me if necessary) that the purpose of Wikidata labels and descriptions is twofold: One use is helping users to find and identify items using their own language; the other, maybe, to generate "information units" such as infoboxes and the like in various projects, also outside of Wikimedia. For all these purposes, I think Alemannic is ill suited: For finding the item for "window" in Alemannic, we would need to add every likely variant from Fänschter to Föister. For identifying, we don't need any Alemannic at all, as there are no "Alemannic-only" speakers. Alemannic speakers read and write Standard German (or French) as well, so we can identify any item with a Standard German (or French) description. Finally, generating infoboxes etc. out of an arbitrary mix of Alemannic dialects, resulting in a "mixed dialect" that doesn't exist anywhere in reality, would be a bad idea too, IMHO. - Regarding your other point: I think we need to look at each language individually. For now, this discussion is about the specific circumstances of Alemannic and not about "all languages ... with different variants and without a well defined spelling". There might be other surrounding conditions that make it meaningful to use a language in Wikidata, but here I still don't really see the point, or simply: the feasibility. But, well - which approach would you support? How do you think that Alemannic should be used in Wikidata, if you think it's possible in a meaningful way? Rather a "stick with one variant" or "add many more variants" approach? Gestumblindi (talk) 18:03, 9 April 2016 (UTC)[reply]
NB! The titles of the pages on alswiki can be found in the sitelinks, and you are free to use the de-labels on Wikidata in your templates on alswiki if you like. Any label in any language is possible to reach by the help of a Lua-module. The Lua-modules we have on svwiki has a fallback-support that allows any language to be displayed, not only English and the other Scandinavian languages. If the only label available is in Urdu, the Urdu label is displayed. -- Innocent bystander (talk) 19:50, 9 April 2016 (UTC)[reply]
Gestumblindi As I understood, Wikdata was created to support small language projects. So if somebody wants to create infoboxes on Alemannic Wikipedia he can have a look after the used descriptions and correct them. But if Alemannic is removed from the languages here there is no possibility to create such infoboxes on als:wp. I think we could discuss this again when there are real plans for such automatically created templates on als:wp.
To my impression there are very few people creating descriptions in Alemannic (gsw) here on Wikidata. So I think that in fact there is no problem with different spellings. Perhaps there could be such problems as you described in the future, but should we implement such unsatisfying solutions because there may be problems one day? --Holder (talk) 12:41, 10 April 2016 (UTC)[reply]
Holder: I do not think that "people aren't really using it, and therefore we don't have any problems" is a really strong argument for keeping ;-) - it seems that, conversely, you'd concede that it would become problematic in its current form as soon as it would be more widely used? But the problems are already starting, every time one actually thinks of adding a "Swiss German" (Alemannic) label and description. After all, the starting point of this discussion was the actual question by Harry Canyon in the German-language WP discussion, where he asked for a translation for Wikidata: Wie schreibt man auf schweizerdeutsch „weiblicher Vorname“?, "How do you write female given name in Swiss German?" - and we can't answer that question. de:User:= (yes, = is his username ;-) ) replied, somewhat tongue-in-cheek: Schweizerdeutsch existiert nicht - "there is no Swiss German". Meaning that there is no unified Swiss German, of course. Harry could write wybliche Vorname, wiibliche Vorname, wibliche Vorname, wyblige Vorname, wyblige Voorname etc. Well, currently there still is no Swiss German label and description in Q11879590. Will you enter some? And then we just have to accept this as the given variant? Or have we to enter more? That's the question (one of the questions)... Gestumblindi (talk) 23:44, 10 April 2016 (UTC)[reply]
Gestumblindi: Do you really think that discussions are a problem? I've added now a Alemannic description in Q11879590.
The funny thing about this question is thar if you ask Swiss people how to write something in Swiss German they will always say "one can't write Swiss German", "Swiss German does not exist" or something like that. But nearly every German-speaking Swiss does write Swiss German in informal writings nearly every day ... --Holder (talk) 05:24, 11 April 2016 (UTC)[reply]
Holder: Isn't that exactly the problem? "In informal writings", yes, but: Wikidata is formal. The most formal of all Wikimedia projects - structured data that needs to be predictable, I'd say. And no, of course I don't think that "discussions are a problem". What I tried to say was that this specific discussion shows us an example of the problem (there is no defined variant of spelling of wiibliche Vorname or the like, and the variant you entered is just one of lots of possible ones), and this is a problem that will continue with the present state of things. Gestumblindi (talk) 11:10, 11 April 2016 (UTC)[reply]
Gestumblindi: You're confusing 'formal language = sociolinguistic register' and 'w:en:Formal language. If you think that only languages with a well defined standard should be used on Wikidata you exclude about 95 % of all languages in the world. Why shouldn't we try it also with Non-standard languages? What's the problem? In Wikipedia we discuss conflicting opinions and try to find a solution. Why shouldn't that work on Wikidata?
Perhaps the real problem is that Wikidata tries to match natural language with formal language. But natural languages don't work that way. Even well defined standard languages are not fully "predictable". This applies only to constructed languages. --Holder (talk) 16:26, 11 April 2016 (UTC)[reply]
Holder: Well, let's return to simple practicalities: Maybe Wikidata is indeed too inflexible by assuming that it's possible to use one well-defined variant for labels and descriptions in each language. But how to solve the problem? To repeat some questions, I would be interested in your answers: You have added the label "wyblige Vorname" and the description "e Vorname, wu Fraue gee wird" to Q11879590. Is your approach for future additions of gsw labels and descriptions "first come, first serve": The first variant entered stays, be it e.g. Walliserdütsch, Züridütsch, Badisch, or Alsatian? Or would you suggest some other approach? And if we keep gsw, should it continue to be called "Swiss German" here in Wikidata, or should it be changed to "Alemannic"? Gestumblindi (talk) 21:56, 11 April 2016 (UTC)[reply]
Gestumblindi: "First com, first serve" is indeed the approach I would prefer. And of course, 'gsw' should be renamed to "Alemannic". Thanks and best regards. --Holder (talk) 03:47, 12 April 2016 (UTC)[reply]
As I said above, it is technically possible to create a code for each dialect and use them all in one wiki together with the main "de" labels and descriptions. They can all be used in the infoboxes if you like. -- Innocent bystander (talk) 06:42, 12 April 2016 (UTC)[reply]
Holder, Innocent bystander: Well, to have some first productive outcome of this discussion, let's change Swiss German to Alemannic, I'd say. Where is this information stored? I notice that already, when I visit e.g. Q11879590 with my language set to Alemannic, gsw is displayed as Alemannisch. When I set my language to English, it's displayed as Swiss German. And then, of course Innocent bystander's approach would be interesting. Are there any (semi-)standardized codes that could be used for e.g. Baseldytsch, Züridütsch etc.? Gestumblindi (talk) 21:12, 12 April 2016 (UTC)[reply]
@Innocent bystander:: Sorry for pinging you again, but before this gets archived.... I think at least the participants of this discussion can agree upon displaying gsw as "Alemannic" (which includes Swiss German and other Alemannic dialects) instead of Swiss German. I think you are the Wikidata expert in this discussion... so... can you help us with that? What has to be changed where? Gestumblindi (talk) 22:36, 17 April 2016 (UTC)[reply]
@Gestumblindi: From what I know, gsw is a ISO 639-2-code. See en:List of ISO 639-2 codes. And I do not think that it is a good idea to change those definitions. And if our software isn't consistent, we probably have to report it to our developers. We have at least one other project that has a similar problem. The language of nowiki is Bokmål, but the ISO-code of Bokmål is nb. To make it even worse, the nowikisource-project is not in Bokmål, it is in Norwegian which has the code no.
I do not know if there are any standardized codes for Baseldytsch, Züridütsch etc. I do not even know if there are any standardized codes for Sweden-Swedish either, but standardized software uses sv-se for that and sv-fi for Finland-Swedish. To take that further, I could probably propose sv-ee and sv-ua without to many objections for Estonia- and Ukraine-Swedish. Such codes are not within our software yet, you have to propose them to our developers. @Adrian Heine (WMDE):. -- Innocent bystander (talk) 07:11, 18 April 2016 (UTC)[reply]
@Innocent bystander: Well, "Alemannic" is, apparently, one of the official (alternate) names for the ISO 639-2 code gsw, see this entry at SIL and this one at Ethnologue. As Holder pointed out, it's a systematically rather murky situation (gsw originally being a code only for "Swiss German" and then officially expanded to nearly all, but not quite all of Alemannic dialects, still including Swiss German). Anyway, at least we need some consistency here: Currently, if the Wikidata interface is set to English, gsw is displayed as Swiss German, but when set to German, it's displayed as "Alemannisch". So, either (which I would prefer) change the English name to "Alemannic", too - or change the German name from "Alemannisch" to "Schweizerdeutsch". Gestumblindi (talk) 10:39, 18 April 2016 (UTC)[reply]

┌────────────────────────────────────────────────────────────────────────────────────────────────────┘ I was expecting that the translations of language names are coming from mw:Extension:CLDR which means from http://cldr.unicode.org/. However, on CLDR "Swiss German" gets correctly translated to "Schweizerdeutsch". Maybe Lydia Pintscher knows better where to change translation mistakes? --Pasleim (talk) 11:58, 18 April 2016 (UTC)[reply]

I lost overview in this discussion, sorry. Can one of you summarize what is wrong? Then I can go talk to Adrian to figure out what needs to change. --Lydia Pintscher (WMDE) (talk) 09:04, 20 April 2016 (UTC)[reply]
On Wikidata the language code gsw is used inconsistently. In English it's written out as "Swiss German" and in German as "Alemannisch". There is no consensus if "Swiss German" or "Alemannic" is the right name for gsw but because Alemannic (Q131339) is not exactly the same as Swiss German (Q387066) a decision should be taken and then used consistently independent of the UI language. --Pasleim (talk) 09:44, 20 April 2016 (UTC)[reply]
Ok thanks. I just talked to Adrian about it. We take what MediaWiki gives us here. The settings are here: https://doc.wikimedia.org/mediawiki-core/master/php/Names_8php_source.html The reason for this seems to be that this is also used to display the language in the language list in the sidebar on Wikipedia and there people wanted to have Allemanisch. --Lydia Pintscher (WMDE) (talk) 14:50, 20 April 2016 (UTC)[reply]
Then it should be Alemannic in English as well. Gestumblindi (talk) 19:40, 20 April 2016 (UTC)[reply]

"Official" vs. "national" languages of Switzerland

As I'm talking about Switzerland, I remember another longstanding issue... the "official" and "national" languages. Officially, Switzerland has three official languages (German, French, Italian) and four national languages (German, French, Italian, Romansh). The difference being that Romansh (a small minority language), though officially designated a national language of Switzerland (and is used on the banknotes, for example), isn't a regular language in official publications and for correspondence with federal agencies, except for native Romansh speakers of the canton of Graubünden. Well, at Q39, there has been something like a very slow edit war over the years, and Romansh was added and removed as an "official language" (Property:P37) several times. Particularly Ludo29 was adamant in removing Romansh as an official language, and the topic has come up several times on the discussion page of Q39. I understand the reasoning of not listing Romansh as an "official language". However, it is a (so to speak: officially designated) national language, and Q39 contains also the name of the country in Romansh. I think that in some way, a relation between Switzerland and Q13199 (Romansh) should be maintained. But in what way, if not as an "official language"? Gestumblindi (talk) 22:09, 8 April 2016 (UTC)[reply]

The Philippines also makes the same distinction between official and national languages. The official languages are English and Filipino, while Filipino is the sole national language. Although we don't have the edit war that CH's Wikidata item is having, I'm still interested in this discussion. If a different property is too much, maybe a qualifier would be better instead? —seav (talk) 02:30, 9 April 2016 (UTC)[reply]
When Wikidata was young I added a number of languages to Q34#P37. The use of P31 as qualifier is probably not right, but it can give you an idea of how it might work. I think Swedish sign language also have some kind of official status, but I never added that. -- Innocent bystander (talk) 06:14, 9 April 2016 (UTC)[reply]
I can see two approaches to this dilemma: Either introduce a new property and tighten the description of official language (P37), or use official language (P37) with P794 (P794) as qualifier. Personally, I always prefer separate properties for separate concepts, but the latter solution could be used until such a property exists. --Srittau (talk) 10:28, 9 April 2016 (UTC)[reply]
« I always prefer separate properties for separate concepts » I'm agree with that. If the country said « Ours official languages are : DE, IT, FR » it's not the work of Wikidata to say différent.
Romansh has a statute, it's not an official language. Creating a specific property ? Probably the best solution Ludo29 (talk) 17:32, 9 April 2016 (UTC)[reply]
A problem may be the definition of Property:P37. It's English description is "language designated as official by this item", but by "official", various things may be meant. The German label says "Amtssprache", which more literally than as "official language" could be translated as "language of the office" - an "Amt" being a (government) office, agency, or bureau. Romansh is not an official language in that sense (except for the native Romansh speakers), as e.g. a person from German-speaking Switzerland can't insist on having an official correspondence in Romansh. But it is a national language, that means: officially recognized as a national language of Switzerland, together with the other three. That is why it also appears on banknotes and there is a Romansh version of the Swiss Government's website. Now, I also think there are two possible approaches, both involving a clearer definition of Property:P37. Either say: P37 is strictly for "Amtssprache", that is, languages that are approved for official correspondence, translations of law etc. Create a new property "national language". Or say: P37 is actually broader and applies to any kind of officially recognized language - then use it for Romansh, after all. Gestumblindi (talk) 18:17, 9 April 2016 (UTC)[reply]
I do not think it works to add a new property for every system of "official language". We would then end up with 190 properties for national/official language, one for each country.
In Sweden we have "official minority-languages". Some municipalities have to support Finnish, some have to support Meänkieli and some have to support Sami. No municipality have to support Yiddish or Romani, but they are still official minority-languages.
In Norway they have different official written languages. -- Innocent bystander (talk) 20:02, 9 April 2016 (UTC)[reply]
So, If we choose the second proposal of Gestumblindi, we have to choose a new name for P37. It can't stay official. Ludo29 (talk) 08:52, 10 April 2016 (UTC)[reply]
Could we call it "officially recognized language", which would encompass "official" and "national" languages? Gestumblindi (talk) 23:28, 10 April 2016 (UTC)[reply]
Imho, official has very strong meaning.
We build wikidata not just for us. We build it also for external reuses. I think that if soemone see official for a propretry of a State, he'll think ok, it's a offcial language..
So, if we have the wish to list languages - and not only official languages - of State, we have to choose an other word that official.
So, not "officially recognized language", but "recognized language". Ludo29 (talk) 08:07, 11 April 2016 (UTC)[reply]
Well, but recognized by whom? After all, Romansh is recognized by the Swiss constitution, it doesn't get much more official - but it happens to be not an "official language" in the sense of an Amtssprache; it seems that we're a bit stuck in that dilemma. For you, every wording containing "official" sounds too much like "language of the (federal) offices", but it seems to me that is not really the only meaning of official. Another idea if we stick with the notion of a new property: "Language officially recognized as a national language"? Gestumblindi (talk) 18:19, 13 April 2016 (UTC)[reply]
by whom ?
Romansh is recognized by Swiss constitution as a national language. Romansh is not recognized by Swiss constitution as an official language. So, we can't add a qualificater official about Romansh in the context of Swiss constitution. Ludo29 (talk) 10:41, 16 April 2016 (UTC)[reply]
Well, as said before: Only with a narrow definition that equals "official language" for Wikidata purposes with what the Swiss constitution means by an official language, that is, an Amtssprache. But, maybe, as suggested by Innocent bystander ("I do not think it works to add a new property for every system of "official language". We would then end up with 190 properties for national/official language, one for each country"), the meaning of "official" in Property:P37 should be seen in a broader international context, including any kind of "officially" recognized language, including the national languages of Switzerland, and maybe, you could accept that too, if we clarify this with an appropriate description? Gestumblindi (talk) 22:32, 17 April 2016 (UTC)[reply]
As I said before, Wikidata have external re-use, including Wikipedia. Official have a very strong meaning. We can't use official in Wikidata if that is to said an other thing. Ludo29 (talk) 09:37, 18 April 2016 (UTC)[reply]
@Ludo29: In any case I think we can agree that it is an unacceptable situation that there currently is no connection between the items for Switzerland and for Romansh, a national language of Switzerland recognized by the Swiss constitution. A connection needs to be created - using a broadly defined Property:P37 or a new property. As you're so strictly opposed to using P37 resp. to any property containing the wording "official", we could create a property called "national language", but somehow I foresee confusion in an international context. Or we end up with a property that is only used for "national language" according to the definition of the Swiss constitution, not usable for any other country, a Switzerland-only property - also not quite an appealing prospect, wouldn't you say? Gestumblindi (talk) 22:18, 19 April 2016 (UTC)[reply]
I think that the current situation is less bad that the other when Wikidata has presented Romansh with the same statut than German, French or italian.
You said A connection needs to be created . Probably. But some others Wikidata contributors don't seem able to create a new property. Ludo29 (talk) 08:11, 20 April 2016 (UTC)[reply]

Anthem

anthem (P85) has similar problems. Sweden (Q34) has no anthem (or national hymn as the label tells in most languages). There is one song that is de facto used as anthem, but it has no official recognition in any law. In contrast EU has an anthem, even if EU isn't a nation. -- Innocent bystander (talk) 09:17, 11 April 2016 (UTC)[reply]

wiki whatsapp group

I stumble on a Wikipedia project that facilitate an interactions on whatsapp group Thats serves as search engine, it gives you response as you typed in your questions with wiki keyword But to my surprise is like the server for that facility is down now what happened  – The preceding unsigned comment was added by 197.211.53.12 (talk • contribs) at 17:38, 10 April 2016‎ (UTC).[reply]

One page per property proposal?

At the moment we have several pages that contain property proposals. When we archive proposals, the whole discussion gets copy&pasted over to the archive page, which is a bit cumbersome, error-prone, and loses the history. I would suggest that we move to a system, similar to what e.g. Commons uses for deletion requests: Each proposal (which can contain multiple related properties) is on its own sub-page of Wikidata:Property proposal. These proposals then get transcluded on the proposal category pages.

Advantages:

  • It is possible to selectively add proposals to the watchlist and ignore proposals you are not interested in.
  • That also makes it easier to notice when a proposal that you are interested in is (not) done, even if you are not pinged.
  • The history of a proposal is much easier to read, without looking at the history of several unrelated proposals.
  • The history stays intact when a proposal gets archived. This is especially important for changes to the {{Property proposal}} template.
  • Archiving is easier. Instead of moving a block of text (and hopefully not cutting too much or not enough), you just need to move a single line.
  • Archiving can be done immediately when a property was created or the status was set to "not done", since watchlist and ping notifications still work. This reduces bloat on the proposal category pages.
  • No need to change the "proposed by" field when archiving a proposal (often forgotten). (added later --Srittau (talk) 19:36, 16 April 2016 (UTC))[reply]
  • A proposal can be added to multiple categories, e.g. "Persons" and "Authority control".

Disadvantages: To be honest, I can't see any.

Any opinions? --Srittau (talk) 14:07, 16 April 2016 (UTC)[reply]

In principle I am in favour. - Brya (talk) 14:34, 16 April 2016 (UTC)[reply]
  • The main disadvantage is that one would need to bookmark every proposal to get an overview. Subpages lead to lost pages none is aware of and need to be maintained. It might be easier if the process for identifier is simplified and limited to one page. They seem to make up the bulk of the proposal and could easily done more quickly.
    --- Jura 14:42, 16 April 2016 (UTC)[reply]
    • I see disadvantage of needing to bookmark every proposal, although this only affects a few "power users", in my opinion. I think the majority of users (myself included) is not interested in changes to every proposal. I doubt that subpages will lead to lost pages and a maintenance problem. This hasn't been a problem on other projects. --Srittau (talk) 15:16, 16 April 2016 (UTC)[reply]

┌────────────────────────────────────────────────────────────────────────────────────────────────────┘ Actually there are two problems:

  • lost subpages (and subpages we don't know the status of)
    It's easy not to lost subpage by using a template for page creation which automatically add the relevant cat like "opened proposal" to new subpage. Example of such template is used by {{Participants}}. author  TomT0m / talk page 17:20, 17 April 2016 (UTC)[reply]
  • and comments on property proposal ..

currently both are easy to monitor.
--- Jura 23:05, 16 April 2016 (UTC)[reply]

How would the naming system for the subpages look like? Matěj Suchánek (talk) 15:00, 16 April 2016 (UTC)[reply]
I think something like Wikidata:Property proposal/2016/04/Great new property would work best. Maybe Wikidata:Property proposal/Great new property would suffice. This is what the German village pump uses. Great new property can be in any language, of course. In the end, the exact naming scheme is not super important, in my opinion. --Srittau (talk) 15:16, 16 April 2016 (UTC)[reply]
 Support Good idea, Srittau. Lymantria (talk) 17:08, 16 April 2016 (UTC)[reply]
 Support – T.seppelt (talk) 20:02, 16 April 2016 (UTC)[reply]
 Support --Srittau I agree completely this would make for a much better process. However this shouldn't only be presented on English project chat as some people will not see it and it may be lost from view too quickly. I recommend you formulate this with detailed proposals to be implemented as a Request for Comment in WD:RFC. ArthurPSmith (talk) 00:53, 17 April 2016 (UTC)[reply]
@ArthurPSmith: That is a valid concern, but I had a look at a few recent RFCs. Of those only one was translated. Seeing as there is currently lots of support and little opposition to this proposal, do you think it would be enough if we would point people here from the most active village pumps, with a short translated version of the proposal? And if it turns out that opposition is higher than it is at the moment, start the RFC process? --Srittau (talk) 14:45, 17 April 2016 (UTC)[reply]
@Srittau: whether or not an RFC is translated, it appears for users of every language who may visit the RFC page. But users with other default languages will not see the English Project chat page unless they specifically follow the link to it. We do get an awful lot of discussion on here compared to other languages so maybe it's sufficient, but I think an RfC would be a better way to handle a change like this. Note that WD:RFC also uses this process of creating a separate page for each proposed RfC, which is then linked from the table on that page. ArthurPSmith (talk) 13:50, 18 April 2016 (UTC)[reply]
Just to be a little clearer also on details I think are still missing from what you've proposed:
  • Do we keep the current list of (16) property proposal categories (eg. People, Authority Control, Natural Science, etc), or change that also?
  • How would specific proposals be linked to these categories? You mention transclusion, but how does a category know a proposal belongs there?
  • For done or not-done proposals could we use an monthly archive page similar to Wikidata:Requests_for_permissions/RfBot/February_2016?
  • are some new templates needed for the overall proposal (and perhaps to indicate discussion has concluded?) as it may include multiple individual properties?
ArthurPSmith (talk) 14:03, 18 April 2016 (UTC)[reply]
 Support don't think a RfC is needed for this change. --Pasleim (talk) 13:22, 17 April 2016 (UTC)[reply]
 Support Good idea. Overload of proposal site with closed proposals (probably caused by uneasy archiving) is real problem. Also ability to add single proposal to watchlist is real advantage. --Jklamo (talk) 13:50, 17 April 2016 (UTC)[reply]

Jura1 replied to some of the points above inline. Since this makes the proposal much harder to read, I have extracted that part below and restored the original proposal above. --Srittau (talk) 14:31, 17 April 2016 (UTC)[reply]

Please review item about Hungarian short film

Can someone who speaks Hungarian please review Blood and High Heels (Q19766009)? I’m fairly certain the inscription (P1684) qualifier on Blood and High Heels (Q19766009)original language of film or TV show (P364)English (Q1860) is incorrect, and the original language of film or TV show (P364) and title (P1476) statements seem suspicious as well. —Galaktos (talk) 12:51, 17 April 2016 (UTC)[reply]

The huwiki article says it's English-speaking with Hungarian subtitles. – Máté (talk) 13:10, 17 April 2016 (UTC)[reply]
The value given for inscription (P1684), 'magyar' is Hungarian for 'Hungarian'. Inscription and subtitle (on a film) are both 'felirat' in Hungarian. That must have caused the confusion. – Máté (talk) 13:14, 17 April 2016 (UTC)[reply]
Ah, that explains it. Thanks a lot! —Galaktos (talk) 13:38, 17 April 2016 (UTC)[reply]

Server switch 2016

The Wikimedia Foundation will be testing its newest data center in Dallas. This will make sure Wikipedia and the other Wikimedia wikis can stay online even after a disaster. To make sure everything is working, the Wikimedia Technology department needs to conduct a planned test. This test will show whether they can reliably switch from one data center to the other. It requires many teams to prepare for the test and to be available to fix any unexpected problems.

They will switch all traffic to the new data center on Tuesday, 19 April.
On Thursday, 21 April, they will switch back to the primary data center.

Unfortunately, because of some limitations in MediaWiki, all editing must stop during those two switches. We apologize for this disruption, and we are working to minimize it in the future.

You will be able to read, but not edit, all wikis for a short period of time.

  • You will not be able to edit for approximately 15 to 30 minutes on Tuesday, 19 April and Thursday, 21 April, starting at 14:00 UTC (15:00 BST, 16:00 CEST, 10:00 EDT, 07:00 PDT).

If you try to edit or save during these times, you will see an error message. We hope that no edits will be lost during these minutes, but we can't guarantee it. If you see the error message, then please wait until everything is back to normal. Then you should be able to save your edit. But, we recommend that you make a copy of your changes first, just in case.

Other effects:

  • Background jobs will be slower and some may be dropped.

Red links might not be updated as quickly as normal. If you create an article that is already linked somewhere else, the link will stay red longer than usual. Some long-running scripts will have to be stopped.

  • There will be a code freeze for the week of 18 April.

No non-essential code deployments will take place.

This test was originally planned to take place on March 22. April 19th and 21st are the new dates. You can read the schedule at wikitech.wikimedia.org. They will post any changes on that schedule. There will be more notifications about this. Please share this information with your community. /User:Whatamidoing (WMF) (talk) 21:07, 17 April 2016 (UTC)[reply]

Again: Qualifier to determine "last update"

I'm referring to this discussion I brought up in March: Qualifier for "last update".

In a nutshell, I want to use a qualifier to express when a statement was true and was checked last time. More concretely, I'm talking about the number of games and goals a soccer player has made/scored for a certain team; see Q6451050#P54 where point in time (P585) is used for that. In the linked discussion, it seemed to me that this usage of point in time (P585) is considered appropriate.

However, now I'm deliberating whether retrieved (P813) would be the better property to use for this purpose? Or is retrieved (P813) for sources only? Yellowcard (talk) 09:29, 18 April 2016 (UTC)[reply]

You may access data at a time (P813) when it is no longer true, however, it was at another (P585) (and is still worth keeping). (And its constraints do indeed indicate that P813 is a source-only property.) – Máté (talk) 10:12, 18 April 2016 (UTC)[reply]
@Máté: Did you have a look at Q6451050#P54 (member of sports team (P54) → CF Montréal (Q167615))? I'm talking about data of a player with respect to a team where he still plays for. The number of games and goals increases week by week and the old number is for sure not worth keeping :) Having a look at the constraints of the property is a good idea. Yellowcard (talk) 10:22, 18 April 2016 (UTC)[reply]
@Yellowcard: No, not in this case, and not in many others, but e.g. for population and many others it is. And I think it's better to use the same qualifier in both instances. – Máté (talk) 10:33, 18 April 2016 (UTC)[reply]
Regarding population I totally agree with you, data like that must not be deleted. So you support using point in time (P585) for the soccer data case as well? Yellowcard (talk) 12:40, 18 April 2016 (UTC)[reply]
Yes, I'd support that for football too. – Máté (talk) 13:12, 18 April 2016 (UTC)[reply]
This use is perfectly fine. point in time (P585) hasn't been added to the list of the accepted qualifiers for member of sports team (P54) mainly because some users keep mistaking it for start time (P580) or end time (P582).--Casper Tinan (talk) 14:03, 18 April 2016 (UTC)[reply]
Mmmm that's an awful constraint. This would contradict general wikidata rules and a local project should not be able to contradict the semantics of a qualifier that is available in any case. Like Denny said, the constraint system should not be an occasion to mimic very strong restrictions on what we can do. author  TomT0m / talk page 16:34, 18 April 2016 (UTC)[reply]

Wikidata weekly summary #205

Here's your quick overview of what has been happening around Wikidata over the last week.

Wikispecies relation between human and category for proposed taxa

Hello everyone,

do we have a property/system for linking Charles Darwin (Q1035) (species:Charles Robert Darwin) and species:Category:Charles Darwin taxa? Something similar to category for people born here (P1464) or category for recipients of this award (P2517). And we would also need something to link the category item to the human. -- T.seppelt (talk) 04:55, 19 April 2016 (UTC)[reply]

No. It should be possible to put in a query for "taxon author = Charles Darwin" and generate a list. - Brya (talk) 06:00, 19 April 2016 (UTC)[reply]
For linking categories back to normal items, we have category combines topics (P971). Looking at the examples there, I'd expect something like category combines topics (P971): taxon author, Charles Darwin (Q1035). Not sure if there's an item for taxon author yet, I can't find one. On a related note, should Category:Taxa by author (Q4155659) and Category:Taxa by author (Q9295491) be merged or are they not quite the same? - Nikki (talk) 06:41, 19 April 2016 (UTC)[reply]
Yes. merged. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 10:48, 19 April 2016 (UTC)[reply]
We have Commons category (P373); we should have an equivalent "Wikispecies category" property. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 10:48, 19 April 2016 (UTC)[reply]
We should very strongly resist any further categorizing or strong linking of categories. --Izno (talk) 11:31, 19 April 2016 (UTC)[reply]

I mistakenly added properties to "Identifiers" instead of "Statements"

I have added "image" properties to a hundred items and now I realize that I have put them in the wrong section: I guess "image" properties belong to "Statements" but I just added them at the bottom of the list, which often belongs to the "Identifiers" section instead. I guess many other contributors have made this kind of mistake. Is there a bot in charge of fixing this kind of mistakes? Or should I go fix them manually? Thanks! Syced (talk) 08:42, 19 April 2016 (UTC)[reply]

Just reload one of the pages and you will notice that it appears in the correct part. It doesn't matter which link you use.
BTW WikiData Free Image Search Tool (Q21283216) is a convenient tool to find images and add them to Wikidata. (sample link: Try it!
--- Jura 08:46, 19 April 2016 (UTC)[reply]
However, this i a regression in the user interface. I as a user now have to decide which link I have to use, not knowing that it actually doesn't matter. And if the statement then ends up to be shown in the wrong section after adding it, I have to think about what I have done wrong and how to correct it, like Syced just did. There should be no unnecessary "Uh, I don't know where to click, maybe I better keep my hands off this" or "Oh my god, what did I break now?" moments when editing Wikidata. --YMS (talk) 08:52, 19 April 2016 (UTC)[reply]
True, but I'm not quite sure what could be done to change that. Re-ordering the page after every addition would be highly annoying. As most of the time one just needs a link, there is a suggestion to place an additional link at the top of the page as well.
--- Jura 09:03, 19 April 2016 (UTC)[reply]
Jura: Wonderful tool! Would you happen to know if I can limit it to item whose latitude/longitude are in a particular area? Without using the "location" property which is missing from many items. The "Discuss" link there is broken. Thanks a lot! Syced (talk) 09:49, 19 April 2016 (UTC)[reply]
The "Wikidata query" "create a query" link has a sample for items 15km around Cambridge: AROUND[625,52.205,0.119,15] . Discussion is mostly done on User talk:Magnus Manske.
--- Jura 10:12, 19 April 2016 (UTC)[reply]

What property to use for external databases?

When we want a link to external databases we usually create a new property. But sometimes it seems not worth it. For instance,

  1. Neurosynth database http://neurosynth.org uses PubMed publication ID (P698) as an identifier, see, e.g., http://neurosynth.org/studies/16516496/ To link to the Neurosynth entry I have used external data available at URL (P1325) with the URL. Would there be other more appropriate ways to make a connection to Neurosynth?
  2. My article Mining the posterior cingulate: Segregation between memory and pain components (Q21012713) is also available in the university database [1], apparently with the identifier c5052ad6-7618-48b6-9132-7b2704a7b0b7. Is seems a bit overkill to have a property for each university repository.

— Finn Årup Nielsen (fnielsen) (talk) 13:53, 19 April 2016 (UTC)[reply]

For #2 you can use full work available at URL (P953). --Succu (talk) 18:04, 19 April 2016 (UTC)[reply]

Mass imports of data

Is there a way that sets of property values can be set for many articles at once (after applying for approval, of course, and with pre-vetting by the community), perhaps by uploading a file containing those values in some format like CSV or JSONL, instead of poking them into the database one at a time with a bot? The sort of volume I'm thinking of is tens of thousands to hundreds of thousands of articles. -- The Anome (talk) 14:48, 19 April 2016 (UTC)[reply]

I used QuickStatements https://tools.wmflabs.org/wikidata-todo/quick_statements.php to load up some hundreds of pages (Danish libraries). — Finn Årup Nielsen (fnielsen) (talk) 16:15, 19 April 2016 (UTC)[reply]
I don't think is possible, all the tools and API can edit only one item at time, but if the data are very interesting and useful maybe developers (@Lydia Pintscher (WMDE):) can invent something. --ValterVB (talk) 16:37, 19 April 2016 (UTC)[reply]
@The Anome: I second the suggestion to use QuickStatements - and with a bot flag, which you should have no trouble obtaining, it works more quickly. If it's good enough for Magnus... Shout if you need help. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 16:39, 19 April 2016 (UTC)[reply]
Thanks! Yes, QuickStatements + bot automation sounds like the way to go. -- The Anome (talk) 07:56, 20 April 2016 (UTC)[reply]
Wikidata:Data donation has links and all for this. --Lydia Pintscher (WMDE) (talk) 09:03, 20 April 2016 (UTC)[reply]

About using P1435

I need a help with filling heritage designation (P1435) for Latvian monuments.

We have two characteristics:

  • monument value - national monument and local monument
  • monument type - archeology, architecture, history, industrial, art, urban, event

How should we fill heritage designation (P1435), which approach is better:

  • create a tree of classes with leaves national/archeology, local/archeology, national/architecture etc. - 14 new items for classes and 9 new items for upper classes
  • or create 2 items for values and 7 items for types and use heritage designation (P1435) twice in the monument item

What do you think? --Voll (talk) 17:55, 19 April 2016 (UTC)[reply]

If there some monuments listed in more than one type category, the second approach would be hard to understand. -- Gymel (talk) 18:18, 19 April 2016 (UTC)[reply]
I would use 'monument value' (national monument / local monument) to fill P1435. Probably the monument type (archeology, architecture, history, industrial, art, urban, event) can be derived from P31. Michiel1972 (talk) 18:29, 23 April 2016 (UTC)[reply]

In the last day or so (?) the navigation menu on the left hand side of every wikidata page seems to have broken - the "Main page" link goes to Main_Page instead of WIkidata:Main_Page, the query service link seems to have vanished, and I'm sure there was a link to Project Chat also. What happened? ArthurPSmith (talk) 18:26, 19 April 2016 (UTC)[reply]

Ha - and right after I posted this comment it seems to have fixed itself ??? ArthurPSmith (talk) 18:28, 19 April 2016 (UTC)[reply]
Reported at WD:DEV#Sidebar as well but I haven't seen any problems. Matěj Suchánek (talk) 19:01, 19 April 2016 (UTC)[reply]

The formatter URLs on IMDb ID (P345) don't work, and the links they generate give 404 errors. How should this be resolved? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 14:28, 20 April 2016 (UTC)[reply]

Changed the default URL formatter to use the IMDB search feature. Works for most identifiers, except for events that use a year suffix (e.g. http://www.imdb.com/find?s=all&q=ev0000003/2015 fails, while the more specific http://www.imdb.com/event/ev0000003/2015 works). -- LaddΩ chat ;) 22:37, 20 April 2016 (UTC)[reply]
Thank you. That's a clever work-around, but I wonder if there's a better solution. Maybe splitting the property? Better, complex, rules for FURLS? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 16:42, 22 April 2016 (UTC)[reply]

SQID as a tool for editors

A main goal of the new SQID Wikidata Browser was to help editors to find out about current property and class item usage, so I would like to announce it here as well. Besides satisfying your curiosity (e.g., to see which type string properties are most common in qualifiers), you can use it to scan for errors or misunderstandings. Here are some examples:

I am sure there are many other applications. Another helpful use are the property pages, which show the qualifiers used for a property and several other statistics. For example, here is the property page for P969 (located at street address).

Property usage numbers and class instance counts are updated once per hour (you may need to clear your browser cache sometimes). Individual entity pages show live data. First opening a page takes a few seconds to download the data, but browsing and filtering will be quite fast after that.

--Markus Krötzsch (talk) 15:56, 20 April 2016 (UTC)[reply]

Very nice, thanks! ArthurPSmith (talk) 20:09, 20 April 2016 (UTC)[reply]
FYI, this tool makes connections to Google and JQuery. Dispenser (talk) 14:49, 21 April 2016 (UTC)[reply]

Several updates and requests

Hey all,

  1. With this commit in Kian repo, We can run Kian models on new items and I run it weekly on adding P31:Q5 for English, German, Dutch, French Wikipedia. I will add it for more Wikis/statements later. Suggest if you want kian running on a particular wiki/statement.
  2. I have been working on wikilabels. It's the component that powers Wikidata:Edit labels. First, I solved some underlying performance issues. And now, I added option of abandoning tasks from your workset, it needs some polishing but it'll be there soon. I have two requests: 1- What do you want from Wikilabels? what is the most annoying bug or missing feature? 2- Right now, ORES model for Wikidata is not the best. We need some human-based data and we are pretty close to reaching it (stats show 3483 out of 4283 edits have been labeled). Please check out Wikidata:Edit labels and label some edits.
  3. ORES is moving to the production cluster. Which means it'll be more stable, and also better performance, etc. but the most importantly, It will allow us to enable ORES extension in Wikis (including here). If you want to test the extension. Go to beta cluster, make an account (or login), enable it in beta features. Then you can check out recent changes, and your watchlist. You can change ORES sensitivity as well in your preferences. We are still working on moving to prod but the datacenter switchover disrupted our work a little bit. Also I would be more than happy to hear your comments, bug reports, feature requests.

Best Amir (talk) 00:22, 21 April 2016 (UTC)[reply]

Historical place names

Welcome to participate in WikiProject Historical Place! The project will deal with using Wikidata as a historical gazetteer, describing places and place names over time.

The first task in to find out current practices. My very first question is: What properties are currently used to define historical place names, and which qualifiers? name in native language (P1559) is used only for people? --Susannaanas (talk) 13:39, 21 April 2016 (UTC)[reply]

@Susannaanas: Use official name (P1448). Snipre (talk) 18:14, 21 April 2016 (UTC)[reply]
@Snipre:Thank you for the recommendation! It helps half-way, but declaring unofficial names would also be needed. There is taxon common name (P1843) but that is limited to taxons. --Susannaanas (talk) 13:20, 22 April 2016 (UTC)[reply]
official name (P1448) describes the official name in any language, and can be constrained by start time (P580) and end time (P582). native label (P1705) is used to describe the local name. This could be used to display the variety of naming conventions, but the purpose of the property does seem limited to one original local form. See the discussion about the property. If native label (P1705) cannot be used for different purposes, there is still a property missing. Susannaanas (talk) 08:21, 23 April 2016 (UTC)[reply]

Cities on the move?

Found this diff, but I'm not sure if this is the right way to do this. I believe the correct way to do this is to relate to the containing country, and then set up statements for that. It is the country that has been part of an union at state-level, not the city (or county). It is also a question on the users page about this. Jeblad (talk) 16:22, 21 April 2016 (UTC)[reply]

I am also curious on the item Christiania (Q21711493), which seems to be the same thing but with another name. Actually, Oslo (Q585) has changed name several times. Viken, Áslo, Oslo, Christiania, Kristiania, and then Oslo again. I think all of this is a single ting with a long continuation, but with several names. I think that the item Christiania (Q21711493) should be deleted and the alternate names added to Oslo (Q585) with start time (P580) and end time (P582). Jeblad (talk) 16:52, 21 April 2016 (UTC)[reply]

I have some doubts about using items like Union between Sweden and Norway (Q62589) for P17 at all. It should maybe rather be treated as a history of topic (P2184):from 1814-1905 in the item about Norway. This item is maybe not as obvious as Swedish Empire (Q215443) who in English is labelled as "Swedish empire" in English but as "The great power era" in Swedish. (Should that item therefor be split?) Using Sweden-Finland (Q3279296) for P17 would be even worse, since such a nation never has existed. It is a term used now for an era when the mid point of Sweden was located much more to the East than it is today. Finland was not even the name of the eastern part of the nation, it was the name of the area around Turku (Q38511).
I have noticed the (K|Ch)ristiana-item. An interesting note is made in the nowiki-article. The city was on fire in 1624 and was rebuild on another location and then renamed.
In a similar way, Karl Johan city (Q10543698) was founded 1812, but never became inhabited. The city was like Oslo moved and renamed to Haparanda (Q588976). Using two items for the same city can therefor be an alternative.
And Åslo and Oslo maybe should be treated as different ways to spell one name? Many Swedish names were changed in the early 20th and late 19th century, but that was more of a change in the orthography of Swedish than real changes of the names. -- Innocent bystander (talk) 19:21, 21 April 2016 (UTC)[reply]
Note that Medieval town of Oslo (Q11989332) and Old Town (Q4583418) is part of Gamle Oslo (Q1493178) which is part of Oslo (Q585). Jeblad (talk) 19:47, 21 April 2016 (UTC)[reply]
Christiania (Q21711493) and Oslo (Q585) was the example I had in mind as well! I think that merging them into one would be the recommended way, for what I have been able to anticipate the discussion around the topic. I will pick it as an example for the discussion. Cheers, Susannaanas (talk) 14:03, 22 April 2016 (UTC)[reply]

Other sites

How can I add something with the 'Other sites' box? The save button does nothing. Cheers, The Jolly Bard (talk) 20:00, 21 April 2016 (UTC)[reply]

What is the "other sites" box? Where is it? --Stryn (talk) 20:21, 21 April 2016 (UTC)[reply]
At the bottom, under the Wikipedia sites. The Jolly Bard (talk) 20:56, 21 April 2016 (UTC)[reply]
What are you trying to add there? - Nikki (talk) 06:53, 22 April 2016 (UTC)[reply]
Non-Wikimedia sites. When I enter a link the save button remains greyed out. The Jolly Bard (talk) 12:17, 22 April 2016 (UTC)[reply]
You can't add non-wikimedia sites there. For non-wikimedia sites you need a property and then add it to the statement section. --Pasleim (talk) 13:10, 22 April 2016 (UTC)[reply]
What then is the purpose of this field? How does one get a property for a non-wikimedia site? The Jolly Bard (talk) 13:18, 22 April 2016 (UTC)[reply]
The purpose of the field is to add links to commons, mediawiki, meta wiki, etc. To which site would you like to link? Maybe there exists already a property for it, see list of properties. New properties can be proposed on WD:PP. --Pasleim (talk) 13:30, 22 April 2016 (UTC)[reply]
In this case, Wikisage. The Jolly Bard (talk) 14:16, 22 April 2016 (UTC)[reply]
You might be able to use described at URL (P973). Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 16:36, 22 April 2016 (UTC)[reply]

Perhaps the form label should be changed to, say, "other Wikimedia sites" or "other sister projects"? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 16:34, 22 April 2016 (UTC)[reply]

Citizenship

I'm wondering about the use of citizenship as a data field instead of either nationality or residency, because citizenship works differently in different parts of the world. It may be sufficient to reside in a country legally, while elsewhere there may be more requirements. Cheers, The Jolly Bard (talk) 21:27, 21 April 2016 (UTC)[reply]

@The Jolly Bard: You don't need to understand anything, you just need sources. Snipre (talk) 15:22, 22 April 2016 (UTC)[reply]
Use country of citizenship (P27) for that. Bear in mind that, for example, I am a citizen of the UK, I consider my nationality to be English, and I could reside anywhere, without that changing - so all three values can be different. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 16:39, 22 April 2016 (UTC)[reply]
For residency we have residence (P551). --Pasleim (talk) 08:43, 23 April 2016 (UTC)[reply]

PHP OOP project using wikidata syntax on Wikipédia API

Hello everybody and cheers from France, I am willing to use wikidata on my internet site for personnal interest and I would like to know how I can get something to work. For the moment I can query the API no problem but I don't understand how to use the wikidata syntax in my project, Thanks a lot, djos  – The preceding unsigned comment was added by 128.78.173.38 (talk • contribs) at 23:12, 21 April 2016‎ (UTC).[reply]

Hi djos, the JSON structure we use for our entities is documented at mw:Wikibase/DataModel/JSON. Cheers, Hoo man (talk) 06:27, 22 April 2016 (UTC)[reply]

Error message when merging

When trying to merge Q4315333 into Q7022760, Special:MergeItems generates an error warning: "Failed to merge items, please resolve any conflicts first. Error: Conflicting descriptions for language pl." --46.147.155.38 06:01, 22 April 2016 (UTC)[reply]

You need to remove the Polish description from one of the items, then you can continue with the merge. You can access the Polish description by clicking on "More languages" below the box with the labels, description and aliases. Cheers, Hoo man (talk) 06:28, 22 April 2016 (UTC)[reply]
Thank you, Hoo man --46.147.155.38 06:38, 22 April 2016 (UTC)[reply]

Sheriffs and police chiefs

How do we list the police chiefs of police departments and sheriffs (in American usage) of counties in items? --AmaryllisGardener talk 23:29, 22 April 2016 (UTC)[reply]

Does director / manager (P1037) in Police departments/district-items make sense? I have never seen an item about a Police district, so I would be glad if you could give me a link to one of them. -- Innocent bystander (talk) 18:42, 23 April 2016 (UTC)[reply]
@Innocent bystander: Like Los Angeles Police Department (Q214126), and then director / manager (P1037) = Charlie Beck (Q5084512)? Sounds logical. --AmaryllisGardener talk 18:56, 23 April 2016 (UTC)[reply]

Adding exact integer quantities

Adding some basic properties to Falcon 9 Full Thrust (Q22808999), I wanted to specify the number of engines: 9 Merlin 1D (Q19923939) and 1 Merlin 1D Vacuum (Q18646644), by editing powered by (P516). However when I add the qualifier "quantity" and type the number 9, the system displays "9±1". How can I tell Wikidata that this is an exact value, not a measurement subject to an error margin? Existing items such as Falcon 9 v1.1 (Q15215794) have the exact quantity displayed correctly (although in the less precise property has part(s) (P527), which I would gladly change if I knew how to save exact values). — JFG talk 18:10, 23 April 2016 (UTC)[reply]

Add "9±0" or "9+-0". This is a known problem which is going to be fixed soon. Matěj Suchánek (talk) 18:29, 23 April 2016 (UTC)[reply]

Edit the order of statement

Hi,

I am trying to add population by statements. Is there a way in the Wikidata Edit UI to be able to order the statement? For example Q1490 Tokyo, There was a population set for census of 2005 and 2010 written last 2014, then this feb a bot imported the japan wikipedia daa for Feb 2016. Then right now I added the 2015 census data. The order becomes this way.

1. Feb 2015 ja.wikipedia import 2. Census 2010 3. Census 2005 4. Census 2015

Is there a way to make the order change? logically older below and newer on top.

1. Feb 2015 ja.wikipedia import 2. Census 2015 3. Census 2010 4. Census 2005 5. Older census data. etc --Napoleon.tan (talk) 02:01, 24 April 2016 (UTC)[reply]

The most recent one should get preferred rank. A bot sets this once in a while. Statement ordering has been de-activated. LUA could retrieve statements based on qualifiers.
--- Jura 06:04, 24 April 2016 (UTC)[reply]

Adding Drug-Target Information to Wikidata

Hi,

I work with the Dumontier Lab in the Biomedical Informatics Research Program at Stanford University and we are interested in incorporating drug-target information from DrugBank to Wikidata. Specifically, we would like to add to Andrew Su's work on importing drug/proten data. Also, because DrugBank contains information about drugs and their targets we would be able to add relational data to both items. Best-Oliver

The last of MediaWiki

d:Q23823457 claims to be different from d:Q958245. Because the editor did not let me add a dewiki-page for the former, telling me that it is already used on the latter, I tried to kill it as dupe. That failed, so now I want to nail the "different from", it needs a reference. First step, Fitzwilliam Museum d:Q1421440, claiming to be a commons category. No obvious link to a commons category, ctrl-U viewsource, apparently there is really no link to a commons category. –Be..anyone 💩 12:43, 24 April 2016 (UTC)[reply]

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