Since the creation of the ticket according to Moore's law the available resources on client and server site should have been increased by a sufficient factor to double the limits.

I also mentioned this behavior and always find it really strange when getting such suggestions.

@MGA73 which bot does that?

There is a workaround we described in https://github.com/Khan/pygments-server/issues/1. It uses a HTTP server to handle the requests.

@dcausse we got everything runing now by setting in the Localsettings.php:

$wgShellLocale = "C.UTF-8"
setlocale(LC_NUMERIC, "C");

This was also the solution for T181987. The troubleshooting just took as a while because we did not disable the MW chaching so that such parameter changes had no immediate effect.

This problem still exist for the latest LTS of MW/extension. I wrote a comment https://www.mediawiki.org/wiki/Topic:Vw4yfp0viknw4ree before i found this ticket. As already mentioned the reason for the slow rendering is that for each code block a separate python process is needed. I wonder if the code could be rewritten in a way that only a single conversion could be performed by merging the input of all blocks before calling the converting only once.

For the current 1.35 we experienced the same problem as in the original description above. At the same time, we have a very similar locale-related issue with Cirrussearch which should have been solved already (T189877).
We are currently experimenting with the suggested workarounds. But anyway, it would be desirable to have a general solution for all these locale-related problems.

Is this issue really solved? In MW 1.35 with the latest Cirrussearch and Elastica extensions we experience the very same error in CirrusSearch error log:

@Paladox we found the same problem and increased the wgSVGMetadataCutoff to really big values without success. But interestingly we get a new error instead:

I did/do not see any successful Petscan query for days. Always getting a: 504 Gateway Time-out.

Is there any workaround?

Just as an information, it istill not fixed on Commons:
https://commons.wikimedia.org/w/index.php?title=User_talk:Aschroet&diff=360277621&oldid=359912218
https://commons.wikimedia.org/w/index.php?title=User_talk:Aschroet&diff=361175442&oldid=360665676

@Jdlrobson , seems you are right. Interesingly, i am logged in. When i go to the Wikipage i see this by the menu on the left side. But following the Commons link, i get the message "Central login
You are centrally logged in. Reload the page to apply your user settings." But the reload does not help with it. So it seems to be a problem with the central login on Commons.

At least this limitation should be mentioned in the API description.

@Esanders, before opening another bug, i'd like to ask if this bug here could also be the reason why external links without names are not displayed in Wikipedia Android App.

Just a statement: When making Wikidata as a central hub for data it should at least guaranteed that the observation of changes are properly displayed. That is why I would recommend to work on this issue

@Billinghurst, maybe you are right . Could you please help me with https://www.mediawiki.org/wiki/Manual_talk:Pywikibot/delete.py#Pages_are_not_deleted_but_template_delete_is_added.

After T154225 has been resolved i could import the mentioned page.

@Billinghurst, for me it is not clear what the suggested change causes. Could you please tell me what will be different for the "normal user"?

@TTO without all revisions it does not work as well. I get the same error message.

Around a year ago i create T89703 according to the missing nearby feature. It is somehow a duplicate of this ticket. Just from experience i learnt that it is very hard to discuss and motivate local admins in the different wikis to work on required changes to that the coordinates are properly exposed. Only in Armenian Wikipedia i reached that goal with help of a use i know very well. That is the reason why i gave up and proposed the following four approaches to tackle the problem :

Thank you for the quick bugfix. How can i find out when this is in production?

An example that there is still an issue:

I can confirm this problem:

I applied the patch and it worked for me.

Thank you @josephine_l.

@josephine_l, i did not see any wrong location template in files uploaded by this app over a long time. I would suggest to close the ticket.

Thank you for the quick fix.

@josephine_l, it is no big thing. Just wanted that you are aware of it. Other version number i did not check yet.

@josephine_l, i know that this is off-topic but could you please tell me why i find lots of older uploads with
{{Uploaded from Mobile|platform=Android|version=1.31}} , as for example: https://commons.wikimedia.org/wiki/File:Pepper_robot_programming_workshop.jpg. I am not aware of the history of development of the app but is there some inconsistent version numbering? I expected to find only new uploads after your last release by doing this search: https://commons.wikimedia.org/w/index.php?title=Special:Search&profile=advanced&profile=advanced&fulltext=Search&search=insource%3A%22version\%3D1.31%22+hastemplate%3AUploaded_from_Mobile&ns0=1&ns6=1&ns9=1&ns12=1&ns14=1&ns100=1&ns106=1.

@josephine_l, for me this looks good. However, it was just a guess what i described. I did not reproduce this behavior on my phone. So it is up to you to decide if this fix is going productive.

@josephine_l , can it be that the (0,0) is the assumed user location? As i see in GPSExtractor.java the double values of currentLatitude and currentLongitude are not initialized, resulting in a "0.0" if they were not updated by MyLocationListener before the photo is uploaded. If the app is configured to use the user location the (0,0) appears in the upload.

(0,0) is a valid value for a location. However, it is very unlikely to have such a photo since it would be located somewhere in the Atlantic ocean on the west coast of Africa. In any case, for me it is unclear where the value is taken from because it is not in the photo.

I am not aware if this is a new issue are if it was already in place when i described the main one with "NaN". However, there are several uploads with the app containing {{Location|0.0|0.0}} which is abviously not correct, e. g.:

• https://commons.wikimedia.org/wiki/File:Smouha_Sporting_Club.jpg (version 1.30)
• https://commons.wikimedia.org/wiki/File:Winter_Melon_Flower_2.jpg (version 1.28).

@josephine_l , it is clear. However, i see the used app version in the "Uploaded from Mobile" template. I will only complain here when the problems occurs again with >=1.30.

@josephine_l , thank you for the very quick fix. I am permanently observing the maintenance category https://commons.wikimedia.org/wiki/Category:Media_with_erroneous_locations. As long as i do not comment here you can assume that everything is fine.

In mobile view it seems to work now. For Wikipedia App on Android it is still the same.

@valhallasw, from T115261 i know that you are able to start/stop this tool on the server. Could please restart Crosswatch. Maybe this issue here can be solved so. Thank you in advance.

I think so.

@bearND, i think that Florian just saw this issue in his Android app when he created the ticket. And since he and me are not familiar with the software and the projects here we just did not know know what project is the one the issue needs to go. So feel free to change this.

@Dbrant, @MBinder_WMF: i updated the task description after isolating the original problem. Now it is much simpler and the solution seems to be pretty clear. Maybe you could quickly browse over it.

Sorry for being a little late and commenting in a closed ticket. I browsed the comments and did not get how i could determined and automatically repair problematic pages. I'd like to do that for dewikisource. Or is this already done for all wikisources? Thanks...

I experience the same now on dewikisource now.

@Bawolff, we applied the fix which solved the initial issue. Thank you. According to the CSS vulnerabilities, let us know if you need support from our side.

1) Directly related to the mentioned problem i see a growing number of files appearing in this maintenance category: https://commons.wikimedia.org/wiki/Category:Media_with_erroneous_locations. Especially over the last weeks it seems that a lot of participants of WLE 2016 are uploading files with broking location templates because they fill in coordinates in non-decimal format.

@Zdzislaw: Merci.

Thank you a lot for the fast help.

@Tpt, do you have any idea about this behavior?

Why does that still happen? E. g. https://commons.wikimedia.org/w/index.php?title=File:SI_badges_-_progressive_scheme.jpg&action=edit

Up again