Fri, May 24
Commit also has "owner" field and I noted that gerritbot provides different owner in this comment.
Thu, May 23
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.
Wed, May 22
Tue, May 21
Mon, May 20
Wed, May 15
Tue, May 14
Mon, May 13
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?
Oct 3 2018
Oct 1 2018
Sep 30 2018
Sep 20 2018
Maybe implement this when there's no external data reference. Otherwise it would be nice if no lat/long would result in external data being auto-centered and auto-zoomed (T187741).
For lang=en or no lang set it currently shows Szeged on maps.wikimedia.org. I tried setting lang= for serveral other languages, with or without any fallbacks shown at fallbacks.json, and no localized name defined at n30453579. They all showed up as "Segedin" ("name:sr-Latn" key value).
Sep 19 2018
Per Commons licensing policy GFDL-only works are still allowed if they were licensed before 15 October 2018. Also, on local projects there are quite some GFDL-only files left that can be dual licensed per relicensing criteria. Having have to change these older GFDL works to use some different 'good template' before moving to Commons and then change back to GFDL on Commons would seem as an unnecessary inconvenience to me. It's also possible to tag new GFDL-only uploads with an additional 'bad template'. Perhaps rather we can let every project decide which way they will configure it if losing files after moving to Commons actually becomes a problem.
This should probably be merged into T187741, or the other way around. This other task has a little more technical details, but it currently doesn't mention that the issue concerns .map page external data as well.
Sep 13 2018
Being able to configure both regional services and default services on wiki (T152971) would be nice.
Sep 11 2018
Sep 2 2018
I fixed this in local module, that set fill for geoline.
Aug 31 2018
Now there are "Topographic" and "Terrain" map services listed. From translator's perspective this makes me wonder, is there a meaningful distinction between the two? Maps under both currently show terrain cartography features like contour lines and hill-shading.
Aug 29 2018
Rather I'm hoping that someone more tech-savvy reviews my request and does the rest.