In T277028#7066317, @lilients_WMDE wrote:

The ticket description above specifies different wording for the window title and for heading over the search bar (when inserting a new template). Currently they seem to use the same local:

I guess we should add a new local to allow different wordings.

It seems this didn't happen for a while now. Will close the ticket for now. Please re-open if you run into this again.

Scheduled for Monday 1pm window
https://wikitech.wikimedia.org/w/index.php?title=Deployments&type=revision&diff=1911170&oldid=1911139

You're welcome. :-)

Seems to be fixed with the patch above, although I don't completely understand why.

Note: Broken since ~26./27. of April

Backport scheduled for today 1pm
https://wikitech.wikimedia.org/w/index.php?title=Deployments&type=revision&diff=1910480&oldid=1910476

Fix works well for the image. There's still some misplacement with the text maybe it's equally easy to fix. See the images below.

Note: If you're a logged in user, the cogwheel from page previews will get you to the preferences page as expected. There you can see both check boxes with the normal the settings. I'm not sure if there should be an extra hint for reference previews working differently on mobile. I guess it's fine. Users on mobile should be used to the behavior with little popups when interacting with references.

In T281235#7038815, @gerritbot wrote:

Change 682819 had a related patch set uploaded (by WMDE-Fisch; author: Thiemo Kreuz (WMDE)):

[mediawiki/extensions/Popups@wmf/1.37.0-wmf.3] Separate reference preview settings in beta & non-beta

https://gerrit.wikimedia.org/r/682819

In T273426#7037539, @WMDE-Fisch wrote:

In T273426#7037435, @awight wrote:

More importantly, IMHO we still need to specify the fallback behavior for browsers without Grade A support.

Do Grade C browsers even get the VisualEditor?

In T273426#7037435, @awight wrote:

More importantly, IMHO we still need to specify the fallback behavior for browsers without Grade A support.

Backport scheduled for Monday 1pm window so we're save that the fix is present even when the train gets stuck.

We might want to backport the potential patch to be sure it's there when released on the 29th.

In T273425#7023568, @awight wrote:

With the latest patches:

Looks great to me!

A small question though, the gap above "Add more information" is 50px and it feels like a bit much.

I have 36px above each parameter name, but maybe this is exaggerated because my param names are in lowercase.

While applying the new namespaces there were some conflicts with pages already existing.

id=268848 ns=0 dbk=VP:Dərinlik -> Vikipediya:BROKENDərinlik (alternate)
id=617000 ns=0 dbk=VP:EƏ -> Vikipediya:BROKENEƏ (alternate)
id=279385 ns=0 dbk=VP:OTRS -> Vikipediya:BROKENOTRS (alternate)
id=11229 ns=0 dbk=VP:Qısayol -> Vikipediya:BROKENQısayol (alternate)
id=323633 ns=0 dbk=VP:Seçilmiş_məqalə_namizədləri -> Vikipediya:BROKENSeçilmiş_məqalə_namizədləri (alternate)
id=323631 ns=0 dbk=VP:Yaxşı_məqalə_namizədləri -> Vikipediya:BROKENYaxşı_məqalə_namizədləri (alternate)

They got renamed and should probably be moved.

We could use Example instead of e.g.. I this still an open question?

Backport scheduled for Monday 1pm https://wikitech.wikimedia.org/w/index.php?title=Deployments&type=revision&diff=1908197&oldid=1908185

In T277271#6908431, @Esanders wrote:

This was fixed in https://gerrit.wikimedia.org/r/670833

Seems to loose focus each time the tags change. When removing/editing a tag using Backspace the focus is lost as soon as the tag is broken up.

On the OOUI demo pages the TagMultiselectWidget seems to work fine. So it's probably just an issue of the custom class. Most likely triggered by https://gerrit.wikimedia.org/r/c/oojs/ui/+/668488

Seems like something happened between OOUI v0.41.2 and OOUI v0.41.1 that did the break the behavior. Advanced-Search inherits TagMultiselectWidget to create a new widget for adding multiple words or group of words in the search field. When hitting Enter there, the input field loses focus in v0.41.2

Already started looking into this ... seems to be a regression in OOjs

@DannyS712 are you currently working on a fix? Otherwise I would.

In T193130#6884094, @Sahilgrewalhere wrote:

hey! @MichaelSchoenitzer_WMDE Can You Please provide me the necessary links for the extensions/files related to this task?

I tested the current version of the patch by @thiemowmde and it already improves a lot. Still there's some minor regression and probably also some details we might want to discuss. See my examples below.

In T270926#6887393, @Esanders wrote:

In T270926#6882747, @WMDE-Fisch wrote:

Thanks for the heads up. I just ran into this. I'll overwrite it with another rule just aiming for the matched brackets. I could also imagine that this is reasonable, since there will be only two bold characters at once in a text due to bracket matching.

The problem is that any amount of misalignment can cause text wrapping to change, which breaks text editing in really bad way. If there is any chance the surfaces being out by even 1px we should not do it.

In T270926#6878819, @Esanders wrote:

Requirements
...
font-weight: bold;

Note that font weight is always reset to normal in 2017WTE, as due to the way we line up the edit surface and the highlight surface, we don't want to risk misalignment by changing the font weight (T184467, T199740). It's fine to use bold here, just be aware of this limitation when QAing.

Thanks for the feedback!

Scheduled for tomorrow 1pm
https://wikitech.wikimedia.org/w/index.php?title=Deployments&type=revision&diff=1901569&oldid=1901517

The gadget's code sits here [1]

Just added the recommendation to use templates for the implementation of the classes.

We got a valid concern from @Amire80 on the patch.