I didn't notice this recent changeset as I checked the relation earlier. Comparing previous version with current one, it doesn't seem like duplicate segments or nodes were removed, though. I see that two new nodes were created almost in place of deleted ones. Also, while member way segments were altered a little, neither version seems to have duplicate segments. So I doubt if this fix attempt changes anything in regard to validity of this water area. However, previously when some objects were missing I noticed that mere dummy edit (no actual change) to a relation made Wikimedia system to pick up this object. So maybe this fix attempt will have similar effect.
Doesn't seem like water area was broken on OSM as then at least zoom levels 10+ would be expected to have some fixed tiles by now. Lake Victoria (mentioned earlier in T231691#5460894) is also still gone. Is this something like T218097 again?
Wed, Sep 18
And now there are also URLs in source wiki edit summaries (T227358). In addition to edit summaries and log comments on target wiki, those would also benefit from clickable wikilinks. Does that warrant a separate task?
Tue, Sep 17
Sat, Sep 14
This can be considered a long-standing design choice on Wikipedia, rather than a bug. Some alternatives are discussed in T120809. Of which some may be poorer choice cartographically. It probably needs to be discussed on Wikipedia if they want to shift towards more wide-spread use of different kinds of location maps.
Thu, Sep 12
Wed, Sep 11
Update: We haven't seen this error yet.
@awight, do you mean that you can't reproduce this? I still run into an error if I try to to import "Image002.gif" mentioned above. On Grafana this shows up as "duplicateFiles" error. On July 28th, when another user reported this on wiki and when I created this ticket, I see 12 errors of this type recorded.
Mon, Sep 9
Sun, Sep 8
I had the same problem after editing https://et.wikipedia.org/wiki/MediaWiki:Citethispage-content yesterday. Now after about 24 h it finally started to work when visited via sidebar link.
Mon, Sep 2
Looks good to me on beta wiki.
Sun, Sep 1
@Gehel, there's also a lake in Norway waiting for monthly automatic update to reappear in smaller zoom levels (T230511). What are the guidelines on how should users report such issues so that they would get fixed reasonably quickly?
Thu, Aug 29
Tue, Aug 27
Aug 15 2019
Aug 13 2019
Aug 12 2019
Aug 7 2019
I'm closing this as Chinese fallbacks were improved in a pull request. Please reopen if it doesn't work as intended.
Aug 6 2019
Aug 5 2019
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 assessment.
Aug 2 2019
Aug 1 2019
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.
Jul 30 2019
Jul 28 2019
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
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.
May 24 2019
Commit also has "owner" field and I noted that gerritbot provides different owner in this comment.
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
May 21 2019
May 20 2019
May 15 2019
May 14 2019
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.