Thu, Apr 29
T269984 also covers part where static map is generated and cached without JSON overlay (including markers).
Apr 5 2021
Apr 1 2021
Mar 16 2021
Mar 12 2021
Mar 11 2021
That's considerably older than translations of other components that normally go out on next week's train. Before last merge translations were over two months old, as indicated above.
Mar 9 2021
Mar 6 2021
As for just displaying the references list at the bottom of the page without appending it in wikitext, this was done years ago (T68860). As for appending it in wikitext, is this task somehow different from T32763?
Mar 4 2021
I can no longer reproduce. Thank you!
Mar 3 2021
Currently last translations in wmf_deploy are from January 28th, while master branch has 16 l10n commits since then. That's not normal, right? Should L10n-bot commit directly (or backport immediately) to wmf_deploy, or...?
Mar 2 2021
I encountered this in et.wikipedia (fix diff). I don't know how to reproduce, but seems some editor tries to preserve whitespace by turning every second successive space into non-breaking space. Does any MediaWiki editor do that under any circumstance?
Feb 24 2021
Feb 22 2021
Feb 12 2021
... now I added mapframe with geoline to 134 articles, and interestingly correct snapshot image...
I forgot to mention that I used a bot account (pywikibot). Now after having edited/added bunch of other maps, my impression is that correct snapshot is generally available right away after saving if I edit via bot account, and otherwise not. Does this imply anything useful?
Jan 26 2021
Recently I tried to contact an anonymous mobile user about their edits, and now after finding this task I realize it's nearly impossible for that user to get my message, and indeed to most other users it appears that anonymous user just ignores their talk page. The only workarond I can think of is to block given user and make reference to talk page in block reason (though I'm not sure if block reason gets accross either via mobile interface). This is particulary bad even if there was only one anonymous mobile user that doesn't get their messages, and so I also wonder why is this low priority.
Jan 7 2021
Dec 18 2020
I'm not sure if it's useful to point this out here, but now I added mapframe with geoline to 134 articles, and interestingly correct snapshot image, with the geoline object on it, was available right away after saving for all except one – article that was most recently created. For the latter correct snapshot appeared about an hour after saving. Though, Wikidata ID on OSM for it was added along with 10s of other objects that appeared right away on snapshot, and via geoshape service it was also available right away. In past days I had problems with retrieving correct snapshot timely in some other more recently created articles like this one.
Dec 14 2020
Two weeks ago I described similar examples in T268927#6655678, as the issue in that task seemed at least partly the same. Earlier, on November 17 I added maps with geoline/geoshape to nearly 100 Wikipedia articles and then all snapshots (static images) were generated/served correctly right after saving, which also was the case before that date, as far as I can remember. So I'd say this issue has surfaced recently.
Dec 2 2020
There may be some sort of misunderstanding here. To my understanding this extension orders compact links too, as evidenced by recent outage (T257625). Also users can opt out from using compact links.
Nov 30 2020
I also observe that lately it takes hours or days after page save until map content matching dynamic view becomes available on snapshot image. E.g. in this article map was added three days ago and on snapshot I currently still don't see OSM object that is auto-positioned in dynamic view. Or, in this article I observed the same yesterday, while now snapshot highlights the OSM object, but the object has become missing in dynamic view.
Oct 27 2020
Sep 29 2020
Sep 26 2020
For OSM standard tiles anyone can trigger tile refresh by appending /dirty to tile URL (documentation). Couldn't Wikimedia use the same scheme, or for some reason would it be more of a vector of vandalism in Wikimedia's case?
Sep 12 2020
My expectation would also be that messages are configurable on a wiki where they are actually used. Closest example to this functionality that I can think of is sitelink change done on Wikidata in the name of user who moved/deleted local page. Wikidata edit summaries related to these actions are configurable on Wikidata. In FileImporter's case perhaps you could make this functionality intervene with FileExporter that is available on local wikis, and ship messages for these two edit summaries with the latter extension instead?
Aug 3 2020
It seems that icon overflow remains to be an issue, as lately reported on wiki.
Jul 17 2020
I also remember that these numbers were displayed correctly before 2018. Probably this regression was introduced along with map improvements 2018. Perhaps someone who knows how to test older versions of Kartotherian and/or osm-bright style can track down which change exactly is responsible for these malformed number shields?
Jul 9 2020
Jul 2 2020
Jun 26 2020
A few thoughts about general options to track imports. I think ideally the import log could have a field which allows filtering imports by source (maybe by wildcarding interwiki prefixes that are already present in log entries of page imports in order to link to source page). So imports could be found by source via simple interface, and in more reliable manner, without depending on page content that can be changed during/after import.
Jun 8 2020
A possible workaround is to actually "revision delete" the problematic file revisions before triggering the import. I haven't tested this but believe it should work.
Jun 5 2020
So files with invalid versions are expected to be imported manually without preserving file history, even if original author already uploaded fixed version?
May 23 2020
Apr 5 2020
Apr 3 2020
Apr 2 2020
For me map snapshot is missing for certain language variants (zh-cn, ch-my). So mostly it seems the same as T246314. Current differences between how browsers and/or mobile treat missing image is covered in T248722, I think.
Mar 31 2020
Actually I observe the same behaviour (window resize makes JSON overlay/all tiles appear, as in Evad's frameless map example) also when not using autozoom, particularly when map has new/updated (uncached) JSON. There apparently are some difference between browsers (or browser versions) for this behaviour, but for me, until very recently this didn't happen and content for dynamic maps generally loaded well, including when previewing and in Commons/Wikidata that don't use static frames. I don't know if related, but it's also new for me that these improperly initialized frames are collapsed during page load (related to switching to <img>?).
Mar 30 2020
Interestingly resizing a browser window gets JSON overlay object loaded and map centered to it for frameless dynamic map. Similarly, since recently I observe that when using auto-positioning (omit frame coords/zoom), then JSON overlay and some tiles don't appear until after window resize for both frameless and framed dynamic map (at least in some browsers).
Mar 23 2020
Is it known that missing config pages cause significant problems in the first place? If users really are stuck and can't import files, then maybe for a start relevant error message should be expanded by adding further instructions (e.g. link to help page) on how to create a config page.
Mar 20 2020
Mar 19 2020
Now zoom defaults to level 13 again when latitude and longitude are specified.
Mar 18 2020
Mar 17 2020
Mar 13 2020
Mar 12 2020
It's not specific to Malayalam sites. It was reported years ago also for ru.wikipedia and fi.wikipedia (T122241). I can add that there have been similar complaints on et.wikipedia.
Feb 25 2020
Currently this appears to be resolved by an accident (T246071). Could you keep Accept-Language detection enabled for some multilingual wikis like Commons and Wikidata? It seems some work has been done in the meanwhile towards alleviating caching issues (see T203179).
Feb 19 2020
Feb 5 2020
This appears to be be because maplink element currently expects latitude and longitude attributes to be used with zoom attribute, but Wikibase in GlobeCoordinateInlineWikitextKartographerFormatter.php provides latitude and longitude value for maplink without zoom value.
Jan 29 2020
This should be fixed now. See T242517.
Jan 28 2020
@Jdlrobson, do I get this right that "Blocked on Others" means that you are not going to +1 the patch? If so, then who is the "others" that I should request review from before I can arrange a deployment?
Jan 26 2020
Jan 18 2020
I'm closing this as language fallbacks have been adjusted as a workaround, and example given in task description apparently displays in correct language now. Underlying LanguagePicker issues are covered in parent task.
Jan 13 2020
Perhaps it's the same as T214984? These examples on mediawiki.org currently include newlines in SPARQL, which apparently isn't allowed in proper JSON.
Jan 8 2020
Dec 25 2019
Dec 15 2019
Without entering mapframe_lat and mapframe_long in "Infobox park" it takes coordinates from Wikidata. I fixed this on Wikidata.
Dec 14 2019
Nov 18 2019
Oct 31 2019
Oct 22 2019
Oct 15 2019
I doubt if this fix attempt changes anything in regard to validity of this water area.
Oct 8 2019
Do I get this right, to make the following showcase map work without Lua, now there isn't a more readable way than removing all newlines from SPARQL?
Sep 30 2019
Indeed, sorry. I only looked that original report was about edit conflicts and I figured that file imports don't have much to do with signatures. Now I recall that file description pages sometimes do include signatures. :)
Sep 27 2019
Sep 25 2019
Sep 20 2019
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?
Sep 18 2019
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?
Sep 17 2019
Sep 14 2019
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.
Sep 12 2019
Sep 11 2019
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.
Sep 9 2019
Sep 8 2019
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.