[06:23:24] cool, then I can use that too [06:55:52] hi, donnu if this is the right place to ask. Does anybody know if it's possible to use wikidata as wikibase repo (my wiki as wikibase client)? didn't find anything on the web (not here https://www.wikidata.org/wiki/Wikidata:Data_access) and not anywhere else [06:59:41] Nir: not as far as I know – the client currently relies on direct access to the repo’s database [07:26:37] PROBLEM - wikidata.org dispatch lag is higher than 300s on www.wikidata.org is CRITICAL: HTTP CRITICAL: HTTP/1.1 200 OK - pattern not found - 1966 bytes in 0.119 second response time [08:03:26] RECOVERY - wikidata.org dispatch lag is higher than 300s on www.wikidata.org is OK: HTTP OK: HTTP/1.1 200 OK - 1950 bytes in 0.135 second response time [08:32:06] PROBLEM - wikidata.org dispatch lag is higher than 300s on www.wikidata.org is CRITICAL: HTTP CRITICAL: HTTP/1.1 200 OK - pattern not found - 1977 bytes in 0.089 second response time [08:37:17] RECOVERY - wikidata.org dispatch lag is higher than 300s on www.wikidata.org is OK: HTTP OK: HTTP/1.1 200 OK - 1942 bytes in 0.098 second response time [09:00:46] PROBLEM - wikidata.org dispatch lag is higher than 300s on www.wikidata.org is CRITICAL: HTTP CRITICAL: HTTP/1.1 200 OK - pattern not found - 1980 bytes in 0.108 second response time [10:14:16] RECOVERY - wikidata.org dispatch lag is higher than 300s on www.wikidata.org is OK: HTTP OK: HTTP/1.1 200 OK - 1950 bytes in 0.107 second response time [13:27:05] PROBLEM - wikidata.org dispatch lag is higher than 300s on www.wikidata.org is CRITICAL: HTTP CRITICAL: HTTP/1.1 200 OK - pattern not found - 1971 bytes in 0.125 second response time [13:32:05] RECOVERY - wikidata.org dispatch lag is higher than 300s on www.wikidata.org is OK: HTTP OK: HTTP/1.1 200 OK - 1960 bytes in 0.114 second response time [16:18:25] PROBLEM - wikidata.org dispatch lag is higher than 300s on www.wikidata.org is CRITICAL: HTTP CRITICAL: HTTP/1.1 200 OK - pattern not found - 1967 bytes in 0.100 second response time [16:23:45] RECOVERY - wikidata.org dispatch lag is higher than 300s on www.wikidata.org is OK: HTTP OK: HTTP/1.1 200 OK - 1963 bytes in 0.091 second response time [17:42:16] PROBLEM - wikidata.org dispatch lag is higher than 300s on www.wikidata.org is CRITICAL: HTTP CRITICAL: HTTP/1.1 200 OK - pattern not found - 1966 bytes in 0.109 second response time [17:47:35] RECOVERY - wikidata.org dispatch lag is higher than 300s on www.wikidata.org is OK: HTTP OK: HTTP/1.1 200 OK - 1954 bytes in 0.103 second response time [18:16:25] PROBLEM - wikidata.org dispatch lag is higher than 300s on www.wikidata.org is CRITICAL: HTTP CRITICAL: HTTP/1.1 200 OK - pattern not found - 1961 bytes in 0.099 second response time [18:17:12] is there a way to change how numbers are formatted? [18:32:06] RECOVERY - wikidata.org dispatch lag is higher than 300s on www.wikidata.org is OK: HTTP OK: HTTP/1.1 200 OK - 1948 bytes in 0.120 second response time [18:39:55] PROBLEM - wikidata.org dispatch lag is higher than 300s on www.wikidata.org is CRITICAL: HTTP CRITICAL: HTTP/1.1 200 OK - pattern not found - 1968 bytes in 0.108 second response time [18:55:45] RECOVERY - wikidata.org dispatch lag is higher than 300s on www.wikidata.org is OK: HTTP OK: HTTP/1.1 200 OK - 1949 bytes in 0.101 second response time [19:31:39] WikidataFacts: hi! :) [19:31:47] hi :) [19:32:00] WikidataFacts: I cleaned up a thousand names and merged ~0 [19:32:03] 20* [19:32:12] it's working, I'm all happy [19:32:16] very cool! [19:32:36] it has been bothering me for months, I saw no way of clearing up that much data [19:32:58] your script is like an early birthday present ^^ [19:33:16] :D [19:34:23] I think I'll consider all scripts and tools made at the hackathon birthday presents :p [19:34:32] * Harmonia_Amanda greedy [19:35:31] Your birthday, Harmonia_Amanda? [19:35:39] it's tomorrow [19:35:49] just in time for cleaning up the bugs :p [19:36:26] all those fantastic new tools and script are easing my Wikidatian life [19:36:30] so ^^ [19:37:42] :D [19:37:56] What are your favourite pres... new tools? :) [19:38:23] abian: I may be contractually obligated to say "the ones I explicitly asked for" [19:38:39] so WikidataFacts off-browser version of my namescript [19:38:46] which is changing my life [19:38:54] and Tpt[m] Databox [19:39:24] but I need to try the new drag n' drop too! [19:39:48] scripts are hard to find, actually :p [19:40:52] abian: and people translated my namescript in several new languages so more people will (maybe) use it! [19:41:33] what does the script do? [19:41:37] Bravo :) [19:41:46] (other than make you very happy :P) [19:41:52] it completes all labels/descriptions/aliases for names items [19:41:57] Is Spanish translation still missing? [19:41:59] correctly [19:42:10] ah [19:42:12] based on the properties [19:42:38] so people can use the *correct* name item after because the descriptions are explicit [19:43:00] and will (hopefully) stop trying to merge Cyrillic names and latin-script ones [19:43:11] abian: I have a Spanish translation :) [19:44:02] nikki: basically it adds ~40 000 octet to every name item :p [19:44:21] Then I can make a try with Aragonese, Catalan, Galician or French (?) [19:45:03] I'm French [19:45:05] Not so good with them, but perhaps with help... O:) [19:45:05] but sure! [19:45:16] Hahaha, French discarded [19:45:48] abian: https://www.wikidata.org/wiki/User:Harmonia_Amanda/namescript-data.json [19:47:02] title, add-button, no-P1705, no-P282, unknown-P282 and all-set [19:47:47] nikki: it doesn't overwrite, so to clean an item you first need to delete the wrong labels/descriptions [19:48:01] nikki: but after that, it does the job alone [19:48:06] I see [19:48:38] Hmmm... does it something to do with https://github.com/emijrp/wikidata/blob/master/common.descriptions.py and others? [19:49:17] it choses if it's about a family name, a female given name, a male given name, an unisex given name, and then apply the labels/aliases/descriptions based on the writing system [19:49:41] abian: yes and no [19:49:54] abian: that's the "fixed" part of the description [19:50:25] my own script add correctly the "real name" to the fixed part of the description when the name is in another writing system [19:50:46] PROBLEM - wikidata.org dispatch lag is higher than 300s on www.wikidata.org is CRITICAL: HTTP CRITICAL: HTTP/1.1 200 OK - pattern not found - 1966 bytes in 0.085 second response time [19:50:49] abian: look https://www.wikidata.org/wiki/Q3897170 for non-Latin languages [19:51:24] https://www.wikidata.org/wiki/Q17055707 for a Korean name [19:51:27] you see? [19:52:16] Interesting, now I see :) [19:52:20] the label should always be in the language (so no Hangul characters in French label, we will have the transliteration), so the description should clarify what name the item is about [19:52:45] so people searching for "Ivan" would be able to chose between Russian, Ukrainian or Latin-script version [19:53:04] and hopefully add the correct value [19:53:31] Definitely useful, yeah [19:53:45] :) [19:55:10] and that way, it's much easier to create correctly names! [19:55:33] so I can just work on a list of usual given names written in devanagari [19:55:38] and then run namescript [19:55:55] and hop! "new" given names ready to use [19:56:11] we are missing so many names when they are not in Latin-script, it's sad [19:56:49] (in part because the US census is free, so importing all names from USA was easy) [19:57:05] (and it's not as easy to find all names from Russia for example) [19:57:53] (but still, with the population of India, we are so lacking in Indian names, that's a shame) [19:58:08] (I hope we'll be able to be better pretty soon) [19:58:30] Wait... is every single American name there? :O [19:58:49] every single family name from the 2010 American census, yes [19:58:50] (Not only Indian names, but Indian things in general, I fear) :S [19:59:23] so it's a strange situation were we have the latin-script version of "Filipov" for example, but not the Cyrillic one [19:59:38] even if there are way more people with the name in Cyrillic [19:59:58] but we don't have a clean-ready-to-import database for those [20:00:24] for transliterated labels, what happens when names are pronounced differently in different countries (and therefore transliterated differently), but spelt the same? [20:00:38] nikki: aliases [20:00:49] Harmonia_Amanda: reading from files should be supported now :) `git pull`, then `node namescript.js filename` [20:01:00] we decided we don't care, because transliterations are always changing [20:01:20] but how do you decide which language is the right one to use as the main label? [20:01:25] RECOVERY - wikidata.org dispatch lag is higher than 300s on www.wikidata.org is OK: HTTP OK: HTTP/1.1 200 OK - 1959 bytes in 0.109 second response time [20:01:35] like, there were three different way of transliterating Russian-to-French, and that's not even taking into account the pronunciation [20:01:42] nikki: the most frequent [20:02:17] so it will really depend of the item [20:02:48] but pronunciation is a very moving information too [20:03:08] the same given name, in French, is not pronunced the same in the North and in the South [20:03:23] etc. [20:03:43] so yeah, most names should have like, a dozen different transliteration for each language [20:04:03] the only "hard" data is the written version [20:04:29] and when you start working on immigration, it becames even more crazy [20:04:50] because officials are "naturalizing" names basically on a case-to-case basis [20:04:51] I don't mind minor differences, I mean things like the english version of michael versus the german version, which don't even start with the same character in japanese [20:05:44] nikki: the Japanese label would probably be the English transliteration (more English-speaking people with that name) with the German one as alias [20:06:20] because if a Japanese person read a book about a "Michael" without any context, what transliteration would they use? [20:06:50] I imagine it would be transliterated based on the original language of the book [20:07:06] and usual transliteration not even starting with the same letter are like, the norm, when you are speaking about Cyrillic-to-Latin script [20:07:50] probably, and if it's a blog article in English written by a German speaking of their friends? [20:07:59] transliteration is *hard* [20:08:13] Wikidata can't predict all context [20:08:31] but we *can* list all usual transliterations of a written string [20:09:06] nikki: we use the property "transliteration" with "language of work or name" as a qualifier [20:09:36] so in this case, probably the Japanese label would be the English transliteration, with German as alias [20:09:51] but both transliterations would be values of the property [20:10:04] with "English" or "German" as value of the qualifiers [20:12:22] so "michael" would have a transliteration property with "ミヒャエル" and language of work or name as "german"? that sounds really weird :/ [20:12:29] because what can you do about all the German immigration to the USA in the XIX century? [20:12:36] context is always key [20:12:47] and Wikidata can't deal massively with context [20:13:01] nikki: no, sorry, I'm tired [20:13:15] nikki: language of name would be Japanese [20:14:25] PROBLEM - wikidata.org dispatch lag is higher than 300s on www.wikidata.org is CRITICAL: HTTP CRITICAL: HTTP/1.1 200 OK - pattern not found - 1969 bytes in 0.099 second response time [20:14:32] it's P518 with "German" or E,glish [20:14:41] "applies to part" [20:14:52] my mistake, I'm tired [20:15:21] ah [20:15:53] so that's would mean "that's the Japanese transliteration for the German version of this name" [20:16:00] which make way more sense [20:16:13] yeah [20:18:18] but yeah, we'll always have problems with context [20:18:25] there are way too many exceptions [20:18:43] we try to *at least* have the correct original strings [20:19:11] but like, Tolstoï is not the current correct way to write this name in French [20:19:31] but nobody would thing about publishing War and Peace under another name in France [20:19:37] that's *the* name [20:19:53] and there are cases like that in *every* language [20:20:54] but at least Wikidata can say that his name was Толстой [20:21:12] no matter how you would write it in German, English or French [20:23:20] well, that’s what labels are for, right? [20:23:44] the label of that particular author can spell it Tolstoï even if the now usual transliteration of the family name is different [20:23:57] WikidataFacts: we were talking about how to chose a label when there are several possible transliterations for the name [20:24:03] ah yes [20:24:10] on the individual item [20:24:13] yes [20:24:18] I totally agree with you [20:24:37] (hm, reading it again now, “that’s what labels are for” really wasn’t very clear at all ^^) [20:24:43] we can't deal with exceptions at the name level, there are simply too many [20:24:58] but we can and do deal with it on each concerned item [20:25:24] (I love the "transliteration" property too) [20:26:04] basically: names are really complicated, so it's complicated on Wikidata too but we do our very best regardless [20:27:06] WikidataFacts: the file for namescript should be on the namescript folder? [20:28:20] it can be somewhere else as well if you specify the path to it [20:28:31] but if you just specify the file name, it should be in the same directory, yes [20:28:39] but if I'm too lazy, the same directory? [20:28:42] great [20:28:43] yes [20:28:54] I hate specifying paths, I never remember how [20:28:59] tab completion should help [20:29:01] but moving files, no problems [20:29:13] even in the same directory [20:29:31] if the file is actually called “filename”, you could just type “fi” and it should fill in the rest automatically [20:29:44] it just seems confusing to me to transliterate the name if that means it's going to show a completely inappropriate transliteration for a lot of the uses, I'd rather see the original name then :/ [20:30:01] (well, of course, it's working now that I have a version with all Qids separated by a space) [20:30:30] nikki: then you can make your infobox show P1705 instead [20:31:18] I'm talking about viewing and editing wikidata [20:31:45] well people don't really want to see error messages when trying to see labels in their languages [20:32:06] the "real" name is always in description and as an alias [20:32:27] but labels should be in their language [20:32:50] empty squares don't make for user-friendly labels [20:35:49] the other way round, we seem to have split the names [20:37:27] ? [20:37:30] like "河野" can be pronunced kawano or kōno, but we don't have a single item for "河野", we have one for each pronunciation [20:37:48] because in Japanese that's two different legal names [20:38:35] people named 河野 Kawano are *not* sharing a family name with people named 河野 Kōno [20:39:17] Japanese has to deal with several writing systems at the same time [20:39:57] a Japanese name is the combination kanji-kana [20:40:04] so we have an item by combination [20:40:28] why do some dates display 'gregorian' and others don't? [20:41:39] SothoTalKer: some are in Julian [20:42:15] SothoTalKer: it clarifies the calendar if the date is in some range where both calendars were in use, I think [20:42:39] 1926 is cleary one of those years where both were used [20:42:40] e. g. for 21 May 2018 you wouldn’t normally assume that the calendar is in Julian, so the “Gregorian” isn’t shown [20:43:00] *when [20:45:04] nikki: but we are not breaking up a combination kanji-kana because it's pronounced differently in Hokkaido and Kyushu [20:46:40] and we are not breaking down Korean names based on hanja, we follow the hangul [20:47:24] WikidataFacts: https://www.wikidata.org/wiki/Q16012935 - i can't see a difference between the birth and death date when editing, but one shows it, the other doesn't [20:48:14] SothoTalKer: that’s because the date of death is late enough that you would just assume the Gregorian calendar [20:48:26] I’m not sure where the cut-off is [20:48:57] but at some point it’s no longer necessary to specify that a value is Gregorian, you can just assume that’s the default interpretation [20:49:37] but surely korean names should follow the same model as japanese [20:49:38] Seems the last European country switched in 1926 [20:50:17] as far as I'm aware, people have a particular hanja name, you can't just pick any of the hanja that match [20:51:47] SothoTalKer, reosarevok: found it, the range where the date is considered ambiguous is (1580, 1930) https://gerrit.wikimedia.org/g/mediawiki/extensions/Wikibase/+/e9777a6013d15258a41d0bd99d0f33abf06cc41f/lib/includes/Formatters/HtmlTimeFormatter.php#109 [20:52:10] Hmm, ok. A bit late but I guess it makes sense, if it means people don't have to guess [20:52:27] nice (: [20:52:37] and thanks :) [20:52:46] you’re welcome :) [20:56:43] nikki: yes, but Korean people told us the hanja were not on official papers? [20:57:33] so you individually know what your hanja are but that's not an official break down anymore? [20:57:55] I'm not sure, we need more Korean people on Wikidata :) [20:58:39] but kowiki don't give us the hanja version of names [20:58:54] jawiki *always* offers the kana version [20:59:03] huh... I thought they were [20:59:16] so I'm really not sure it has the same value [20:59:33] https://www.quora.com/Do-most-people-in-South-Korea-have-Hanja-names-on-their-identity-cards claims they're on id cards at least [21:00:45] nikki: so hanja is widely used but not mandatory? [21:00:55] that's my understanding [21:00:57] since some people do have names without hanja [21:01:02] but I'm not korean and don't know any koreans [21:01:21] in Japan, you just can't have a name outside of the kanji-kana combination [21:01:35] my cousin is studying Korean and is in Korea right now [21:01:48] I'll ask here for more information [21:02:10] she should know who to ask, at least [21:03:22] her* [21:04:34] well, I'm going to bed [21:04:46] have a good night everyone! [21:14:44] * abian wanted to say "Happy birthday" to Harmonia_Amanda :'( [21:22:40] do it tomorrow? [21:22:45] RECOVERY - wikidata.org dispatch lag is higher than 300s on www.wikidata.org is OK: HTTP OK: HTTP/1.1 200 OK - 1977 bytes in 0.238 second response time [21:26:56] Yeah :) [21:30:35] PROBLEM - wikidata.org dispatch lag is higher than 300s on www.wikidata.org is CRITICAL: HTTP CRITICAL: HTTP/1.1 200 OK - pattern not found - 1973 bytes in 0.116 second response time [21:35:46] RECOVERY - wikidata.org dispatch lag is higher than 300s on www.wikidata.org is OK: HTTP OK: HTTP/1.1 200 OK - 1969 bytes in 0.102 second response time [21:43:35] PROBLEM - wikidata.org dispatch lag is higher than 300s on www.wikidata.org is CRITICAL: HTTP CRITICAL: HTTP/1.1 200 OK - pattern not found - 1971 bytes in 0.100 second response time [22:09:55] RECOVERY - wikidata.org dispatch lag is higher than 300s on www.wikidata.org is OK: HTTP OK: HTTP/1.1 200 OK - 1963 bytes in 0.147 second response time [23:20:46] PROBLEM - wikidata.org dispatch lag is higher than 300s on www.wikidata.org is CRITICAL: HTTP CRITICAL: HTTP/1.1 200 OK - pattern not found - 1970 bytes in 0.102 second response time [23:36:35] RECOVERY - wikidata.org dispatch lag is higher than 300s on www.wikidata.org is OK: HTTP OK: HTTP/1.1 200 OK - 1978 bytes in 0.101 second response time [23:54:46] PROBLEM - wikidata.org dispatch lag is higher than 300s on www.wikidata.org is CRITICAL: HTTP CRITICAL: HTTP/1.1 200 OK - pattern not found - 1972 bytes in 0.225 second response time