Some quick and dirty CSS I added to en:User:Evad37/timeless.css

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.

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.

Having checked again just now, 1:27 UTC, the thumbnail is now displayed correctly on both of my sandbox pages linked above.

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

Now its been 5 months since replication was disabled... any updates @MSantos @Mholloway @Gehel ?

The auto zoom/positioning is not currently working for the static map thumbnails on English Wikipedia, see e.g. User:Evad37/Sandbox/Mapframe test

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.

@TheDJ Could this be related to this change to the CSS, deployed this week?

This seems similar to T227402: White screen with red dot shown instead of map when using geoline/geoshape with specified coordinates

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...)

@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?

This is still (or is again?) happening with geolines, for some recently tagged relations. Reported on-wiki here and here.

@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).

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.

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

In T51969#5669037, @John_Broughton wrote:

(b) let's find specific solutions to specific user problems that don't require that approach.

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.

FYI, I found I could do the draggability easily enough without the library, just using mouse/pointer events directly - diff.

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.

Just now got a self- edit conflict while editing an existing section (this edit):

#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.

In T227402#5388976, @Pikne wrote:

I doubt if there is a viable Kartographer/Kartotherian fix to your use case. If centre coordinates are entered (or retrieved from Wikidata) then these coordinates should probably still be respected as centre coordinates and map shouldn't be expected to centre differently.

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):

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

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.

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:

T193312: Clicking on mapframe static map (or maplink link) in apps doesn't launch dynamic map is similar, except without the app crashing

@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

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

Another example: https://en.wikipedia.org/wiki/Special:Log?type=massmessage&wpdate=2019-01-31&limit=200

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

Resolving T181362 fixed a whole lot of scripts/gadgets, which was due to mismatched ids, and the omission rather than hiding of empty portlets.

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

@CKoerner_WMF Did you get any further information, or should we update the Help page per what you've written above?

Another example from the above merged task:

It's working for me on that page:

Adding Wikimedia-Blog-Content since this is about the licensing of said content.

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.

In T156433#4318138, @Pnorman wrote:

The default database osm2pgsql database schema does not do anything with relations other than boundary or multipolygon.

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?)