That all makes sense to me, happy with the way these are assessed

Thanks so much, just went through and put in my comments in the sheet.

This is a feature of the language fallback

That's good from me. Thanks so much!

Thanks for bumping this, I'll look into where we can bring this in but it would likely be in the new year.

It's working for me now too

Yes that's correct. I will update this to make sure we include qualifiers and references across desktop and mobile

This is a duplicate of: T426667

I would agree with the recommendation to go with @size-1600
@Alice.moutinho what do you think?

OK then let's make it work with the coordinates at the top as specified in the design. The approach would be an engineering decision; I would say whichever is simplest.

Can you take a screenshot of the proposal so that we can see it?

@Alice.moutinho Although it looks not as good, it replicates what we have on desktop and it is much more work to make it work that the visual difference it will make for now. We can look into it in the future

Yes, I am happy with that decision here

Yes that solution works for me here

This is not so pressing that we need to create a POC, especially for this release. Would it be possible to revert the previous change that created this issue and go back to the previous layout of map -> coordinates?

Thanks for highlighting that, I created a ticket for that here: T439735: [BLZMI] Create a guide for Query Service users to help migrate their queries from Blazegraph to QLever

Could we please update it to the text that I had, I think explaining the backends is more than people need to know / adds confusion.

Happy with the new suggested text, and tagging @Alice.moutinho for the colour of the banner, I would say something in the orange colour range? Red is too alarming and green is too positive.

Good to note here we don't have this page to summarise your changes and won't need anything here. The hCaptcha will

Thanks so much for the background on this. I would agree, with your points here if that is the WMF recommendation.

Pending clarification

That sounds good to me

Does anyone else have a screenshot we can look at?

Story writing notes:
Use the documentation here to determine which value inputs should be changed to LTR in the RTL UI:
https://doc.wikimedia.org/codex/latest/style-guide/bidirectionality.html#phone-numbers

From story writing:

Notes from story writing:
We should be using the component from codex:
https://doc.wikimedia.org/codex/latest/components/demos/accordion.html

This is covered in: T429286

Alice and I have spoken and decided that the behaviour should be:
only ever one message, new messages dismiss previous messages, and all messages stay for max 3 seconds

Looks good to me, thanks so much

Thank you so much!

@jhsoby and @Amire80 how does this look to you?

Not sure I can check this I receive Unauthorized User-Agent error

Is there somewhere I can check this that is live?

Not sure if it's because of this, but the floating add statement button no longer appears

Looks good to me thank you

covered in T430046: [MEX2] Find better ways to indicate reference blocks

I also just made an edit on https://test.wikipedia.org and there was no hCaptcha.

With which user and editing interface?

What is the current timeline you are envisioning for us to implement this on Wikidata?

Thanks so much for the responses. There are a number of tools that are important for contributions on Wikidata, but cannot display hCaptcha. Some of the tools that would be affected are:
https://iw.toolforge.org/quickstatements
https://meta.wikimedia.org/wiki/QuickStatements_3.0
https://openrefine.org/
https://lexica-tool.toolforge.org/

If the issue is that the banner stays on the screen for 3 seconds. We should remove any previous banners each time a new banner appears, as they no longer apply to the current action the editor has taken.