Mon, Apr 26
Wed, Apr 14
Jan 19 2021
Something interesting: If the size of the mapframe is adjusted, e.g. <mapframe height="200" to <mapframe height="201", then the static map is immediately generated correctly - and undoing causes the worldwide static map to appear again. It would appear the snapshot service is initially fed bad data (perhaps checking for group ids before they have been generated/saved?), and then that bad image is cached for a couple of hours.
Jan 17 2021
Jan 10 2021
This was really starting to annoy me, so I added this code to my global.css on meta to restore the blues.
Here's the diff where @Isarra introduced the purple https://gerrit.wikimedia.org/r/c/mediawiki/skins/Timeless/+/649727/2/resources/screen-common.less (patch set), deployed as part of MediaWiki 1.36.0-wmf.25 a few days ago.
Jan 1 2021
Dec 12 2020
Having checked again just now, 1:27 UTC, the thumbnail is now displayed correctly on both of my sandbox pages linked above.
Dec 11 2020
Nov 29 2020
Aug 25 2020
Aug 3 2020
The portal tool generates, as the name suggests, a portal-style page with links to Wikipedia and other Wikimedia projects, based on what's connected to the relevant Wikidata item. It does detect device language, or you can set the language from the interface, and then the projects in that language will be linked (as well as the interface being translated). Translations/patches/bug-reports welcome, by the way: https://github.com/evad37/wm-portal
Jul 11 2020
Jul 5 2020
Jun 26 2020
Jun 21 2020
Jun 20 2020
The auto zoom/positioning is not currently working for the static map thumbnails on English Wikipedia, see e.g. User:Evad37/Sandbox/Mapframe test
Apr 10 2020
The difference is also really noticeable when enabling/disabling the code editor, e.g. on .css pages, as that is still using the normal 13px font size
Wow, 15.2px is really, unpleasantly, big... in my opinion anyway. For comparison, the font size in this textbox here on phrabricator, and in most other skins (Vector, Monobook, Modern, Cologne Blue) is 13px.
Mar 28 2020
Mar 19 2020
Feb 15 2020
Feb 12 2020
Yeah, if there isn't support for writing a new extension, and it isn't likely to be deployed, and the existing setup works for my needs, then there's not much point of me working on this. It's just a shame that anyone wanting to do some unit testing for scripts has to basically reinvent the wheel each time (unless they happen to stumble upon someone else's solution).
Fixed on enwiki with this diff. Other wikis can make the same edit to fix it, so I'm marking this bug resolved. (The fact that we don't have global templates/modules is another issue...)
Jan 10 2020
@chasemp I'm not sure why you changed this task from a concept review to a readiness review. Should I go ahead and start working on this, or should I wait for further discussion/review of this concept, or is there something else I should be doing?
Dec 25 2019
Dec 18 2019
@sbassett It is related to T71445 and the surrounding issues, but mainly just based on my own experiences of trying to do unit testing for my scripts in a somewhat sane way. I don't have any particular deployment date in mind - maybe sometime next year, I'm not really sure how long it would to take to write an extension, get it reviewed, and resolve whatever concerns arise. There isn't a sponsoring WMF group or person (though I'd be more than happy to collaborate if anyone wants to).
Dec 14 2019
Yes, a security concept review (per mw:Security/SOP/Security Readiness Reviews) for that code -- in the context of it, or substantially similar code, being made into an extension.
Dec 13 2019
Dec 10 2019
Copying what I wrote on T234661
Hi all. I've created w:en:User:Evad37/WikiUnit.js to make on-wiki unit testing of gadgets and scripts a bit easier to implement, and available when previewing or showing changes to code. Ideally this, or something like, it would become an extension. Feedback would be appreciated at https://en.wikipedia.org/wiki/Wikipedia:Interface_administrators%27_noticeboard#Gadget_and_userscript_unit_testing
Nov 18 2019
Nov 17 2019
Nov 15 2019
Given that a user wants to both interact with (or at least see) a page's content, and also interact with a somewhat complicated form/process (i.e. many controls/inputs, e.g. Rater, or in VE adding/editing a template with many parameters), what alternatives are there?
- Unmovable dialog: Forces the user to swicth back-and-forth to another tab/window; or exit the dialog, find what they wanted to find, and go back in
- Docking: Only works if your screen is big enough
- Prepending to (or placing just above) the content area: Causes content to re-position, can't necessarily see both things at once (if scrolling is required), not really suitable if the form/process applies to only one section of the page
- Appending to (or placing just below) the content area: Similar to prepending, but instead content re-positioning existing content, the form/process won't initially be visible on longer pages, unless you force the page to scroll there
I don't think those alternatives are actually better than letting the user move the dialog out of the way.
Nov 12 2019
FYI, I found I could do the draggability easily enough without the library, just using mouse/pointer events directly - diff.
Nov 11 2019
I've implemented draggability for an OOUI process dialog for the latest version of my Rater script, by using a drag-and-drop library and some CSS overrides. It would be nicer if this functionality was directly supported, rather than relying on a library with a bunch of functionality that isn't actually used -- at least for reusers of OOUI, even if WMF devs choose not to use it.
Nov 10 2019
Just now got a self- edit conflict while editing an existing section (this edit):
Nov 3 2019
Aug 4 2019
#1 is T156433: Geoline/geoshape does not work with relations other than multipolygon/route/boundary.
Not sure what's up with #2, that may be another bug.
Aug 3 2019
Jul 30 2019
Previously not specifying latitude/longitude/zoom used default values, which in most cases weren't appropriate, but at least showed a map that could be interacted with. In any case, the current behaviour is not desirable - either a default zoom should be used if latitude and longitude are provided without a specified zoom, or there should be an error message provided.
While the module could be updated to use the new auto positioning feature, this is definitely a bug in Kartographer per the following examples (which just use <mapframe> tag directly, not the module):
Jun 25 2019
Mar 31 2019
Still happening, this time ~475 messages failed to send on enwiki: https://en.wikipedia.org/wiki/Special:Log?type=massmessage&wpdate=2019-03-31&limit=500
Mar 17 2019
The css rule hiding the empty list items is defined in mediawiki core, in mediawiki.skinning/content.css.
Vector, Monobook, and a few other skins add the css via the resource loader module mediawiki.skinning.interface.
Skins which aren't using that module will need to define the rule themselves, like how Minerva has done in its lists.less file.
Feb 24 2019
Update: Per discussion on gerrit, the latest patch sets add a new mw.loader.usingScript(), rather than adding functionality for a separate use case to mw.loader.using.
With the proposed code, to specify a dependency on a external script you would use:
Feb 19 2019
T193312: Clicking on mapframe static map (or maplink link) in apps doesn't launch dynamic map is similar, except without the app crashing
Feb 16 2019
@Tacsipacsi I've made a userscript you can use instead (until or unless Echo is updated to indicate new messages in some other way): https://en.wikipedia.org/wiki/User:Evad37/timeless-newMessageHighlight
Feb 15 2019
I think all that's wanted is a yellow background for the username and icon (or just icon for mobile/tablet views) for when the talk page link also has that yellow background - i.e. something like
so you can tell at a glance (i.e. without opening the dropdown) that one of those notification is a talk page message.
Jan 31 2019
Jan 25 2019
Jan 20 2019
Although it also isn't working for Template:Infobox video game on enwiki, and the latest edit to the template (or rather its /doc subpage) was on 13 Jan, a few days before MediaWiki 1.33/wmf.13 was deployed. Reported at village pump (technical), where the failure means that VisualEditor can't display parameters or descriptions.
From the merged task:
Yeah, looks like its probably another manifestation of the same error
Dec 22 2018
Resolving T181362 fixed a whole lot of scripts/gadgets, which was due to mismatched ids, and the omission rather than hiding of empty portlets.
Nov 11 2018
Sep 20 2018
Sep 13 2018
Sep 12 2018
Sep 11 2018
Note that the help page has been updated (diff), but I'm leaving this open since the configuration setting should probably be mentioned somewhere in https://www.mediawiki.org/wiki/Extension:Kartographer
Sep 8 2018
Sep 4 2018
@CKoerner_WMF Did you get any further information, or should we update the Help page per what you've written above?
Sep 2 2018
Another example from the above merged task:
Aug 31 2018
It's working for me on that page:
Aug 30 2018
Adding Wikimedia-Blog-Content since this is about the licensing of said content.
Aug 29 2018
Noting that I've been able to save .map pages using the api, e.g. https://commons.wikimedia.org/w/index.php?title=Data:Sandbox/Evad37/Highway_192_in_Iowa_(3).map&action=history, just be specifying a Data:_____.map page name, valid JSON (including the licence, source, description fields), and not setting the content model. The pages seem to just get created with the correct content model.
Aug 28 2018
How are the type=route relations handled then? Is there any chance of doing something similar for just for the geoline service for relations that are only made up of lines (e.g. streets which aren't part of a numbered route)?
This still seems like a valid low/lowest priority bug to me, even if it isn't going to be fixed in the near future due to the current management's decision (i.e. it's more of a "not now", rather than "never ever ever", isn't it?)