Page MenuHomePhabricator

ArthurPSmith (Arthur Smith)
User

Projects (8)

Today

  • Clear sailing ahead.

Tomorrow

  • Clear sailing ahead.

Monday

  • Clear sailing ahead.

User Details

User Since
Oct 5 2015, 2:29 PM (303 w, 4 d)
Availability
Available
LDAP User
Unknown
MediaWiki User
ArthurPSmith [ Global Accounts ]

Recent Activity

Jun 10 2021

ArthurPSmith added a comment to T284694: Enable "What Links Here" to include ZObject references.

Something like that. Also the link should be removed if all references to one ZObject from another are removed.

Jun 10 2021, 12:14 PM · Patch-For-Review, WikiLambda, Abstract Wikipedia team

Jun 9 2021

ArthurPSmith claimed T284694: Enable "What Links Here" to include ZObject references.
Jun 9 2021, 8:13 PM · Patch-For-Review, WikiLambda, Abstract Wikipedia team
ArthurPSmith created T284694: Enable "What Links Here" to include ZObject references.
Jun 9 2021, 8:13 PM · Patch-For-Review, WikiLambda, Abstract Wikipedia team

Jun 2 2021

ArthurPSmith added a comment to T282020: Add the type string from Z8 Vue code into the PHP side to show below the page title (currently "ZObject: ZObject").

Actually currently it always says "ZObject: Z2" - because it's calling $zobject->getZType() and they are all Z2's at that level.

Jun 2 2021, 8:33 PM · WikiLambda, Abstract Wikipedia team
ArthurPSmith added a comment to T282020: Add the type string from Z8 Vue code into the PHP side to show below the page title (currently "ZObject: ZObject").

If I understand this correctly, the idea is to show the function signature, for example for Z813 ("empty") the Vue code displays "( list: List ): Boolean" - so we want to place that string somewhere near the top of the page under the title...

Jun 2 2021, 3:23 PM · WikiLambda, Abstract Wikipedia team

May 12 2021

ArthurPSmith claimed T282020: Add the type string from Z8 Vue code into the PHP side to show below the page title (currently "ZObject: ZObject").
May 12 2021, 8:32 PM · WikiLambda, Abstract Wikipedia team

Apr 28 2021

ArthurPSmith created T281363: Speed up integration tests.
Apr 28 2021, 1:24 PM · Abstract Wikipedia team

Apr 21 2021

ArthurPSmith closed T278965: Default new ZObject in Create should not require deleting and re-adding Z2K2 key as Resolved.

It's working on notwikilambda! Closing...

Apr 21 2021, 8:39 PM · Abstract Wikipedia team (Phase δ)

Mar 31 2021

ArthurPSmith added a comment to T277077: Z0 should never be stored as a ZID in a ZObject.

Maybe more fundamentally the regex matches should all be adjusted so it's looking for Z[1-9]\d* rather than Z\d+ as a valid Z id?

Mar 31 2021, 7:21 PM · WikiLambda, Abstract Wikipedia team (Phase γ)
ArthurPSmith created T278965: Default new ZObject in Create should not require deleting and re-adding Z2K2 key.
Mar 31 2021, 1:45 PM · Abstract Wikipedia team (Phase δ)

Mar 22 2021

ArthurPSmith added a comment to T278161: Allow case-sensitive or lexical-category-restrictive lexeme search.

Hmm, another strange case is search for L:Kelly - the 3 current matches are for L404650, L361948 and L230178, none of which seem to have the string "kelly" in them. So there's some sort of stemming going on here in addition to the case insensitivity, which would be nice to be able to avoid if possible.

Mar 22 2021, 10:30 PM · Wikidata, Wikidata Lexicographical data
ArthurPSmith created T278162: gloss text entry box is too short and hard to edit.
Mar 22 2021, 6:07 PM · Wikidata Lexicographical data, Wikidata
ArthurPSmith created T278161: Allow case-sensitive or lexical-category-restrictive lexeme search.
Mar 22 2021, 6:03 PM · Wikidata, Wikidata Lexicographical data

Mar 18 2021

ArthurPSmith moved T273221: Measure and indicate Lexeme language completeness, and prompt editors with what more might need doing from Backlog to In progress on the Wikidata-Lexicodays-2021 board.

Denny's posted this notebook: https://public.paws.wmcloud.org/User:DVrandecic_(WMF)/Lexicographic%20coverage.ipynb which does pretty much the above for the language Wikipedia corpora. Results at https://www.wikidata.org/wiki/Wikidata:Lexicographical_coverage
However, I don't think he wants to keep running it, so can we move it somewhere that it will be run regularly by a bot or something? The coverage/completeness data is helpful, and the 'missing' page for each language is a great guide to editors, if it could be kept reasonably up to date.

Mar 18 2021, 2:58 PM · Wikidata-Lexicodays-2021, Wikidata, Epic, Wikidata Lexicographical data
ArthurPSmith added a comment to T277701: Change ZObjectFactory built-in validation to handle optionality.

From the discussion it sounded like we didn't want to (partially) address this by allowing null values for keys (JSON does allow 'null' so it could be done that way, though the UI currently doesn't have a mechanism for entering a null, and further changes would still be needed in ZObjectFactory anyway) - rather the optional key should just be absent from the ZObject. If key had an additional boolean attribute "optional" (itself optional, default false) that would partially address the problem, but not the case where we want exactly 1 of N specific keys to be not null (as for implementation). Eventually each type should have its own in-wiki validator that can take care of all this. There are possibly other mechanisms being considered also. So maybe simplest would be for ZObjectFactory to just treat every key as optional for now?

Mar 18 2021, 1:50 PM · Abstract Wikipedia team (Phase ε), WikiLambda

Mar 17 2021

ArthurPSmith reopened T277067: Z13 and Z501 do not load when running maintenance/update.php as "Open".
Mar 17 2021, 8:01 PM · Abstract Wikipedia team (Phase δ), WikiLambda
ArthurPSmith added a comment to T277067: Z13 and Z501 do not load when running maintenance/update.php .

@Jdforrester-WMF Z501 is now loading, but Z13 still not - you can see this on notwikilambda right now for instance - https://notwikilambda.toolforge.org/wiki/Special:AllPages?from=&to=&namespace=2468

Mar 17 2021, 8:00 PM · Abstract Wikipedia team (Phase δ), WikiLambda
ArthurPSmith added a comment to T276841: Cannot create an instance of Z8/Function.

@Jdforrester-WMF the patch I just uploaded does also fix T276836: Cannot edit Z4/Type - the issue there was indeed the change in normalization. I'm not sure however if my fix for that (denormalizing strings and references in the key validation check) is ideal... but it does seem to work. I added tests that fail without these changes and pass now.

Mar 17 2021, 6:16 PM · Abstract Wikipedia team (Phase γ)
ArthurPSmith added a comment to T276841: Cannot create an instance of Z8/Function.

I'm assuming this is the same issue as T276836: Cannot edit Z4/Type, and that the recent changes to the normalisation code in the front-end API means the operations made clientside are no longer valid?

Mar 17 2021, 3:50 PM · Abstract Wikipedia team (Phase γ)
ArthurPSmith claimed T276841: Cannot create an instance of Z8/Function.
Mar 17 2021, 1:34 PM · Abstract Wikipedia team (Phase γ)
ArthurPSmith added a comment to T276841: Cannot create an instance of Z8/Function.

I see the same problem. Looking into it now!

Mar 17 2021, 1:34 PM · Abstract Wikipedia team (Phase γ)

Mar 10 2021

ArthurPSmith created T277067: Z13 and Z501 do not load when running maintenance/update.php .
Mar 10 2021, 4:59 PM · Abstract Wikipedia team (Phase δ), WikiLambda

Mar 3 2021

ArthurPSmith added a comment to T261465: Z20/Tester type.

Just a note - this has been added to the preloaded ZObjects, but it does not load (missing on notwikilambda.toolforge.org for example) due to the reference to Z7, which does not exist yet. It would probably be helpful to have some indication during the update/load process that loading a particular ZObject like this failed...

Mar 3 2021, 3:55 PM · Abstract Wikipedia team (Phase γ)

Feb 17 2021

ArthurPSmith added a comment to T273567: Adding a key with type Z8 to Z8 lead to a HTTP 500.

After discussion James suggested keeping track of the validation context (basically I think option 4 above) - I'll look into this.

Feb 17 2021, 9:32 PM · Patch-For-Review, Abstract Wikipedia team (Phase γ)

Feb 11 2021

ArthurPSmith added a comment to T273567: Adding a key with type Z8 to Z8 lead to a HTTP 500.

The above patch removes the type registry check (option 3). But maybe another solution would be better in the long run?

Feb 11 2021, 9:43 PM · Patch-For-Review, Abstract Wikipedia team (Phase γ)
ArthurPSmith updated subscribers of T273567: Adding a key with type Z8 to Z8 lead to a HTTP 500.

Ok, I've tracked down the source of the problem... It is indeed an infinite recursion issue, in the validation process.

Feb 11 2021, 7:09 PM · Patch-For-Review, Abstract Wikipedia team (Phase γ)

Feb 10 2021

ArthurPSmith added a comment to T273567: Adding a key with type Z8 to Z8 lead to a HTTP 500.

Note that Z6K1 has value type Z6 and that doesn't cause this problem.

Feb 10 2021, 2:55 PM · Patch-For-Review, Abstract Wikipedia team (Phase γ)
ArthurPSmith claimed T273567: Adding a key with type Z8 to Z8 lead to a HTTP 500.

This is interesting - I'll take a look at it!

Feb 10 2021, 2:53 PM · Patch-For-Review, Abstract Wikipedia team (Phase γ)

Jan 20 2021

ArthurPSmith claimed T266292: Values that are references should display labels.
Jan 20 2021, 9:18 PM · Abstract Wikipedia team (Phase γ), Abstract Wikipedia UX

Jan 14 2021

ArthurPSmith added a comment to T270295: Fix behaviour of SelectZObject component to make it more usable and similar to OOUI component.

Some of my notes on other things the select widget should do that it doesn't do right now...:

Jan 14 2021, 6:59 PM · Abstract Wikipedia team (Phase β), Abstract Wikipedia UX
ArthurPSmith closed T269192: Rewrite the type selector, a subtask of T270295: Fix behaviour of SelectZObject component to make it more usable and similar to OOUI component, as Resolved.
Jan 14 2021, 6:54 PM · Abstract Wikipedia team (Phase β), Abstract Wikipedia UX
ArthurPSmith closed T269192: Rewrite the type selector as Resolved.

TypeSelector has been replaced by SelectZobject, so this can close!

Jan 14 2021, 6:54 PM · Abstract Wikipedia team (Phase β), Abstract Wikipedia UX
ArthurPSmith closed T264828: Get list of types and their keys from wiki, including labels in requested language, a subtask of T266267: Prefill keys when adding an object, as Resolved.
Jan 14 2021, 6:52 PM · Abstract Wikipedia UX, Abstract Wikipedia team (Phase γ)
ArthurPSmith closed T264828: Get list of types and their keys from wiki, including labels in requested language as Resolved.

I think we're done here now? Thanks for all the help guys!

Jan 14 2021, 6:52 PM · Patch-For-Review, Abstract Wikipedia UX, Abstract Wikipedia team (Phase β)
ArthurPSmith added a comment to T264828: Get list of types and their keys from wiki, including labels in requested language.

which was fixed in a patch. All this now deployed!

Jan 14 2021, 5:00 PM · Patch-For-Review, Abstract Wikipedia UX, Abstract Wikipedia team (Phase β)
ArthurPSmith added a comment to T264828: Get list of types and their keys from wiki, including labels in requested language.

See also https://gerrit.wikimedia.org/r/c/mediawiki/extensions/WikiLambda/+/656176 which removes the remaining dependencies on the hard-coded types list except for the following:

this.keylabel = editingData.ztypes.Z3;

in OtherKeys.vue.

Jan 14 2021, 3:03 PM · Patch-For-Review, Abstract Wikipedia UX, Abstract Wikipedia team (Phase β)

Jan 12 2021

ArthurPSmith closed T270299: Fix two-way binding on the OtherKeys component as Resolved.

Marking as resolved then, thanks!

Jan 12 2021, 3:42 PM · Abstract Wikipedia team (Phase β), Abstract Wikipedia UX
ArthurPSmith added a comment to T270299: Fix two-way binding on the OtherKeys component.

@gengh does this problem seem fixed now?

Jan 12 2021, 2:47 PM · Abstract Wikipedia team (Phase β), Abstract Wikipedia UX

Jan 7 2021

ArthurPSmith added a comment to T270299: Fix two-way binding on the OtherKeys component.

Ok, I think the amended commit in gerrit now fixes this issue. I looked into the question of why the "otherkeydata" was used, and the problem is the way this component is designed we need something that has all the keys in zobject EXCEPT the Z1 and Z2 keys which are handled in the FullZobject component. If we decide that's unnecessary then we can look into replacing it simply with zobject in this component. Another alternative is maybe to create a computed object which is zobject minus those specific key-value pairs.

Jan 7 2021, 9:28 PM · Abstract Wikipedia team (Phase β), Abstract Wikipedia UX
ArthurPSmith added a comment to T270299: Fix two-way binding on the OtherKeys component.

Able to reproduce now, thanks! It seems to be specific to string values? Not quite sure what's going on; as to why having two different objects representing the same structure; it's probably from the evolution of my thinking about how to do this and learning how vue works. I'll see if I can make the change as you imply, I guess using the zobject value directly?

Jan 7 2021, 6:10 PM · Abstract Wikipedia team (Phase β), Abstract Wikipedia UX

Jan 6 2021

ArthurPSmith added a comment to T270299: Fix two-way binding on the OtherKeys component.

Above change doesn't address the main question here.

Jan 6 2021, 8:40 PM · Abstract Wikipedia team (Phase β), Abstract Wikipedia UX
ArthurPSmith added a comment to T270299: Fix two-way binding on the OtherKeys component.

Oh yeah, I had noticed this was broken and wasn't sure the cause... This gives me a clue on the cause but I'm not sure how to fix. Will think a bit about it but feel free to propose a specific solution!

Jan 6 2021, 7:56 PM · Abstract Wikipedia team (Phase β), Abstract Wikipedia UX

Jan 5 2021

ArthurPSmith closed T271181: persistent toolforge 502/503 errors as Resolved.

Things still seem to be working properly and at least the 5xx errors have disappeared, so i think we can say this is resolved now. It would be nice to know what caused it though!

Jan 5 2021, 7:06 PM · Toolforge
ArthurPSmith added a comment to T271181: persistent toolforge 502/503 errors.

@Kizule and @dcaro - thanks for checking. Yes, the problem appears to have gone away now (8:52 AM EST). But the 11 min load @dcaro saw sounds like a real problem - the examples come from a simple Wikidata Query Service query and it does nothing with them other than list them as links, so there's no way they cause trouble. I'm still wondering why there seem to be a large number of 4xx errors shown in grafana for the last day when I see only 3 in the access log on toolforge.

Jan 5 2021, 2:00 PM · Toolforge
ArthurPSmith created T271181: persistent toolforge 502/503 errors.
Jan 5 2021, 1:13 AM · Toolforge

Dec 22 2020

ArthurPSmith added a comment to T270301: Minimize the times OtherKeys component calls wikilambda_fetch; create a global state manager?.

@gengh this is great, thanks! I was hoping we'd get vuex pieces some time, definitely needed. I'm a little stalled right now on what I was working on because I need to convert a zid to a label (also a very general problem, but this is needed to remove TypeSelector.vue and the dependency on the hardcoded type list); ok if I look at adding that to your key label support?

Dec 22 2020, 8:13 PM · Abstract Wikipedia team (Phase β), Abstract Wikipedia UX

Nov 18 2020

ArthurPSmith added a comment to T263956: Work out how Lucas was able to save a Z6 as a Z2 and stop it from happening again.

Or just test a json array directly - it gets entered (because it is a valid zobject) but causes trouble because it's not a valid *persistent* zobject:

var api = new mw.Api(); var test = api.postWithEditToken({action:'edit',format:'json',title:'ZObject:Z12366', text:'["test", "test2"]', contentformat:'application/json', contentmodel:'zobject'});
Nov 18 2020, 4:52 PM · Abstract Wikipedia team (Phase β)
ArthurPSmith added a comment to T263956: Work out how Lucas was able to save a Z6 as a Z2 and stop it from happening again.

I.e. if you try to save an object that looks like {"Z1K1": "Z10", "Z10K1": ...} that would also fail because it's not in the persistent object format (Z2) but rather a list (Z10) at base. Or any other type that's not Z2.

Nov 18 2020, 4:44 PM · Abstract Wikipedia team (Phase β)
ArthurPSmith added a comment to T263956: Work out how Lucas was able to save a Z6 as a Z2 and stop it from happening again.

hi @Jdforrester-WMF - don't we require the base persistent object always to look like {"Z1K1": "Z2", "Z2K2": (rest of object)} ? Also I'd prefer that the "Z2K1": id key always be defined and match the page name...

Nov 18 2020, 4:42 PM · Abstract Wikipedia team (Phase β)
ArthurPSmith added a comment to T266237: Backend to provide all types (Z4s) defined on the wiki.

Although actually trying to do this, it appears the types listed in the table are not the ZObject id's, but string values - so instead of Z4 you have to query for "ZType". Hmm. That doesn't seem like the right choice long term but I guess we can work with it for now.

Nov 18 2020, 2:51 PM · Abstract Wikipedia team (Phase β)
ArthurPSmith added a comment to T266237: Backend to provide all types (Z4s) defined on the wiki.

So having worked on an autocomplete interaction for the reference type, it seems to me that API (list=wikilambda_searchlabels within the mediawiki query API) could be usefully extended to restrict search results by type; with no query string that could return all ZObjects (up to a limit) of a given type. It already returns id, label combinations for a given language. With type = Z4 that would satisfy this ticket...

Nov 18 2020, 2:06 PM · Abstract Wikipedia team (Phase β)

Oct 12 2020

ArthurPSmith added a comment to T258901: Generic viewer for ZObjects.

Change 633560 in gerrit has this adjustment - I'm not sure how to link it to this ticket though?

Oct 12 2020, 3:52 PM · Patch-For-Review, Abstract Wikipedia team (Phase β)

Oct 8 2020

ArthurPSmith updated subscribers of T265034: Wikilambda API help page broken.
Oct 8 2020, 12:18 PM · Abstract Wikipedia team (Phase β)
ArthurPSmith created T265034: Wikilambda API help page broken.
Oct 8 2020, 12:18 PM · Abstract Wikipedia team (Phase β)

Oct 7 2020

ArthurPSmith added a comment to T258901: Generic viewer for ZObjects.

From stand-up today I'll look at modifying the Vue components to allow a "view" mode as opposed to edit mode.

Oct 7 2020, 8:10 PM · Patch-For-Review, Abstract Wikipedia team (Phase β)
ArthurPSmith claimed T258901: Generic viewer for ZObjects.
Oct 7 2020, 8:09 PM · Patch-For-Review, Abstract Wikipedia team (Phase β)
ArthurPSmith added a comment to T264827: Change the ZObject creation UX so that users are prompted to pick a type, instead of Z2K2 defaulting to a ZString.

I think this should be dealt with by having the default value for Z2K2 be null, not '' (an empty string). Alternatively, just remove the Z2K2 from the default Persistent ZObject.

Oct 7 2020, 1:28 PM · Abstract Wikipedia UX, WikiLambda, Abstract Wikipedia team (Phase δ)
ArthurPSmith added a comment to T263956: Work out how Lucas was able to save a Z6 as a Z2 and stop it from happening again.

Hi Lucas - the problem is a change in the data model so that all stored objects (with a ZID, i.e. a page in the namespace) are of type Z2 - Persistent ZObject. This is assumed by the editing UI, so it was very confused to see a Z6 instead of a Z2 as the stored object. A Z6 (string) should be stored as a Z2 with key Z2K2 being the value (the string itself). So yes, probably best to just delete those two for now.

Oct 7 2020, 1:24 PM · Abstract Wikipedia team (Phase β)

Sep 30 2020

ArthurPSmith added a comment to T258904: Special:CreateZObject.

Just a thought here - I would guess the main difference from the generic ZObject editor for the "Create" process is that there is no page ID yet. Presumably we want to generate the id's automatically - Z3834 followed by Z3835, Z3836, etc. Is there a standard approach to do that reliably? I know Wikidata's had issues with id values for their items (Qxxx...) getting skipped, but at least there doesn't seem to have been any issue with the same ID being generated twice in create. Anyway, whether or not that specific solution is adopted it sounds like that's an extra piece that's different from how normal wiki pages work generally...

Sep 30 2020, 11:51 PM · Patch-For-Review, Abstract Wikipedia team (Phase β)

Sep 23 2020

ArthurPSmith added a comment to T262447: Initial Vue implementation for ZObject editing.

@santhosh there are a few places where English words are used that should be i18n messages - do you know how this should work with Vue in Mediawiki? Is there a good example out there now?

Sep 23 2020, 2:32 PM · Abstract Wikipedia team (Phase β)
ArthurPSmith added a comment to T262447: Initial Vue implementation for ZObject editing.

Latest patchset (19) removes the Object.entries and destructuring bit; really this wasn't needed and if we're sticking with ES5 then it should go.

Sep 23 2020, 2:06 PM · Abstract Wikipedia team (Phase β)
ArthurPSmith added a comment to T262447: Initial Vue implementation for ZObject editing.

and another patchset to fix eslint complaints...

Sep 23 2020, 1:33 AM · Abstract Wikipedia team (Phase β)
ArthurPSmith added a comment to T262447: Initial Vue implementation for ZObject editing.

Patchset 15 fixes the issue with creating new ZObjects! However, it also unintentionally altered the package-lock.json file; I'm not quite sure what happened to change that...

Sep 23 2020, 1:03 AM · Abstract Wikipedia team (Phase β)

Sep 22 2020

ArthurPSmith added a comment to T262447: Initial Vue implementation for ZObject editing.

Patchset 11: call makeEmptyContent if ZObject is new

Sep 22 2020, 5:35 PM · Abstract Wikipedia team (Phase β)
ArthurPSmith added a comment to T262447: Initial Vue implementation for ZObject editing.

And patchset 10 - this was using an API to fetch the labels of keys in the old implementation; obviously that's not available (yet) here, and we might prefer a different solution anyway. So I stripped that out.

Sep 22 2020, 3:19 PM · Abstract Wikipedia team (Phase β)
ArthurPSmith added a comment to T262447: Initial Vue implementation for ZObject editing.

Re-pull from gerrit worked (I think). I've uploaded patchset 9 - basically I've abandoned the special handling for labels as too much has changed there from the old implementation, and it all sort of works (more crudely) with the OtherKeys implementation anyway. No language drop-down any more though... I would have had to completely rewrite those two components.
However, I'm thinking the longer term solution here is to write special components like those for each ZObject type, which will allow special things like the language handling. I sort of have special handling now for lists (Z10) and strings (Z6), though only because those are built in to the representation.

Sep 22 2020, 3:11 PM · Abstract Wikipedia team (Phase β)
ArthurPSmith added a comment to T262447: Initial Vue implementation for ZObject editing.

Hmm, thanks for fixing those things. However, now I'm not sure how to submit my further changes - I get the following message after doing a merge with your changes and then trying 'git review -R':

Sep 22 2020, 2:48 PM · Abstract Wikipedia team (Phase β)
ArthurPSmith added a comment to T262447: Initial Vue implementation for ZObject editing.

2 more patches to fix up ES5 vs ES6 issues (mostly const/let -> var) in the javascript, and also to address npm test and SonarQube complaints.

Sep 22 2020, 1:24 PM · Abstract Wikipedia team (Phase β)

Sep 18 2020

ArthurPSmith added a comment to T262447: Initial Vue implementation for ZObject editing.

And just added another patch to fix the types and labels list (temporarily - these should really come from the data itself somehow).

Sep 18 2020, 2:16 PM · Abstract Wikipedia team (Phase β)
ArthurPSmith added a comment to T262447: Initial Vue implementation for ZObject editing.

Not sure what's going on with the language stuff, but it sounds like it might be a local problem on my end. I'll probably reload everything at some point and see if it goes away.

Sep 18 2020, 1:32 PM · Abstract Wikipedia team (Phase β)

Sep 17 2020

ArthurPSmith added a comment to T262447: Initial Vue implementation for ZObject editing.

Yeah, this is a choice I made for now to make things simpler in the model handling, but also to be closer to how MediaWiki does things. The display values and accepted short-codes are available from LanguageNameUtils, thusly:

Sep 17 2020, 1:35 PM · Abstract Wikipedia team (Phase β)

Sep 16 2020

ArthurPSmith added a comment to T262447: Initial Vue implementation for ZObject editing.

very rough version (it displays stuff but I don't think any edit functionality is working yet) in gerrit - in progress! https://gerrit.wikimedia.org/r/c/mediawiki/extensions/WikiLambda/+/627887
:

Sep 16 2020, 5:35 PM · Abstract Wikipedia team (Phase β)
ArthurPSmith added a comment to T263000: Decide on modelling for a type for natural languages (for ZMonoLingualString, etc.).

For a reference on the (exceptionally large) number of ways that Wikidata is currently handling languages, see Lea's draft table here:
https://www.wikidata.org/wiki/User:Lea_Lacroix_(WMDE)/List_of_lists_of_languages

Sep 16 2020, 1:11 PM · Abstract Wikipedia team (Phase δ)

Sep 15 2020

ArthurPSmith added a comment to T262447: Initial Vue implementation for ZObject editing.

This is moving along, but I'm noticing that currently there are some significant differences - in particular in language handling and I'm not sure how to proceed. The old 'abstracttext' had a list of languages that were themselves ZObjects - of type Z180 (language). This allowed having both the short code ('en') and a full label ('English', 'Anglais', etc.) in whatever the chosen current language was. I guess for now I'll just use and display the short codes and allow entry of whatever code they want rather than having a drop-down of languages, but maybe longer term we would want a different choice here?

Sep 15 2020, 3:22 PM · Abstract Wikipedia team (Phase β)

Sep 9 2020

ArthurPSmith added a comment to T262447: Initial Vue implementation for ZObject editing.

From the standup meeting today, I'm going to try working on this over the next week or two. However, I had a basic question on how to proceed. I'll do it on its own branch for now, so merging shouldn't be an issue right away. The question: in google/abstracttext I implemented this as a separate "new edit" button, but I think it would be better to just replace the regular "edit" page for the ZObject namespace. Any strong opinions on this? This is going to be pretty experimental to start with, so of course we can change things drastically here!

Sep 9 2020, 5:33 PM · Abstract Wikipedia team (Phase β)
ArthurPSmith added a subtask for T258903: Generic editor for ZObjects: T262447: Initial Vue implementation for ZObject editing.
Sep 9 2020, 5:27 PM · Abstract Wikipedia team (Phase β)
ArthurPSmith added a parent task for T262447: Initial Vue implementation for ZObject editing: T258903: Generic editor for ZObjects.
Sep 9 2020, 5:27 PM · Abstract Wikipedia team (Phase β)
ArthurPSmith created T262447: Initial Vue implementation for ZObject editing.
Sep 9 2020, 5:25 PM · Abstract Wikipedia team (Phase β)

Sep 8 2020

ArthurPSmith added a comment to T260315: Create a file containing the core types to upload to wiki.

We chose to not risk split-brain issues with the title of the object stored in both MW's metadata and also inside the object in the Z2K1 key, so we splice in the value ...

But that value is kind of critical as an identifier within and between ZObjects - the prefix for related keys for types at least, and of course the value of any references. It means they don't make sense without the MW metadata.

Sep 8 2020, 1:06 PM · Abstract Wikipedia team (Phase β)

Sep 7 2020

ArthurPSmith added a comment to T260315: Create a file containing the core types to upload to wiki.
Sep 7 2020, 2:42 PM · Abstract Wikipedia team (Phase β)
ArthurPSmith added a comment to T260315: Create a file containing the core types to upload to wiki.

I was thinking about this - if we want a single file, why not make it a ZObject itself, i.e. a JSON formatted list (Z10) of these Persistent ZObjects? It will need some sort of script like the main MediaWiki maintenance/importTextFiles.php to run I assume...

Sep 7 2020, 2:10 PM · Abstract Wikipedia team (Phase β)

Sep 4 2020

ArthurPSmith added a comment to T260314: Hardcode certain inalienable truths.

This sounds like protection levels? I.e. some things editable by anyone, some only by confirmed users, some only by admins, or other levels. However, you want it granular so that labels can be at a different protection level from other keys. Wikidata has desired something similar, to allow granular protection of some statements while allowing others within the same item to be editable by anyone. Anyway, would using standard Mediawiki protection procedures work for this for now?

Sep 4 2020, 5:54 PM · Abstract Wikipedia team (Phase θ)
ArthurPSmith added a comment to T258904: Special:CreateZObject.

Is this the right design page: https://meta.wikimedia.org/wiki/Abstract_Wikipedia/Early_mockups#Create_an_object ?
I guess my question is whether the create page should be separated from the edit page (Special:CreateZObject as outlined in the approach here) or just go to a generic edit page which can do everything... ??

Sep 4 2020, 4:17 PM · Patch-For-Review, Abstract Wikipedia team (Phase β)
ArthurPSmith added a comment to T258904: Special:CreateZObject.

I notice this is (so far) being implemented as a plain form with ooui - I think this is fine, though it limits what you can initially create. But Wikidata's create item is similarly limited to just the label, description and aliases in a given language. So I would suggest this should also be limited to the Z1 keys (type, label and description in a single language), with the id (Z1K2) auto-generated. Maybe I should check out the "designs" - I'm assuming the metawiki pages? (Edit: I just realized that the current design has Z2 - persistent Zobject - replacing most of the Z1 keys, so the id and labels come from Z2 now - anyway the same point stands that the initial creation of the object maybe could only use these required keys for a persistent ZObject.)

Sep 4 2020, 4:05 PM · Patch-For-Review, Abstract Wikipedia team (Phase β)

Jul 30 2020

ArthurPSmith added a member for Abstract Wikipedia team: ArthurPSmith.
Jul 30 2020, 2:53 PM

Jul 21 2020

ArthurPSmith added a comment to T243701: Wikidata maxlag repeatedly over 5s since Jan 20, 2020 (primarily caused by the query service).

Something seems to be going on very recently that's a different pattern - did something change on the infrastructure side, or is there a change in usage pattern for the last few hours? Basically maxlag (WDQS lag specifically) has NOT gone below 5 (5 minutes for WDQS) for more than 1 hour. This hasn't happened, as far as I can tell, for many days, perhaps weeks or months. Typically maxlag recovers when bots stop editing after about 20-30 minutes, sometimes it takes almost an hour, but this is the longest delay in a long time. Specifically around 2020-07-21 14:04 the lag went over 5, and as of 15:18 it's grown to over 16.
(editing) finally at 15:35 it's coming down again (down to about 12 now).

Jul 21 2020, 3:19 PM · Wikidata-Campsite, Traffic, SRE, Performance Issue, Discovery, Wikidata-Query-Service, Wikidata

Jul 20 2020

ArthurPSmith added a comment to T242081: Pywikibot fails to access Wikidata due to high maxlag lately.

The purpose of checking maxlag is to slow the rate of EDITS to Wikidata. I don't understand why Pywikibot is using it as a reason not to READ data. There are surely a vast number of other applications out there that read from Wikidata (and query WDQS) without checking maxlag!

Jul 20 2020, 7:58 PM · Patch-For-Review, Upstream, Pywikibot, Pywikibot-tests

Jun 23 2020

ArthurPSmith added a comment to T255587: Vue should not use loadHTML.

Ah, I just noted on T253334 - I don't think RemexHtml is the right solution either - Vue templates also are not really html, as they include "elements" not in the HTML standard, and parsers may not handle them correctly. I ran into this just now using wmf/1.35.0-wmf.38 which has the RemexHtml parser, where I have an html table that has some of its rows provided by another Vue component:

Jun 23 2020, 8:51 PM · MW-1.35-notes (1.35.0-wmf.38; 2020-06-23), Vue.js, Performance-Team, MediaWiki-ResourceLoader
ArthurPSmith added a comment to T253334: Vue ResourceLoader support: JavaScript in script elements parsed as HTML leading to parsing error.

I don't think this problem was resolved correctly. What looks like HTML in templates is ALSO not really HTML. In particular, the current ResourceLoader does not handle <table>'s correctly when there is an internal component in the table, something like:

<table><tbody> <tr><th>header...</th></tr> <internal-tr-component ...></internal-tr-component> </tbody></table>

The current parsing is pulling out the "internal-tr-component" as a separate element outside of the table. This is wrong - templates should be left alone! I think an XML parser that doesn't understand HTML at all might be best for this?

Jun 23 2020, 8:41 PM · Performance-Team (Radar), MediaWiki-ResourceLoader, Vue.js

Jun 2 2020

ArthurPSmith committed rTPTAB48de3f961cc5: Fix for changed behavior of iter() and dicts (ordering is based on insertion… (authored by ArthurPSmith).
Fix for changed behavior of iter() and dicts (ordering is based on insertion…
Jun 2 2020, 11:21 PM
ArthurPSmith added a member for Tool-Wikidata-Periodic-Table: ArthurPSmith.
Jun 2 2020, 12:12 PM

Apr 8 2020

ArthurPSmith added a comment to T249687: gadget to add external ID as reference.

Thanks for creating this! I'm not sure what the standard citation reference for an external ID is, but what I've been using is:

  • stated in (P248) the value of "subject item of this property" (P1629) for that external ID property, if any
  • external ID property with value from the item
  • retrieved (P813) on the current date.

So it would be nice if this gadget could add these three (or 2 if no P1629 value) statements as a reference with a simple interaction...

Apr 8 2020, 4:12 PM · Wikidata-Gadgets, patch-welcome, Wikidata

Mar 18 2020

ArthurPSmith placed T112140: Provide a wrapper function in pywikibot around wbparsevalue up for grabs.

Unassigning, I'm not working on this any more!

Mar 18 2020, 4:13 PM · Patch-Needs-Improvement, Pywikibot, Pywikibot-Wikidata
ArthurPSmith closed T160205: Add interstitial to wikidata-externalid-url as Declined.

Wow, was that really almost 3 years ago. There doesn't seem to really be a need for this, so I'm closing the request as declined.

Mar 18 2020, 4:09 PM · Tools, Wikidata
ArthurPSmith closed T160205: Add interstitial to wikidata-externalid-url, a subtask of T150939: Replace https://tools.wmflabs.org/wikidata-externalid-url by providing improved handling for external id formatter urls, as Declined.
Mar 18 2020, 4:09 PM · MediaWiki-extensions-WikibaseRepository, Wikidata

Feb 14 2020

ArthurPSmith added a comment to T119226: Very small (or very large) quantity values (represented in scientific notation) result in error in add/update via pywikibot/wikidata API.

Sorry I never got around to looking at this further. @DD063520 do you understand the above comment from @thiemowmde about using the wbparsevalue api rather than python internals?

Feb 14 2020, 1:53 PM · Pywikibot, Pywikibot-Wikidata, Wikidata

Feb 12 2020

ArthurPSmith added a comment to T243701: Wikidata maxlag repeatedly over 5s since Jan 20, 2020 (primarily caused by the query service).

@Bugreporter

I think increase the factor will not make thing better, it only increase the oscillating period

Feb 12 2020, 10:01 PM · Wikidata-Campsite, Traffic, SRE, Performance Issue, Discovery, Wikidata-Query-Service, Wikidata

Feb 11 2020

ArthurPSmith added a comment to T238045: Improve parallelism in WDQS updater.

Possibly relevant comment here: I believe there is a plan also to move to incremental updates (updating only the statements/triples that have changed) so it is probably important that any parallelism in updating be coordinated so that updates for the same item (Q value) be grouped together and done in the same process, so they don't clobber one another. Updates for separate items (different Q values) can be handled in parallel as the associated RDF triples are independent (the subject of a triple is always the item, a statement on the item, or a further node derived from the item). Even without that incremental update process, grouping updates on the same item together could be a significant speed boost, as 5 updates for Q9999 can be collapsed into just the last update under the current procedure of completely rewriting the triples.

Feb 11 2020, 7:45 PM · Discovery-Search (Current work), Wikidata-Query-Service, Wikidata

Feb 7 2020

ArthurPSmith added a comment to T243701: Wikidata maxlag repeatedly over 5s since Jan 20, 2020 (primarily caused by the query service).

Over the past weeks, we noticed a huge increase of content in Wikidata. Maybe that's something worth looking at?

Wikidata content is growing at a fast and steady pace and has been for a few years now. For the last few months it's been expanding at a rate of around 3,500,000 new pages per month. So that seems unlikely to be connected.

Feb 7 2020, 1:34 AM · Wikidata-Campsite, Traffic, SRE, Performance Issue, Discovery, Wikidata-Query-Service, Wikidata

Feb 4 2020

ArthurPSmith added a comment to T243701: Wikidata maxlag repeatedly over 5s since Jan 20, 2020 (primarily caused by the query service).

@Addshore and others - the problem has deteriorated since Saturday - see this discussion on Wikidata: https://www.wikidata.org/wiki/Wikidata:Contact_the_development_team/Query_Service_and_search#WDQS_lag

Feb 4 2020, 4:47 PM · Wikidata-Campsite, Traffic, SRE, Performance Issue, Discovery, Wikidata-Query-Service, Wikidata