Yes, definitely we'll be able to keep the imagemap functionality of linking nodes to pages. The only user-facing breaking change would be that it'd no longer be possible to generate a graph on one page and then refer to that graph on another page via normal wiki syntax e.g. [[File:GraphViz digraph example1 dot.png]] but I suspect that's not a very common thing to do.

Does anyone think it might be a good idea to get rid of the uploading of GraphViz images as wiki files?

@Tpt I've added you to this testing account as well.

Tool is installed and seems to be working fine:

I've created wsexport-test and added tools.community-tech-tools as a maintainer.

It may be that it's failing to match /wptestblog2/es/ to the es site, and is instead finding the first match on the default site, because it's comparing the incoming request path with the various configured paths of the different sites and not taking into account the trailing slash properly (so either they should all have a trailing slash, or not; I'm not sure which).

This is failing in the code that reorders the text elements in a switch statement so that sublocales are at the top and fallback entries are at the bottom. Why do we do this? It seems unnecessary, but it might have something to do with errors in rsvg's handling of variants/fallbacks and so higher ones get preferred. Anyway, we weren't testing for language codes given with underscores vs hyphens — the latter is I think the standard, so I've added support for them here (and left in the underscore checking because they're also used sometimes). Ideally we'd normalize these values, but I think the above patch makes sense anyway.

I'm getting this error with the above file:

What language do SVGs (that have 'simple' in a contentLanguage) render in on Simple Wikipedia? I think if they can be displayed correctly there, then they should be able to be translated.

This is merged and ready for QA on the staging site.

PR for saving translations: https://github.com/wikimedia/svgtranslate/pull/104 (WIP)

I've just released 0.8.0, containing code relating to this task.

I've just released 0.8.0, containing code relating to this task.

I've just released 0.8.0, containing code relating to this task.

I've just released 0.8.0, containing code relating to this task.

I've just released 0.8.0, containing code relating to this task.

I've just released 0.8.0, containing code relating to this task.

The above test files are all working correctly now. I wonder if disabling output buffering has fixed this problem as well. That sort of makes sense.

We can't easily detect that the font isn't installed, but we can check for the five fallback families: "serif", "sans-serif", "cursive", "fantasy", and "monospace". One of those is supposed to always be the last term in a font-family specification.

PR: https://github.com/wikimedia/svgtranslate/pull/103

PR for the message fix: https://github.com/wikimedia/eventmetrics/pull/286

I'm not currently able to find another example of this issue. Maybe the culprit was the Nginx proxy after all. If anyone finds another broken image please send this back to the in-development column.

This seems to have been a result of T216209.

PR: https://github.com/wikimedia/svgtranslate/pull/101

The language list is now in the right order on the staging site.

https://github.com/wikimedia/eventmetrics/pull/285 updates the bundle with the new ordering.

This file only specified font-family:Arial in the text elements, so I added a serif fallback font family (font-family:Arial serif), and the file now renders correctly: https://tools.wmflabs.org/svgtranslate-test/File:Mosquito_gender_ml.svg

I'd thought that perhaps this was because we were rendering the PNG and then writing it to a file via PHP, so I made https://github.com/wikimedia/svgtranslate/pull/99 that uses shell-level redirection to do the same thing. Doesn't fix the problem though (still, it does feel a bit faster in my testing, so maybe it's worth doing anyway).

I was wrong. The templatedata is still not being returned by the API when the TemplateWizard test is run. It works locally, and when I set $wgJobRunRate = 1; it fails with the same error that's occurring in CI.

This seems to be an issue with the job queue, and if we load the test template's page before doing anything else then the templatedata is populated correctly and the rest of the tests pass.

Thanks. I've signed up.

I'm keen to help! I don't think the changes on the svgtranslate side sound huge.

The first part of this is to sort them in the right order in the bundle: https://github.com/wikimedia/ToolforgeBundle/pull/19 (I suspect we actually meant to do it this way originally).

Here's a fix for that message: https://github.com/wikimedia/eventmetrics/pull/278

This appears to be an error in the timezone list on our web server, specifically with ACST. :-(

Merged. Ready for QA.

Patch merged.

PR now ready for review: https://github.com/wikimedia/svgtranslate/pull/96

Patch has been merged.

Last (hopefully!) PR: https://github.com/wikimedia/eventmetrics/pull/276