I've updated the staging site.

But it's not ready yet.

rsvg-convert is also a requirement for T211637: Render image previews via RSVG.

Is the grey colour @wmui-color-base30? In the screenshot it looks like it's #7f7f7f but that's not in the Wikimedia base stylesheet.

Actually, we were fixing different things.

Oh oops, sorry @Tpt I didn't see you'd already made a patch for this. :)

Staging site updated: https://tools.wmflabs.org/svgtranslate-test/

If we want to use the same functionality as in ProofreadPage (e.g. click, scroll, and pane this image), it has the jquery.prpZoom module. Although, there's a million other libraries out there that do similar things.

@jmatazzoni confirmed that this is just for pageviews for Wikipedias, not Commons and not Wikidata.

Do the pageviews for pages created and improved also include Wikidata items and Commons uploads? I assume they do.

Merged.

This will also include setting up Docker to use the Wikimedia fork of RSVG won't it? But apart from that, I don't suppose svgtranslate's use of rsvg will require anything specific (i.e. if people are developing locally and not with Docker, they can use whatever rsvg their package manager gives them).

That's T210872, and I think it's big enough to stand on its own.

@Mooeypoo the bug I said I thought I'd found with the above patch is T211619 and is a separate issue. This patch is ready for review after all. Thanks!

@ErrantX do you have any update on this?

All done and merged. Staging site updated: https://tools.wmflabs.org/svgtranslate-test

This was due to invalid Index URLs being entered. I've changed it to validate the URLs when the contest is saved.

Centred it is.

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

It's because all 47 other languages are only partially translated. Try with e.g. https://tools.wmflabs.org/svgtranslate-test/File:Anatomy%20of%20the%20Human%20Ear.svg

Much better, thanks! Is there a way to equalize the widths of the two? The To looks much wider than From.

I've snuck the image-display part into the patch for T206712. It's only one line.

Yes! Looks like things are working again. Thanks @EBernhardson.

No, this really does seem to be flakey. Sorry! It looks like the TemplateData is not being retrieved (sometimes?) for the newly-created test template. Could that be because the job queue is not being cleared before then? Or something else...

PR merged.

The location of the coverage file wasn't set, and there were a few coverage-tag failures. All fixed now, and the patch merged.

Are there other elements other than those two?

I'm seeing a bigger difference in widths - 298 vs 285. The dropdown is wide enough to extend above the input labels which shouldn't happen - see screenshots above by me and Prateek.

It was failing just for fun I think. I rechecked, and all is well. :-( Selenium is odd.

I see that SMW defines its own list of timezones.

I remembered the problem I found yesterday: we're delivering the image as an SVG and leaving it to the browser to render it, and so the clever systemLanguage switch happens in the browser and the displayed language is whatever is set in the browser preferences — and not the current To language in the tool. We can't change the browser's language, so I guess we need to serve up the SVG with either only one language or with the system language strings changed to those of the To language? Or something better and less ugly. :)

The From dropdown is wider than the To dropdown, causing the alignment to break

This is all merged now (including the larger dialog window), and is live on the test site https://tools.wmflabs.org/svgtranslate-test/

The test site is up to date with this change: https://tools.wmflabs.org/svgtranslate-test

Good point. I've updated the above patch to look for the three closing braces as well. Hopefully it's not turning too much into an ugly parser-in-regex. :)

Tagging WMAU as this is currently happening for https://wikimedia.org.au/wiki/Form:Event

Ready for review: https://github.com/wikimedia/svgtranslate/pull/26

Is this task for replacing ULS for all three of its usages in SVG Translate: interface language, preferred languages, and target language?

This seems to be what happens in core's SvgHandler as well.

I agree with both of you. Although, @Prtksxna did you mean to have different strings inside the zh and ja examples?

In T206712#4767161, @Prtksxna wrote:

I just remembered that @Mooeypoo had shared that the tool becomes useless on large screens. I think we should limit the interface width to 1400px (CSS, not device pixels… retina 👀).

The non-HTTPS for http://qrpedia.org seems to still not be working. https://downforeveryoneorjustme.com/qrpedia.org

In T209019#4761518, @ErrantX wrote:

@Samwilson double encoding has been an ongoing issue - I have a suspicion I've fixed it in the past but now the redirection is server-based only and so it's probably failing. Will explore a fix.

Can you open a new issue and assign it to me?

The systemLanguage attribute is allowed to contain multiple language codes, such as in Agua_Caliente_Solar_Project_Electricity_Generation-2017.svg:

No worries! :) Thanks.

It looks like there's some issues with double-encoding in some codes. For example, the centre plaque in
https://commons.wikimedia.org/wiki/File:Toodyaypedia_plates_stg_1_gnangarra_fs-1.jpg
resolves to
http://en.qrwp.org/St_John_the_Baptist_Church,_Toodyay_%25281963-_%2529
instead of
http://en.qrwp.org/St_John_the_Baptist_Church,_Toodyay_%281963-_%29
(i.e. the % was URL-encoded a second time).

@ErrantX it looks like qrwp.org is still not working (both HTTPS and not, and with and without www.). But en.qrwp.org is working for both HTTPS and not (yay! that means lots, but perhaps not all, of the codes are working I think?).

The button can start to look funny maybe, when we add lots of languages there:

It'd look like this (I'm not sure what the button should say):