Another observation. It seems that it's some sort of random bug?

I can't recreate the problem:

I thought this is a common problem (or design?) for all Mediawiki page on mobile phones? Viewing desktop version of Wikipedia on a mobile phone also shows bigger article content font size (see image). I'm not sure if this page should be treated separately?

On the time when _keyboardShortcut is called, the CodeMirror-hints is already closed and removed, so we cannot use that way to check if a code hint is displayed.

Is the clone API inside https://secure.phabricator.com/conduit/ or simply git clone?

Mentioning at corresponding UI elements sound like a good idea. Currently the "execute query" already have a shortcut hint:

I wrote one on my blog in Chinese: https://www.arefly.com/google-code-in-2017-wikimedia/ ☺️ (hope Google Translation works well!)

I changed the "Tools" from a dropdown item to a button. The design will be more consistent and also can work better on small screens.

The result view's dropdown should be working too.

(Click to view this GIF)

So we are trying to make the drop-down menu become something like this drop-down menu right?

https://gerrit.wikimedia.org/r/#/c/402039/

We can remove search.png too after T184070: Add "This page requires JavaScript" notes to special pages in the Translate extension :)

We have to remove the .png reference from the .less/.css files right?

Perhaps we could do something like:

@Ryan10145 can you try and see if https://stackoverflow.com/a/15645088/2603230 works first? If no, perhaps the pywikibot.comms.http is not behaving the same way as requests and we'll need to look into that.

I think if the user don't specify the -revision we will assume that the revision is latest and find out the latest date from the site. See T183667#3864150 for details.

I assume that with

Added R to jump to query result and Arrow Up/Arrow Down to select item in query result

Updated. Should be all working now :)

Ctrl/Command+Enter: Run query
Esc: Leave current input field/textarea
Alt+F: Click "Fliter" button in Query Helper
Alt+S: Click "Show" button in Query Helper
Alt+L: Click "Limit" button in Query Helper
Alt+D: Clear query
Alt+R: Restore previous query
?: Toggle Help menu
E: Show examples
F: Focus on "Fliter" button in Query Helper
S: Focus on "Show" button in Query Helper
~: Focus on query textarea
L: Show language menu

to be a better layout for accessibility? So that the user lands on textarea, then uses tab to go through the Query Helper, and finally goes to Run button.

Just tested. We are currently able to use alt+tab to

In T173213#3772104, @Florian wrote:

Was already imported as: https://codein.withgoogle.com/dashboard/tasks/4880480144982016/

With the title: "Keyboard accessibility for Query.Wikidata.org" and the request to add keyboard-accessibility to the index.html file. However, @Jonas do you want to mention, which keys should trigger what function? :)

Can the maxretries parameters load from config2.py in default? (Though 15 retries in default would be too many...)

In T183670#3860753, @Framawiki wrote:

Note that all filenames in the list are in the date format, so latest will ne to be converted.

The two parts can actually combine to:

It seems that using [[ https://www.mediawiki.org/wiki/API:Edit | redirect: true ]] in Edit API in MobileFronted's TalkSectionOverlay solve the problem.

Is the main problem in skins/MinervaNeue/resources/skins.minerva.talk/init.js or other file?

I would suggest first request for comments at https://zh.wikipedia.org/wiki/Wikipedia:互助客棧/其他 in Chinese Wikipedia.

Is there any way we could use phan in MediaWiki-Vagrant which still runs PHP 5?

In T183016#3847447, @jayvdb wrote:

I suggest using https://www.mediawiki.org/wiki/Manual:Pywikibot/PAWS for this. Less complicated.

One implementation is to perform file locking on whichever is being downloaded on, and exit with an error if the will-be-written file is locked. Another is to avoid same-filenames entirely.

In T183675#3860177, @zhuyifei1999 wrote:

(clarification: by iff I meant if and only if)

We have to do task T183666: download_dump.py: Use response.iter_content first as we cannot implement progress bar without using iter_content.

It seems that file like enwiki-latest-abstract.xml does not have a md5 code in https://dumps.wikimedia.org/enwiki/latest/enwiki-latest-md5sums.txt. How can we check those files?

Would timezone settings on bot user's computer be a problem to this?

If we are to use an external library, does that mean we have to add this library to requirements.txt?

I would suggest something like https://stackoverflow.com/a/15645088/2603230. (See also: https://github.com/wikimedia/pywikibot/blob/master/pywikibot/page.py#L2686-L2693)

I guess there should be a simpler solution (without having to modify replaceCategoryInPlace in textlib)?

Pull request merged.

Pull request here: https://github.com/benapetr/wikimedia-bot/pull/71

I guess we might have to wait till margin-start got supported by major browsers to solve it?

Just curious, @Xqt suggests here in another patch that [[ https://doc.wikimedia.org/pywikibot/_modules/pywikibot/comms/http.html | pywikibot.comms.http ]] could be used instead of requests. Would pywikibot.comms.http be better here too?

By the way, currently Wikipedia already has the expected output because of Tidy (https://www.w3.org/People/Raggett/tidy/). But I think this patch is still needed for general Mediawiki sites.

Note that according to https://en.wikipedia.org/wiki/Wikipedia:Manual_of_Style#Section_headings

Second is it really necessary to use these affected textlib methods for template removements which breaks the script? A single C:\pwb\GIT\core>pwb.py replace -regex "\[\[Kategorie\:Antifaschist\]\]\r?\n" ""-cat:Antifaschist does the job too. This means category.py should be able always to do the job. In my sample the cosmetic_changes didn't care for replace.py. This is a bit curious.

According to the error message

Is this script something like https://github.com/WikiTeam/wikiteam/blob/master/wikipediadownloader.py?