Thu, Aug 15
Tue, Aug 13
Mon, Aug 12
Wed, Aug 7
I'm closing this as Chinese fallbacks were improved in a pull request. Please reopen if it doesn't work as intended.
Tue, Aug 6
As of today's review of articles with these maps, it's fixed. San Juan is correctly spelled on en.wp . I guess it's been fixed.
Mon, Aug 5
Repeating the object over and over doesn't seem necessary to me and if tech people say it isn't a good idea then I defer to this assesment.
Fri, Aug 2
After Kartographer is fixed this new template can be redirected to Template:Maplink (given the new template will remain compatible with Maplink's parameters).
Thu, Aug 1
That is yet another case where Wikimedia's language picker fails to "latinize" the name. In absence of "name:en" key it could pick the value of the main "name" key from data attached to San Juan label node, but instead it picks "name:sr-Latn" due to "Latn" suffix.
Tue, Jul 30
For the big maps available after clicking the thumbnails, specifying a latitude and longitude only works if a zoom is also specified, otherwise the white background with the red dot is shown.
Sun, Jul 28
Jul 25 2019
Jul 23 2019
Text "Sort by" and separate texts for options that follow ("relevance", "edit date" and "creation date") are a bit inconvenient to translate as I'd like to reverse the order of these texts. May I suggest rewording the first text as "Sort by $1" so that position of the option variable can be adjusted per translation. Or, perpahs, to add further flexibility in translating, full phrase ("Sort by relevance") in single message might be even better.
Jul 19 2019
Now that more specific error messages are exposed to users, it says "Cannot upload SVG files that contain a non-standard DTD declaration.". Currently there doesn't seem to be much else to do with such files than: 1) upload fixed version to source wiki, 2) delete the file, 3) restore only the valid file version, 4) import. Which feels counter-productive as file history will be lost.
Jul 11 2019
That seems to be due to the way template/module is implemented on Wikipedia. The template apparently expects frame-lat, frame-long and zoom parameters to work properly. Template documentation suggests that without these parameters it tries to do something with coordinates from Wikidata, but it seems to fail for this specific use case.
Jul 10 2019
History of the relation of Ios (history viewer) has edit comments like "coastline fixes" and "repaired relations", which suggest that coastline of Ios has been broken on several occasions over the past months. So likely it was broken at the time when Wikimedia updated coastline. If I'm not mistaken coastline is updated less often than other map features, so it may take a while till it gets fixed. Unless someone tries to regenerate the area manually (approach mentioned in T159631).
Jul 6 2019
I wonder if would be possible to still show this warning if all present categories are hidden categories? It seems that this warning message is mostly unused now since all files need to include some good template (a license) that usually has a hidden tracking category on Commons.
Tiny note from translator: comma seems to be misplaced in message "Editing, the source wiki automatically was not possible please follow the instructions above."
Jun 17 2019
Now in contrast, there is a huge invented water body in Sughd, Tajikistan, apparently bordered by rivers. See https://maps.wikimedia.org/#9/39.2312/68.6810.
Jun 13 2019
Jun 11 2019
Wasn't the idea to remove only the "Template" part of the "Information" section? While task description doesn't mention this part, it links to a ticket that covers only this part. With the entire "Information" section gone all imports seem to be blocked currently.
Jun 8 2019
It seems that maplink being used without "zoom" parameter is causing problems, see T225350.
Jun 5 2019
Handling of commons: prefix is not right, here it becomes :et:Project:.
Jun 3 2019
Missing country polygons on dynamic map (page preview) seem to be be related to T218097.
May 29 2019
Administrator might want to delete the file straight away, instead of tagging it as "Now Commons". Also, on English Wikipedia a few exported files are tagged as Keep local, and not as "Now Commons". I think it's good if adding "Now Commons" was easier, but it would be also good if FileImporter would ask for confirmation to tag the source page, or there was another way to skip editing the source wiki.
May 28 2019
Yes, this error message would probably do in case the extension cannot be corrected during import.
File name endings of both SVG files mentioned in this task seem to be correct and intended, but there is apparently something wrong with file content, and both the latest version (first SVG has one version) and older versions are checked. Also, it doesen't seem to be related to abuse filters.
To be sure I'm not misunderstanding: The file extension of this file https://et.wikipedia.org/wiki/Fail:Kilingi_Nomme_suurvapp.png is png, but the detected mime type is gif. Is it the gif that's wrong or the png? If it's the gif, how could a user fix this?
May 24 2019
Commit also has "owner" field and I noted that gerritbot provides different owner in this comment.
is this bug still valid? (nowdays there are checkboxes in many places)
May 23 2019
So, a couple of days ago someone edited the OSM object and now water appears again as tiles get updated. Geometry nor styles related tags weren't changed.
May 22 2019
Is there a workaround we can put in place? See: https://ro.wikipedia.org/wiki/Provincia_Entre_R%C3%ADos
May 21 2019
May 20 2019
May 15 2019
May 14 2019
We figured this is not relevant in the Wikimedia environment, because all our wikis allow the same file types. There is no way a file can show up with an extension that is not allowed on Commons.
May 13 2019
Blacklisting a Wikimedia project doesn't seem right to me as long as Wikimedia Commons is supposed to be a shared file repository for all Wikimedia projects. Also it'd be still possible to move files to Commons, by disallowing FileExporter you'd only impede copying file history properly.
Apr 26 2019
Remarks on my encounter with another abuse filter: filter 69 is set to first warn and then allow/tag the edit. In FileImporter however it doesn't allow the change. If I click "Import" repeatedly then I'm still stuck with the warning. Unlike the current situation, I'd expect that if OTRS template is not changed during the import then the abuse filter is not triggered at all.
Apr 25 2019
I was bold and I arranged a SWAT deploy, instead of waiting another week until this gets fixed on Wikipedias.
Apr 19 2019
Apr 5 2019
Apr 1 2019
Mar 31 2019
Right's description has been changed now (T215131), but this doesn't seem sufficient. I'll update the task description.
Mar 24 2019
This seems to be implemented for snapshots now, e.g. zoom level 17 is used here. Thank you!
I now note that zoom level 13 is also set here in Kartographer as "fallbackZoom". I think it would be better to remove this restriction too.
An observation related to route relations referred in T214350: none of those added in changeset 63573867 seem to be available as a geoline in Wikimedia system, unless individual member ways of a relation also have Wikidata tag. While relations added a few days before (changeset 63385246) and after (changeset 63605916) seem to be all available. I can't spot any differences in OSM tagging, e.g. geometry for r8821308 is not available via geoline, while r8797335 from another changeset is available.
Mar 22 2019
Mar 19 2019
I now ran into another SVG that gives this error:
W3C validator doesn't like the version of this SVG, but I've imported several other SVG-s of the same version successfully.
I don't know, maybe some tiles for some zoom levels are cached somewhere. "China", "Corea dal sid" and "Giapun" are Romansh name variants that should no longer appear on new tiles. Other issues seem to remain, though.
Mar 18 2019
Update: it seems that now after patch by @Mooeypoo has been deployed it no longer displays "South Korea" in Romansh (rm) for "zh-cn". Now it displays Korean name as "zh-cn" doesn't fall back to "zh". "Japan" however is still latinized as "Nippon" (ja_rm) for "zh-cn". Also, "ko-Latn" value is used to latinize "zh-cn", e.g. see "Namp'o" here.
There is a fallback mechanism in place. Relevant fallbacks are described here. The problem seems to be that "zh" and its variants generally fall back to "zh-hans" that is little used on OSM (see taginfo). I assume these fallbacks should be rearranged, as long as Wikimedia maps localization relies on OSM tags.
Mar 13 2019
@Pikne it seems that it is more related to the OSM replication system but I can't replicate this specific object that you suggested (see image below), I will start invetigating this problem and see if there is an issue with that.
Mar 12 2019
This SVG file seems to be invalid. My browser displays its XML tree instead of image, and validator.w3.org is unable to check it.
Mar 4 2019
Feb 20 2019
Feb 18 2019
Feb 8 2019
Geometry nor relevant tags for Lago di Garda OSM object (r8569) doesn't seem to have changed lately. Earlier in relation to another object @MSantos mentioned that there might be a problem with OSM replication system. Lago di Garda polygon doesn't seem to be available via geoshape service either.
Feb 2 2019
Seems to work now. When I tried to display these objects via geoline service some time ago then border between Q44756 and Q44829 had some gaps. Around these gaps, I note that someone fixed a duplicate node for border segment w498585495 a couple of weeks ago. Maybe that was the problem.
Feb 1 2019
I note that link to geoline service in task description still doesn't return coordinates as expected. The same object returns coordinates via geoshape service though. Another object Q22330964 was available via geoline service a few weeks ago and displayed via mapframe, but no longer does, though associated OSM object doesn't seem to have changed. Was that fixed too and is expected to be alright soon, or is that something else?
Jan 22 2019
I've also experienced this over the past days. For instance, if I currently refresh this static snapshot, then occasionally it gives "Bad geojson - unknown type ExternalData" and occasionally it gives an image. Maybe it relates to T198622?
Jan 21 2019
I'm not sure if any of these feedback comments asks for automatic restoring. Village pump comments seem to be about cases where file necessarily wasn't uploaded to local project prior to nominating for deletion on Commons (which is more like T214280).
Now this concerns log comments too.
In relation to always adding information template there is also this import related aspect that source/author info in source wiki is often insufficient. E.g. there are imports like this where uploader/importer likely is the author, but per Commons licensing policy this needs to be stated explicitly. Then empty information template would hopefully encourage user to fill it and provide explicit author/source info.
Jan 14 2019
Suggest holding off on this in favor of T144448 which is mostly done already and live on Beta (and planned for Watchlist later).