[08:16:42] New patchset: Daniel Kinzler; "(bug 50478) Filter langlinks by site group." [mediawiki/extensions/Wikibase] (master) - https://gerrit.wikimedia.org/r/71302 [08:26:49] New patchset: Daniel Kinzler; "(bug 50478) Filter langlinks by site group." [mediawiki/extensions/Wikibase] (master) - https://gerrit.wikimedia.org/r/71302 [08:35:58] New patchset: Daniel Kinzler; "Use MockStiteStore for testing" [mediawiki/extensions/Wikibase] (master) - https://gerrit.wikimedia.org/r/71322 [08:37:18] New patchset: Daniel Kinzler; "(bug 50478) Filter langlinks by site group." [mediawiki/extensions/Wikibase] (master) - https://gerrit.wikimedia.org/r/71302 [08:47:45] New review: Aude; "(1 comment)" [mediawiki/extensions/Wikibase] (master) - https://gerrit.wikimedia.org/r/71322 [09:04:00] aude: hello! [09:04:15] I hope I'm not late for the hangout? [09:12:27] here's the sitelink group bug: https://bugzilla.wikimedia.org/show_bug.cgi?id=50478 [09:12:39] and the cache key thing: https://bugzilla.wikimedia.org/show_bug.cgi?id=50303 [09:12:58] ...and the deployment issues katie mentioned: https://bugzilla.wikimedia.org/show_bug.cgi?id=50371 [09:13:08] i'm not sure i fully understand that bug report though... [09:14:29] DanielK_WMDE_: we got the deployment thing, although it's a bit problematic the way we load the extension [09:15:03] aude: is it problematic only because we had it deployed twice in this case? [09:15:04] we return null if the constant is defined and then localisation update was unable to load it [09:15:14] no, it was not deployed twice [09:15:32] but the data model constant must have already been set in the Wikibase extension in wmf8 [09:15:47] then they added data model to wmf8 so they could run localisation update [09:16:00] ...because the code was in there, too. that's what i meant by "twice" [09:16:10] and it crashed because it returned null the second time and couldn't find WikibaseDataModel.i18n.php [09:16:14] yes [09:16:17] but about returning null... the top level include *always* returns null, no? [09:16:24] what else would it return? [09:16:28] it's an issue that will occur with DataValues if we split that stuff out [09:16:37] right [09:16:42] DanielK_WMDE_: it's before i18n is loaded [09:16:51] and then is used in !include_once [09:16:55] which is unreliable [09:17:07] hm... [09:17:16] it could be include_once === false, though still risky [09:17:16] that's in the localisation script [09:17:47] and then it rebuilt a corrupt localisation cache, which roan did not realise before he scapped things :( [09:17:57] eek [09:18:01] there obviously needs to be a check that the cache is good [09:18:20] so... the rebuild script loads the extension files explicitly? not the i18n files directly? [09:18:27] with my change, the localisation update will still abort but have the option to --force and override [09:18:34] e.g. as appropriate in our situation [09:18:46] apparently [09:18:56] it's a mw instance [09:19:04] everything is loaded [09:19:13] isn't the localization cache going to be wonkey anyway whenever we have multiple versions of some module/extension deployed? [09:19:32] our multiple versions are on different versions of core [09:19:32] or do we have one cache per deployed branch? [09:19:36] e.g. different code bases [09:19:55] the problem just is when we have a new extension for the new branch, but the extension has to be put everywhere [09:19:58] yea, but is the split that way too? [09:20:14] it does not have to be part of require_once() explicitly [09:20:21] but the script will search for it [09:20:23] yea... why does it have to be put everywhere? [09:20:33] * aude asked the same question [09:20:39] that's what i'm attempting to address [09:20:42] :P [09:20:43] normally it's that way [09:20:44] fun times [09:20:57] i'm adding the option to override and skip the extension [09:21:23] there are various other issues in the cache rebuild scripts and scap process that are out of scope for us [09:21:39] could have made a dummy branch for the extension, contianing only dummy files, and the set the submodule for the old wmf branch to that [09:21:47] we could [09:21:47] (nasty hack, but should work, right?) [09:22:17] anyway, need to think about this if we split out the datavalues componentes [09:22:20] components [09:22:27] the query ones are fine as they are not loaded now [09:23:51] DanielK_WMDE_: anyway, if you like to do some code review, https://gerrit.wikimedia.org/r/#/q/status:open+project:mediawiki/extensions/Wikibase+owner:%22Liangent%22,n,z [09:24:02] if you want to take a look at liangent's stuff [09:24:39] otherwise i'll review later and try to get stuff merged [09:37:42] aude: i want to püush the property info stuff first, then look at cache keys. may do reviews before or after cache keys. [09:37:49] DanielK_WMDE_: ok [09:37:59] denny is also around and can review [09:43:17] New patchset: Nikerabbit; "Use MockSiteStore for testing" [mediawiki/extensions/Wikibase] (master) - https://gerrit.wikimedia.org/r/71322 [09:43:49] New review: Nikerabbit; "(1 comment)" [mediawiki/extensions/Wikibase] (master) - https://gerrit.wikimedia.org/r/71322 [09:44:57] Henning_WMDE: https://bugzilla.wikimedia.org/show_bug.cgi?id=50491 [09:45:06] Abraham_WMDE: can you put it on the board as well? https://bugzilla.wikimedia.org/show_bug.cgi?id=50491 [09:45:43] Denny_WMDE: done [09:47:51] Abraham_WMDE: thx [10:18:20] Abraham_WMDE: can yopu please put these on the borad? 50478 (review) and 50303(doing) [11:11:49] yoo [11:28:05] aude: Denny_WMDE: I don't dare to create new patches too fast without getting existing patches reviewed, or naming problems require me to manually rebase a bunch of dependent patches [11:28:48] liangent: you get used to it :) [11:29:23] liangent: since a lot of people are on vacation, review backlock is a problem. i'll try to get some reviewing done today, but can't promise [11:30:37] DanielK_WMDE_: how are your vacations arranged :p [11:36:54] liangent: reviews for you are on my to do list for today [11:37:00] and i understand your hesitance for that [11:37:28] btw i am also fine with merging and then refactoring / renaming later (but it has to happen very soon afterwards) [11:37:36] this at least saves some mess from git [11:38:30] liangent: i'm here the next four weeks. i'm mostly unavailable in august. [11:39:45] liangent: if Denny_WMDE does not review, i can probably when i get home [11:40:06] renaming can be done later or any issues in a follow up [11:43:24] https://bugzilla.wikimedia.org/show_bug.cgi?id=46352 [11:44:07] Denny_WMDE: DanielK_WMDE_: aude: got it [11:44:12] liangent: ok [11:44:22] ^^ DanielK_WMDE_ when you have time, you want to check that bug and confirm or resolve https://bugzilla.wikimedia.org/show_bug.cgi?id=46352 [11:44:25] (iirc) [11:44:28] https://bugzilla.wikimedia.org/show_bug.cgi?id=49978 [11:45:49] https://bugzilla.wikimedia.org/show_bug.cgi?id=49952 [11:46:40] https://bugzilla.wikimedia.org/show_bug.cgi?id=47610 [11:48:03] https://bugzilla.wikimedia.org/show_bug.cgi?id=49742 [11:48:52] https://bugzilla.wikimedia.org/show_bug.cgi?id=49740 [11:49:13] New patchset: Daniel Kinzler; "(bug 49742) introducing PropertyInfoTable." [mediawiki/extensions/Wikibase] (master) - https://gerrit.wikimedia.org/r/71333 [11:50:21] Denny_WMDE: for statements display, is silent fallback to another language ok? it's difficult to find a good design to insert a language tag everywhere, and it messes up the interface [11:50:34] New patchset: Daniel Kinzler; "(bug 49742) introducing PropertyInfoTable." [mediawiki/extensions/Wikibase] (master) - https://gerrit.wikimedia.org/r/71333 [11:50:38] eg dropdown list [11:50:48] liangent: no, completely silent is not good [11:51:45] liangent, Denny_WMDE: i'd say anything that can be edited in the current context must be very explicit about language fallback. but when showing a label in an entity selector or some such, a silent fallback is probably ok, don' [11:51:50] ...don't you think? [11:52:03] https://bugzilla.wikimedia.org/show_bug.cgi?id=49315 [11:52:08] that is also required [11:52:40] https://bugzilla.wikimedia.org/show_bug.cgi?id=49642 [11:53:14] Denny_WMDE: checking 46352 now [11:53:42] liangent: agree with daniel [11:53:57] aude: DanielK_WMDE_: the only problem I see is https://en.wikipedia.org/wiki/False_friend [11:54:08] liangent: example? [11:54:16] https://bugzilla.wikimedia.org/show_bug.cgi?id=46555 [11:54:24] in the selector it could be an added (de) [11:54:36] liangent: that's why there should always be a description... [11:54:53] https://bugzilla.wikimedia.org/show_bug.cgi?id=49583 [11:55:03] Denny_WMDE: that's a simple solution, but are language codes really a nice idea? shouildn't iot be the language name? [11:55:26] yeah, language name is good [11:55:37] but that's too long [11:56:02] liangent: why? [11:56:15] i mean, what's the problem with it being long? [11:56:30] hello hoo [11:56:34] https://bugzilla.wikimedia.org/show_bug.cgi?id=49571 [11:56:50] * DanielK_WMDE_ is missing the triage [11:57:00] hi DanielK_WMDE_ :) [11:57:05] DanielK_WMDE_: the suggest list is so small [11:57:08] DanielK_WMDE_: speak up if you have any comments [11:57:39] aude: can't follow atm, and got too much other stuff to do. [11:57:44] ok [11:57:49] https://bugzilla.wikimedia.org/show_bug.cgi?id=49554 [11:58:02] Abraham_WMDE: is there a quick log of what was triaged, and what the outcome was for each? [11:58:08] i'd like to look over it later [11:59:11] DanielK_WMDE_: maybe list of wikidata bugs changed today [11:59:49] https://bugzilla.wikimedia.org/show_bug.cgi?id=49532 [12:00:03] DanielK_WMDE_: not really, we're going through the unprioritized bugs [12:00:30] https://bugzilla.wikimedia.org/show_bug.cgi?id=49527 [12:01:15] https://bugzilla.wikimedia.org/buglist.cgi?cmdtype=dorem&remaction=run&namedcmd=wikidata-1d&sharer_id=10206&list_id=212913 [12:01:20] DanielK_WMDE_: ^ [12:01:26] i have to add data value bugs to that [12:01:29] Denny_WMDE: is it ok to introduce a pseudo language code to indicate "the finally looked up label after the fallback chain is completely resolved" in serialized form for UI, eg wbUsedEntities? [12:01:37] like {"p2":{"id":"p2","type":"property","labels":{"qqz":{"language":"de","value":"AnotherItem"}},"datatype":"wikibase-item","title":"Property:P2","lastrevid":47},"q3":{"id":"q3","type":"item","labels":{"qqz":{"language":"en","value":"Stuff"}},"title":"Item:Q3","lastrevid":56}} [12:03:45] https://bugzilla.wikimedia.org/show_bug.cgi?id=45363 [12:03:58] liangent: trying to follow [12:06:11] https://bugzilla.wikimedia.org/show_bug.cgi?id=47317 [12:06:39] Denny_WMDE: ? [12:06:40] https://bugzilla.wikimedia.org/show_bug.cgi?id=49432 [12:07:02] liangent: we're in a bug triage meeting [12:07:13] once we're done, he can answer [12:07:13] Denny_WMDE: undo via api is indeed an issue [12:07:50] aude: ok [12:08:25] DanielK_WMDE_: so you confirm the bug? [12:08:47] New patchset: LivingShadow; "Documentation for RepoApi.createClaim extended" [mediawiki/extensions/Wikibase] (master) - https://gerrit.wikimedia.org/r/71175 [12:09:05] Denny_WMDE: yes. [12:09:21] ok, thanks [12:09:30] Lydia_WMDE: https://bugzilla.wikimedia.org/show_bug.cgi?id=44749 [12:09:53] aude: If you have a second... what do you think about https://gerrit.wikimedia.org/r/#/c/71175/2/lib/resources/wikibase.RepoApi/wikibase.RepoApi.js ? [12:10:29] I don't think such stuff belongs there, only the wrapper itself should be documented and not the API [12:10:31] hoo: the documentation or the patch as a while? [12:10:33] (except of types) [12:10:33] whole? [12:11:24] https://bugzilla.wikimedia.org/show_bug.cgi?id=48709 [12:11:49] hoo: i think those details are not needed but if we want them there then ok [12:11:50] aude: Yep... I think we shouldn't have more than the plain param descriptions there... [12:11:59] sure, sounds fine [12:12:04] I don't really want them there... hard to maintain [12:12:48] hoo: then remove them [12:12:52] sounds reasonable to me [12:13:57] aude: Ok, going to -2 the change then [12:13:58] hoo: and has Henning_WMDE or danwe reviewed that patch yet [12:14:03] hmmmmm, ok [12:14:18] * aude don't want you to be stuck [12:14:18] I don't feel comfortable -2ing a volunteer patch, tbh [12:14:28] ok [12:15:31] https://bugzilla.wikimedia.org/show_bug.cgi?id=49433 [12:16:48] aude: what's the verb for abandoned ... to abandone ? Autocorrect and dict.cc don't like that... [12:16:51] https://bugzilla.wikimedia.org/show_bug.cgi?id=49186 [12:17:01] abandon [12:17:03] to abandon [12:17:18] ah... stupid /me [12:17:23] Thank you both :) [12:17:28] https://bugzilla.wikimedia.org/show_bug.cgi?id=48888 [12:18:02] https://bugzilla.wikimedia.org/show_bug.cgi?id=48938 [12:18:43] https://bugzilla.wikimedia.org/show_bug.cgi?id=48567 [12:19:52] New review: Hoo man; "I don't really think we want more documentation in RepoApi as that just doesn't really belong there ..." [mediawiki/extensions/Wikibase] (master) C: -1; - https://gerrit.wikimedia.org/r/71175 [12:23:04] hoo: I'm okay with it. But the docs have to be linked in a way that it can also be found. I learned using the API not via docs, because I could not find any, but by digging through the code and reading server responses in Firebug. [12:23:25] (LivingShadow is me) [12:23:41] Granjow: mh [12:24:17] maybe just link the automatic documentation at https://www.wikidata.org/w/api.php and the help pages on mediawiki.org in the file header once? [12:24:45] hoo: Yes, thought of this as well. That would already help a lot. [12:24:47] Like "Documentation for the API modules can be found at ..." [12:25:17] that's probably nicer than to expand the documentation of each method with a lot of redundant information which can be hard to keep up to date [12:25:59] hoo: Plus, I started searching on the wikidata.org main page -- but there is literally nothing at all to be found. [12:26:16] Yes, this totally makes sense! [12:26:50] Henning_WMDE: could you take a look at https://bugzilla.wikimedia.org/show_bug.cgi?id=48567 please? [12:27:49] https://bugzilla.wikimedia.org/show_bug.cgi?id=49349 [12:27:59] Btw, do you use to publish upgrade notes (breaking changes or so)? Like the new WikibaseDataModel introduced last week. I just got a blank page, without any error message at all, when I upgraded Wikibase but did not notice the new repository. [12:28:46] Denny_WMDE: re templates in labels... wtf?! how does that happen? if it does indeed happen, i'd think this shoudl be pretty high prio, no? [12:28:53] Granjow: we're trying to add it to the weekly summaries but it doesn't already happen :( [12:28:54] https://bugzilla.wikimedia.org/show_bug.cgi?id=49315 [12:29:11] Granjow: You should follow our mailing list(s) [12:29:13] DanielK_WMDE_: yep, we just put it on immediate and i want to assign it right away, that's bad [12:29:40] i'm still very confused as to how that would happen. odd. [12:29:49] me either, i first didnt believe it [12:30:42] hoo: Which one? [12:31:14] Granjow: we got wikidata-l and wikidata-tech [12:31:15] https://bugzilla.wikimedia.org/show_bug.cgi?id=49282 [12:31:20] DanielK_WMDE_: wait, why'd you just un-confirm it? [12:31:34] PinkAmpersand: i did whut? [12:31:39] https://bugzilla.wikimedia.org/show_activity.cgi?id=48567 [12:31:42] hoo: Just noticed, createEntity also lists «query» as supported type, but the API (* action=wbeditentity *) does not, what is the query for? [12:32:03] wtf? [12:32:05] looks like the bugzilla version of an edit conflict :P [12:32:08] oh, bugzilla, i hate you [12:32:19] all i did was hit "save" to add myself to the cc list [12:32:23] https://bugzilla.wikimedia.org/show_bug.cgi?id=49306 [12:32:33] apparently, bugzilla didn't detect the "mid air collision" :( [12:32:51] https://bugzilla.wikimedia.org/show_bug.cgi?id=49298 [12:33:19] Granjow: That's weird [12:33:30] Denny_WMDE: btw, if i'd thought y'all would care that much about that bug, i'd've upped the severity and bothered some of you about it weeks ago [12:34:04] https://bugzilla.wikimedia.org/show_bug.cgi?id=49240 [12:34:19] PinkAmpersand: this one scares us a bit, yeah :) [12:35:11] Granjow: Could you be so kind and remove that as well? That's a great example to my points above :P [12:35:19] * for my [12:35:26] well, let's take a moment to thank the clueless n00b who set an item's label to {{delete}} 6 weeks ago ;) [12:35:27] [6] 10https://www.wikidata.org/wiki/Template:delete [12:35:37] PinkAmpersand: feel free to always bother me about such bugs - it's ok in this case to bother me once too much ;-) [12:36:22] https://bugzilla.wikimedia.org/show_bug.cgi?id=49242 [12:36:59] hehe, I love bothering you guys about this stuff. this is just one of those things that matters way more from a developer perspective than from a luser perspective, and since i'm a luser, I'm not great at guessing what will matter :P [12:37:30] hehe yeah [12:38:00] https://bugzilla.wikimedia.org/show_bug.cgi?id=49236 [12:38:54] https://bugzilla.wikimedia.org/show_bug.cgi?id=49235 [12:40:33] DanielK_WMDE_: we just closed https://bugzilla.wikimedia.org/show_bug.cgi?id=49235 as not reproducible. if we misunderstood something, let us know [12:40:35] https://bugzilla.wikimedia.org/show_bug.cgi?id=46644 [12:42:29] https://bugzilla.wikimedia.org/show_bug.cgi?id=49171 [12:42:47] https://bugzilla.wikimedia.org/show_bug.cgi?id=49165 [12:43:58] Denny_WMDE, aude: our own dumb template engine uses {{....}} for parameters. So if that occurss in a paramerters, it may get replaced. [12:43:59] [7] 04https://www.wikidata.org/wiki/Template:%2E%2E%2E%2E [12:44:14] oh, makes sense [12:44:19] https://bugzilla.wikimedia.org/show_bug.cgi?id=49124 [12:44:23] Henning_WMDE! ^ [12:44:29] Denny_WMDE, aude: The solution is to esacape {{ in all parameters to templates [12:44:34] yep [12:44:40] Henning_WMDE: oh, right ---^ [12:44:43] :) [12:45:35] https://bugzilla.wikimedia.org/show_bug.cgi?id=45529 [12:47:15] https://bugzilla.wikimedia.org/show_bug.cgi?id=49111 [12:47:46] https://bugzilla.wikimedia.org/show_bug.cgi?id=49014 [12:48:41] hoo: sure :) [12:49:38] https://bugzilla.wikimedia.org/show_bug.cgi?id=49102 [12:55:11] https://bugzilla.wikimedia.org/show_bug.cgi?id=49067 [12:57:39] liangent: hi, sorry for letting you wait [12:58:06] New patchset: Daniel Kinzler; "(bug 49742) Rebuild script for property info table." [mediawiki/extensions/Wikibase] (master) - https://gerrit.wikimedia.org/r/71336 [12:58:55] New patchset: LivingShadow; "RepoApi.js: Links to documentation added." [mediawiki/extensions/Wikibase] (master) - https://gerrit.wikimedia.org/r/71337 [12:59:11] Denny_WMDE: ok [12:59:12] finished? [12:59:14] yes [12:59:20] so regarding the display [12:59:33] * aude happy the meeting is done :) [12:59:36] i think everywhere it is displayed, we can put something there [13:00:03] i am just trying to find my demo for that... [13:01:20] grrr... sqlite... https://integration.wikimedia.org/ci/job/mwext-Wikibase-client-tests/1165/console [13:01:24] ah, need to upload first [13:01:26] is WikibaseDataModel depending on Wikibase? [13:01:47] liangent: i think the other way around [13:01:55] data model is intended to be stand alone [13:02:01] e.g. bots could use it outside of mediawiki [13:02:54] hmm so what if I want to use my language classes/functions in DataModel? [13:03:08] or should I just move that part of logic to Wikibase? [13:03:28] the latter [13:03:34] what denny says [13:03:45] or inject it into the datamodel [13:03:55] and refactor the datamodel so it can take that as a dependency [13:04:11] liangent: here's my little demo on how i think that could look like: http://simia.net/languagetext/ [13:04:19] like if ( class_exists( ... ) ) { ... } ? [13:04:27] New patchset: Daniel Kinzler; "(bug 49742) introducing PropertyInfoTable." [mediawiki/extensions/Wikibase] (master) - https://gerrit.wikimedia.org/r/71333 [13:04:50] liangent: no, rather have a standard implementation of the functionality without your fallback in the datamodel [13:05:00] and then be able to replace that with a class of your own [13:06:17] but let's first understand what exactly you want to do [13:06:19] Lydia_WMDE: https://gerrit.wikimedia.org/r/#/c/71087/ :) [13:06:24] shall i start reviewing your code now? [13:06:36] aude: thx [13:06:39] or shall we talk first? [13:06:41] wb_entity_per_page will be available in the dumps [13:06:57] for anyone who does not wish to run that rebuild script [13:08:29] New patchset: Daniel Kinzler; "(bug 49742) Adding caching layer for property info." [mediawiki/extensions/Wikibase] (master) - https://gerrit.wikimedia.org/r/71339 [13:11:09] Denny_WMDE: some quick talk first is fine [13:11:24] put ui design talk after review [13:11:27] Abraham_WMDE: put this one please on the list for wednesday - https://bugzilla.wikimedia.org/show_bug.cgi?id=48567 [13:11:38] liangent: ok, great [13:12:05] for what I'm trying to do: Entity::getLabels() is in datamodel which accept an array of language codes [13:12:25] I want to change it to / make a new function in Entity to accept fallback chains [13:12:36] understand [13:13:05] so basically, i ask Entity::getLabels('de') and it returns the 'en' fallback if it does not find a 'de'? [13:13:19] what would be the signature of the new function? [13:13:38] hmm let me make it accept a fully expanded fallback chain [13:14:16] like Entity::getLabels( array( array('de','en'), array('zh-cn', 'zh', 'en') ) [13:15:13] in these case those 'de','en','zh-cn', 'zh', 'en' will be LanguageWithConversion objects [13:15:28] hehe, my patchset has number 1337 :D [13:15:35] if the caller can't provide it (not have Wikibase installed), it's fine not to use this feature [13:15:45] New patchset: Daniel Kinzler; "(bug 49742) Introducing PropertyInfoDataTypeLookup" [mediawiki/extensions/Wikibase] (master) - https://gerrit.wikimedia.org/r/71341 [13:16:37] liangent: trying to understand... [13:16:50] so this is resolved :p [13:16:57] so the signature is an array of language codes [13:17:02] and each array is a fallback-chain [13:17:14] and the whole thing wrapped in an array [13:17:28] whereas right now it was an array of language codes [13:18:05] it's signature will be like the new version of setLanguages in https://gerrit.wikimedia.org/r/#/c/71182/5/lib/includes/serializers/SerializationOptions.php [13:19:40] what's the current signature? [13:19:43] an array of ( ( string as language code ) OR ( array of ( LanguageWithConversion objects ) as fallback chains ) ) [13:20:02] currently it is is array of string as language code? [13:20:06] right [13:20:14] ok [13:20:34] where is languagewithconversion situated? [13:21:03] you mean where are they created? [13:21:10] in which extension is the code? [13:21:15] Wikibase [13:21:41] hmm, now i see. if it stays there the datamodel would be dependent on wikibase [13:21:49] that's what you meant earlier, right? [13:22:27] doesn't make things easier, but i wonder if language with conversion is generic enough a thing to be in core? [13:22:30] maybe at some point [13:22:52] then model would depend on core [13:23:12] the class already depends on core [13:23:14] at the moment [13:23:29] but the model does not [13:23:33] right [13:23:38] Denny_WMDE: well if you don't have Wikibase when using DataModel, you can't get ( array of ( LanguageWithConversion objects ) as fallback chains ) to feed to that getLabels [13:24:13] yes, but you still need to write code that deals with that when it comes in [13:24:21] and then you need wikibase code [13:24:33] I only call $something->translate( ) [13:24:41] any "glue" between data model and mediawiki stuff or mediawiki dependent stuff is in wikibase [13:24:44] as denny says [13:24:50] I don't really care whether it's really LanguageWithConversion .. [13:25:13] another option could be to resolve the list before [13:25:19] $something->getLanguage( ) $something->getFetchLanguage( ) $something->translate( ) [13:25:31] and ask Entity::getlabel with a flat list [13:26:06] no it depends on how many labels does the entity have [13:26:18] explain please [13:26:21] or I have to get a full list of labels, then intersect myself [13:26:22] New patchset: Daniel Kinzler; "(bug 49742) Hook PropertyInfoStore in service reg." [mediawiki/extensions/Wikibase] (master) - https://gerrit.wikimedia.org/r/71343 [13:26:47] liangent: that would be bad, indeed. but i don't fully understand, sorry [13:28:25] benecloudstar around? :) [13:30:39] Denny_WMDE: there'll be something [13:30:39] $returnLabels = array(); [13:30:39] foreach ( $chains as $chainFor => $chain ) { [13:30:39] foreach ( $item in $chain ) { [13:30:39] if ( isset( $label[$item->getFetchLanguage()->getCode()] ) { [13:30:39] $returnLabels[$chainFor] = array( [13:30:39] 'language' => $item->getLanguage()->getCode(), [13:30:40] 'value' => $item->translate( $label[$item->getFetchLanguage()->getCode()] ), [13:30:40] ); [13:30:41] break; [13:30:41] } } } [13:33:48] if this piece of code is in DataModel, $label is already these, and getFetchLanguage/getLanguage/translate works as duck typing [13:34:31] if it's in Wikibase, I should get $label with ->getLabels() with no language restriction first [13:35:33] i am sorry, i am really trying to follow [13:35:41] can we make an example of an item with a few labels [13:35:46] and an example request [13:35:56] and what should come out given a few such example requests [13:36:12] i am very sorry for being so slow [13:39:48] Denny_WMDE: well will it be easier to write some demo code first [13:40:13] maybe [13:40:15] or will understanding that be difficult for you [13:40:26] i am trying to write an example [13:40:26] given an item [13:40:31] given a few requests [13:40:35] what is the expected result [13:41:25] then another question, is this fine to use qqz to indicate requests language? {"p2":{"id":"p2","type":"property","labels":{"qqz":{"language":"de","value":"AnotherItem"}},"datatype":"wikibase-item","title":"Property:P2","lastrevid":47},"q3":{"id":"q3","type":"item","labels":{"qqz":{"language":"en","value":"Stuff"}},"title":"Item:Q3","lastrevid":56}} [13:42:04] New patchset: Daniel Kinzler; "(bug 49742) introducing PropertyInfoTable." [mediawiki/extensions/Wikibase] (master) - https://gerrit.wikimedia.org/r/71333 [13:42:09] liangent: https://www.mediawiki.org/wiki/User:Liangent/wb-lang/example [13:42:13] can you continue on this one? [13:42:16] as an example? [13:42:21] i will check your other question now [13:43:57] in your example, "qqz" means "in the language that was requested", and "de" (for the label) is the language of the actual result, right? the requested language is nowhere visible anymore, is this correctly understood? [13:46:10] Denny_WMDE: added [13:46:35] and qqa=qqz I randomly picked another one [13:47:06] reload. I edited a bit [13:48:24] why do i ask for sr-ec-converted-from-sr instead of sr-ec only? [13:48:56] sr-ec-converted-from-sr is a LanguageWithConversion object, right? [13:49:38] right [13:50:15] well let me expand it to answer "why do i ask for sr-ec-converted-from-sr instead of sr-ec only?" [13:50:37] done [13:51:26] edited again [13:51:44] ok, i will add a bit more to see whether i understood [13:52:07] btw do you think duck typing is called a dependency? [13:52:22] I'm used to this as a python user too [13:52:44] i think it should be a dependency also in PHP [13:52:54] but i am not a good PHP developer [13:53:15] i would like to hear some of the more experienced devs on that (DanielK_WMDE_ Jeroen aude ?) [13:54:19] you don't really need a LanguageWithConversion here, as long as it can provide getLanguage()->\Language, getFetchLanguage()->\Language, translate(string)->string, it's ok [13:54:52] for that sr-ec-converted-from-sr fallback item [13:55:06] liangent: i extended the example a bit more [13:55:11] can you please check and correct? [13:55:37] i will quickly bother jeroen, he just walked in about the duck typing [13:55:57] liangent: duck typing is usually not a good idea, much better to add an interface. [13:56:12] you can benefit much better from ide support for type hinting and parameter checking that way [13:56:33] we are working with type hints as much as possible, and duck typing will not work with that at all. [13:56:43] DanielK_WMDE_: well I don't use ide :p [13:56:56] * aude uses vim :D [13:56:59] http://www.wikidata.org/wiki/User:AvocatoBot >> http://benestar.github.io/DotNetDataBot/ [13:57:06] dislikes ide [13:57:10] New patchset: Daniel Kinzler; "(bug 49742) Rebuild script for property info table." [mediawiki/extensions/Wikibase] (master) - https://gerrit.wikimedia.org/r/71336 [13:57:20] New patchset: Daniel Kinzler; "(bug 49742) Adding caching layer for property info." [mediawiki/extensions/Wikibase] (master) - https://gerrit.wikimedia.org/r/71339 [13:57:28] Lydia_WMDE: ^^ [13:57:54] liangent: other people do, and type mismatches will be highlighted as errors. also type hinting is enforced by php at runtime. [13:58:31] * DanielK_WMDE_ thinks IDEs are great to avoid errors and spend less time finding and opening files, searching around, etc [13:58:49] * aude disagrees with DanielK_WMDE_ :) [13:59:19] aude: we could benchmark at some point :) [13:59:23] heh [13:59:36] also, source code debugging is a must, imho. [13:59:44]