jQuery,ui dependency is removed.
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
Advanced Search
Apr 1 2017
Mar 22 2017
Excellent! Thanks
Thanks for the great explanation and sorry for overloading the file.
(the weird point of the mentioned query on the previous comment is if you remove just one of the pages from the list or replace it with something else, it works just fine)
Thank you for the kind explanation. I was able to reduce the troublemaking query an user issued to the tool to this which still have database timeout issue:
Mar 21 2017
@Umherirrender: Thanks a lot for your help on this, but can I also know the reason behind this? I have a very specific query something like this:
With more thinking now I believe helm is not very suited for wmflabs.
Mar 20 2017
Mar 17 2017
Mar 15 2017
Mar 14 2017
Mar 13 2017
Mar 12 2017
Mar 11 2017
Excellent, it makes a huge difference for my use.
Mar 8 2017
Feb 26 2017
Feb 11 2017
Jan 15 2017
Jan 8 2017
Jan 5 2017
Dec 23 2016
Dec 22 2016
Dec 20 2016
Nov 26 2016
Oct 12 2016
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).
Oct 1 2016
Fixed on upstream
Aug 13 2016
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.
Aug 11 2016
Jun 11 2016
Apr 28 2016
Apr 11 2016
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.
^ the "clear" button, removed from Webkit with vendor specific CSS but remained on IE.
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 :)
Apr 10 2016
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.
Apr 9 2016
Mar 8 2016
Feb 19 2016
I've moved the test on Test Wikipedia to not confuse Urdu Wikipedia users, so new steps to repro:
- Open https://test.wikipedia.org/wiki/Special:Preferences#mw-prefsection-gadgets and enable "Test mobile only gadget bug" and save
- Open https://test.wikipedia.org/wiki/Main_Page
Feb 18 2016
Thank you. Done :)
Steps to repro:
- Open https://ur.wikipedia.org/wiki/خاص:ترجیحات?uselang=qqx#mw-prefsection-gadgets
- Open Gadgets tab, make sure (gadget-NotoNastaleeq) is NOT checked but check (gadget-NotoNastaleeqMobile) then save gadgets preference.
- Open https://ur.wikipedia.org/wiki/صفحۂ_اول
Feb 16 2016
I just changed it to "wpExtraQueryRedirect" and am open to change to anything you wish.
Feb 9 2016
Looks great. Thank you
Feb 8 2016
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.
Feb 5 2016
Fixed on wmf.12
Feb 1 2016
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.
Jan 31 2016
Jan 30 2016
Jan 29 2016
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.
Jan 28 2016
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.