Thu, Jul 11
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 something with coordinates from Wikidata, but it seems to fail for this specific use case.
Wed, Jul 10
Hisotry 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).
Sat, Jul 6
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.
Mar 13 2019
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
Jan 3 2019
Dec 21 2018
It seems that Gressholmen now displays as the surrounding bay area object has been edited to exclude it. However as per natural=bay wiki page it isn't required to exclude islands. I still see quite some missing islands overlapping bay areas (w648202691, r9048910) around Estonia.
Dec 11 2018
Regretfully I can reproduce this. To trigger page blanking filter on Commons (filter 4) you need an account that has less than 200 edits and that isn't in "autopatrol" user group. It seems to be triggered because first revision is empty. I don't know if this is FileImporter's problem or rather a problem of this particular filter. Displaying raw HTML of course is another issue.
Dec 5 2018
Dec 4 2018
So, if I import a file then log will say that I uploaded a file, eventhough particular file versions will be attributed to other users? I wonder why is that.
Dec 1 2018
It's a beta feature. Have you enabled it in your preferences?
It displayed a message saying that meta.wikimedia config page "does not contain enough info about <Information>". So I copied the missing information section from en.wikipedia config page. It should be working now.
Nov 29 2018
Is new type of import that would allow filtering imports where file versions were imported along with page revisions in import log also planned?
If there's already going to be an import log entry then isn't the change tag kind of redundant?
Nov 23 2018
Nov 21 2018
Seems to be the same as T195318. 'zh-cn' falls back to 'zh-hans' which in turn doesn't fall back to anything. Since South Korea label node (249399362) doesn't have 'name:<lang>' key for neither code then 'name' key value (Korean name) or maybe no name label at all should be used, but instead name in some unexpected language is used, in this case Romansh name ('name:rm' key value).
Nov 20 2018
Nov 17 2018
Guyana label displays now and French Guiana label is not supposed to display per T181805#4610263. So it seems that in its current form this task can be closed.
Nov 14 2018
This particular file (Modarres Expressway, Tehran 20110912.JPG) doesn't appear in Special:ListFiles because "Include old versions of files" is unchecked.
Nov 11 2018
Nov 9 2018
Nov 8 2018
Nov 7 2018
Thank you. Looks good on wikis that use alphabetic and alphabetic_revised sorting orders.
Oct 30 2018
T158919 seems to be related. Will that task also solve this task here?'
Oct 29 2018
Oct 9 2018
I find a mail conversation about similar issue in WIWOSM and code (introduced soon after this conversation) that does something with relations that osm2pgsql misses. I've little understanding of this, but can you do something similar here?
Oct 4 2018
If I'm not mistaken this was introduced in T138154. Based on that task it's unclear to me if or to what extent it was necessary to apply these generalization algorithms. Appropriate generalization largely depends on scale and the way data is used. Current one doesn't look fitting to me. Could someone please evaluate if it can be dropped or what would be better parameters for it. Maybe you can adjust it to generalize lines to lesser degree for greater scale (smaller zoom level)? Or, if it relates to significant performance issue, then maybe you can rather limit the number of objects or the size of data that can be retrieved at a time?