Just to update this ticket:

Leaving breadcrumbs:
Looks like the MobileFront end team have been poking this area not too long ago: https://gerrit.wikimedia.org/r/c/mediawiki/extensions/MobileFrontend/+/482233

This is the desired status based on the statement I've got from Product Management.

👍 Awesome!

I just wanted to check we have a common understanding of what adding these languages "to the list of language codes supported for Lexemes." means:
You can see on beta that the merged patch means e.g. rm-surmiran can be used as a code for: lemmas, forms and glosses.

From the screenshot and my testing looks like the request is blocked by CORS and then the the response is blocked by CORB.

1 line fix at https://github.com/wmde/wikibase-docker/pull/80

https://gerrit.wikimedia.org/r/c/wikibase/termbox/+/504240 shows that perhaps a way towards solving the bug is trying to delay the removeAlias action (and thus the reactive update) until after the focus has happened.

In T219499#5108586, @sarhan.alaa wrote:

Wow in minutes .. it took a query on wb_terms >5 minutes to get 50 results only. Same on Query Service. How did you find those?

Adding to camp since I guess fixing is in this realm

I took the "blue" from the mocks (#36c) and I assumed it was supposed to reflect accent50.
@Hanna_Petruschat_WMDE is that right?

So, my suggested approach to this is:

• have a mixin that:
  • creates a data field focusIn
  • has 2 methods that change that field true/false
• mix this mixin into LabelEdit and DescriptionEdit
• wire up @focusIn and @focusOut to the mixin methods
• optionally add wb-ui-focus-in-input class to TermTextField based on focusIn field value
• add new focussedTermInput scss mixin with blue border
• add scss mixin to wb-ui-focus-in-input

This appears to be solved by the fix for https://phabricator.wikimedia.org/T220379#5097045 :)

@Pablo-WMDE @Jakob_WMDE I heard on IRC that you found performance problems with using spread and replace on the entity mutations. Is that the case? If so I guess we need to use Vue.set but otherwise I think we might want to use spread for consistency, readability lack of dark-arts etc..

Moving back to To Do because it looks like debugging is probably going to need some thought about: T220375 first to be effective. Also want to merge the results of T220379 just in case there is some connection.

In attempting to debug this I built the development version with docker-compose run -e NODE_ENV=development --rm node ./node_modules/.bin/vue-cli-service build

In T210293#5094226, @Michael wrote:

In T210293#5094201, @Tarrow wrote:

I don't know loads about this but I wanted to ask if this need could be met by our existing support with -x-. E.g. could you use rm-x-Q688873 for rm-rumgr?

Could you elaborate on that functionality? It doesn't seem to work out of the box on my development setup:

Or is this something that has to be configured for allowed languages?

I don't know loads about this but I wanted to ask if this need could be met by our existing support with -x-. E.g. could you use rm-x-Q688873 for rm-rumgr?

Just to help with reviewing: as part of this task we had to make sure that people won't leak their IP addresses; this can be "product tested" as follows:

In order to give this a product test you could try something like the following:

• log into beta wikidata
• open a page with the new term box
• duplicate the tab
• in one tab log out
• in the other tab enter edit mode
• make an edit and click save
• check that there is now no edit in that entity's history

In our "storytime" type slot I think we said the following.

I tried manually editing the test Dockerfile generated by blubber to run npm ci rather than`npm install`. I was thinking that this might then result in a test failure but this was not the case.

Looks probably fixed. Waiting to see https://gerrit.wikimedia.org/r/c/mediawiki/extensions/Wikibase/+/500856 go in as a confirmation

Thanks for finding and fixing this.

My suggested thoughts on implementing this:

• Add username to the USER store module
• Add actions and mutations for setting username in store
• set username

I'm taking a look at this from the WMDE side. Thanks both of you for digging into this.

also IMHO this is not an extra story or anything. This is just part of implementing the save request

I think we do.

From Mattermost: according to @Addshore WikiPageEntityStore is the place to look for hints as to the existing logic

I took a little look at this and I'm not feeling super clear on what the acceptance criteria are. My immediate thoughts would be that baseRevId not equalling the latest id shouldn't immediately result in a conflict.

This seems to me to be done in wikibase/termbox but we are still waiting on updating the pin. This is blocked by diffusion / gerrit sadness. See: T218780

You can see an example of this story working at: https://wikidata.beta.wmflabs.org/w/index.php?title=Q515700&oldid=1101978&useformat=mobile

In the daily today we talked about:

wbeditentity for saving and will not generate custom edit summaries. This will result in generic "Changed an Item" summaries for every save.