Excellent, it makes a huge difference for my use.

I hosted Monaco on toolserver and brought a working example with it here https://fa.wikipedia.org/?withJS=MediaWiki:Monaco.js now I like to see if I am able to replace ace with monaco with some gadget code.

I think you can consider using https://github.com/Microsoft/monaco-editor also, it supports right to left languages much better than ace https://github.com/ajaxorg/ace/issues/1429 (which made CodeEditor pretty useless on our wiki).

Fixed on upstream

Honestly, I didn't know that when I filed this bug. If the situation is like that no one is defining any custom RS/RC/deployment/service/pods, putting helm certainly adds no value but if anyone is interested on defining custom definitions, it can be useful thing I believe.

Well I didn't say we can not patch that one also. Yes, that should be reported to them of course. So in conclusion, I am closing this, the specific clear button which is not disabled yet can be followed on T62430.

IE case is interesting and IMO is another reason why we should avoid vendor specific property, mw did some workaround for webkit to not show "clear" button, to save more space on search box I'd guess, but not for IE yet. Even if we apply some workaround for IE now, in case Firefox would do the same thing other vendors did, we should again tweak all our styles on different skins to make a HTML component look like another one.

Since Chrome/Webkit allow us to remove the broken "clear" button, why not just do that globally in RTL instead of removing type="search" from inputs?

IMHO that can be considered a forward hack and won't fix that 1 pixel spacing issue I care more about :)

That task has been asking for assistance from those that use OSX in a RTL environment daily, Could you provide support to them, or know anyone that might be able to assist?

WebKit decided to not change this https://bugs.webkit.org/show_bug.cgi?id=51499#c2 but their platform is also affected so that won't make much difference no matter that someone decides for Chrome if current situation is right or not. IMHO the main question is if we want keep this type="search" but reset its behavior on Chrome with CSS all over on different skins and trig its bidi bugs on Webkit or can we simply use type="text" to not have to do all of this.

I've moved the test on Test Wikipedia to not confuse Urdu Wikipedia users, so new steps to repro:

1. Open https://test.wikipedia.org/wiki/Special:Preferences#mw-prefsection-gadgets and enable "Test mobile only gadget bug" and save
2. Open https://test.wikipedia.org/wiki/Main_Page

Thank you. Done :)

Steps to repro:

1. Open https://ur.wikipedia.org/wiki/خاص:ترجیحات?uselang=qqx#mw-prefsection-gadgets
2. Open Gadgets tab, make sure (gadget-NotoNastaleeq) is NOT checked but check (gadget-NotoNastaleeqMobile) then save gadgets preference.
3. Open https://ur.wikipedia.org/wiki/صفحۂ_اول

I just changed it to "wpExtraQueryRedirect" and am open to change to anything you wish.

Looks great. Thank you

Yes, there was some complains about our local projects and general issue that might happen with a translation service which was not about the specific topic and even not about the Yandex service itself at all which seems resolved with our attention to the brought topics and my explanation about the service.

Fixed on wmf.12

Reza and I were working on same thing and with the fix of T125193 we used hunspell on our tool and actually we no longer need python binding and dictionaries this task had over than that one.

Thank you. Also we've started using it on our tools also and it is working great.

Somehow similar T125193 but not the exactly the same.

This is somehow is in continuation to T123192 but we don't need the python binding installed here and just vanilla hunspell and its headers package which are in widely use on other softwares are needed.

Also we are not intrested on language packs hunspell provides, such as hunspell-fr, as we like to use our own dictionaries here.

The main interest here would be en-fa pair but of course ru-fa or other common languages would be nice also. BTW tg-fa pair is a matured enough AFAIK on apertium so you may consider enabling that also.

BTW we can discuss about the title of proposed parameter, "extraQueryRedirect", as we didn't use it now but going to after the merge.

It is affecting mobile editing on RTL wikis badly on Chromium based browser (Desktop and Android Chrome, not Desktop Safari and iOS Chrome) so should be fixed ASAP.

Thank you :) Actually I was using webservice restart and that probably can explain why I didn't have the file, probably webservice script worth to be fixed in a way that restart would do the same exact thing start is doing.

Yes. Actually I was using a node.js solution before and then converted this to a simple PHP code. So is it going to be okay from now on? That would be very nice :) but still if deleting and then recreating the tool would help more I have no issue on it as the code is easy to setup and if you don't believe so, it is OK this to be closed. Thank you.

I was wondering if it would be possible to use a runtime 3d model and integrating glTF, a new JSON based standard backed by maintainers of OpenGL standard, somehow? https://github.com/KhronosGroup/glTF

Not some super prefect solution, just something that could show abusefilter edit tags would suffice for now IMO.