@Tgr - Thanks for the info. Fixed it in the template: https://en.wikipedia.org/w/index.php?title=Template:Infobox_writer&diff=prev&oldid=855362428.

BTW, I noticed that some of the old bogus accounts like "Kaldari" (uppercase) and "kaldari2" are now gone (or merged?). Would it be possible to delete or merge my temporary account I made to work around the bug (which also uses rkaldari@wikimedia.org)? No rush, just wanted to ask in case it's easy now. Thanks!

@mmodell: OMG, it works! I can log into my old account and all the history is still there too! Thank you! Thank you!

@Reedy - Any update? Did you want to do a walkthrough with the developer for this one or just look at the code?

@Esanders: I tried benchmarking this again, but got some weird results. On the article United States, the first two times I tried to load it with NWE, I got a timeout error from the editor after 60 seconds: "Error loading data from server". After that, however, loading was smooth and fast: typically about 10 seconds or less. Any idea what may have caused the delays initially? Maybe a missing server-side cache? (It's also possible this was just an issue on my end with my internet connection.)

Regarding things like repositioning text-boxes, changing text size, combining text boxes, etc. my personal opinion is that that sort of work should be done in Inkscape (or other SVG editors), not a translation tool. Modifying positioning data in SVGs can actually be very complicated due to grouped objects, different methods of scaling, etc. It's not like a PNG where you only have to move pixels around. This tool should be for doing one thing and doing it well: translations (especially since everyone on the internet has access to Inkscape for all the other SVG editing tasks).

I'm totally fine with losing all history at this point :)

When I try to load
https://tools.wmflabs.org/grantmetrics-test/images/logo.svg, it gives me a
404.

I guess the obvious follow-up question is what should updatePageTriageQueue.php do with drafts? I guess nothing since even old drafts (that are still drafts) can potentially be re-reviewed.

@SBisson, @Catrope: There's one more loose end I didn't notice until now: We need to update PageTriage/cron/updatePageTriageQueue.php to not automatically remove drafts older than 30 days (regardless of their ptrp_reviewed state). This is a cron script that is run daily in production. I'm reopening this ticket to handle it since it probably needs to be addressed immediately (since the new branch will be cut tomorrow).

@thcipriani, @mmodell: Just to let you know, I would be totally fine with having all my gerrit accounts deleted (and their history, etc.), if it meant I could successfully use gerrit again under the username kaldari (as that's the username I've been using for 8+ years and that everyone knows). I've been locked out of my account for 2 months now, and I know y'all are doing your best to address the problem, but maybe it's time to consider more drastic ideas. Any thoughts on that?

@MusikAnimal - Now you do :)

Looks good to me!

So far, I haven't been able to reproduce either. Pete, could you also try commenting out everything at https://en.wikisource.org/wiki/User:Peteforsyth/common.js except for the OCR script? That should reduce the number of variables.

When we migrate the image scalers to Debian stretch we'll have a refreshed graphics library stack.

@MoritzMuehlenhoff: It looks like the migration of the image scalars to Debian stretch is complete, but this bug is still present and it doesn't look like a refreshed graphics stack was included in the upgrade: https://tools.wmflabs.org/apt-browser/stretch-wikimedia/main/. Now that the migration is complete, could we manually refresh the graphics stack (or at least librsvg and its dependencies)?

Hmm, that's unfortunate. I think @Nettrom would be the best person to answer your question: How important do you think it would be to backfill the missing data? I'm not aware of any current WMF projects that are using page creation metrics (now that ACTRIAL is over). Obviously, it would be a minor problem for NPP folks, but I think they could survive without it.

We can scan wikitext in the database for template tags, right? Could we then cross-reference that with the editor used to make those edits? That is, can we see something like, "Here's an edit that has a template and that edit was made with the wikitext editor, therefore, the template was inserted with template wizard." The problem is if they just type or copy/paste the template tag into the editor. We'd have to have a date filter here to only check edits made after the TemplateWizard was enabled on that wiki.

@Niharika: Hmm, I'm not sure, but somehow we have to get folks to actually do this. The longer we wait, the harder it is to change, e.g. [1], and the more we risk someone leaving the WMF and taking their code with them (as unlikely as that may be). FYI, I've made you an "owner" of the Wikimedia GitHub project, so you should be able to move your repo at least. See https://help.github.com/articles/transferring-a-repository-owned-by-your-personal-account/.

Thanks for your help Dan!!

Given the following factors...

• The translate tool on Tool Forge is already sort of working (but is buggy and uploading is broken)
• Reviving the TranslateSVG extensions is likely to require a good deal of refactoring (it's 7 years old) and may require work on the Translate extension as well (which is complicated)
• We don't have a lot of time to work on this project (basically 3 months until next Wishlist Survey) and are also working on another project simultaneously
• The original Wishlist Survey proposal suggested fixing the tool rather than the extension...

I'm leaning towards working on the Tool Forge tool.

I like Prateek's last one the best! (A COPY 2)

@SBisson - Good point, I didn't think about the icons. Maybe MusikAnimal's idea is better.

That doesn't look good. Maybe we should just put a PNG there instead.

Not sure if you're planning on doing T189839 or not, but if so, you might run into space trouble with other languages like German ("Teilen Sie diese Ergebnisse"). Maybe just "Share" would work better. Sorry to add more bikeshedding :)

While I would be happy to have all of WMF development move off of Gerrit (due mainly to T197083), I don't think that's going to happen any time soon, and certainly not as part of this task. In the meantime, we need to at least get these tools out of people's personal GitHub accounts.

To summarize here...

And I would be happy to confirm anyone that wants to be confirmed on testwiki.

On enwiki, only user listed at [[Wikipedia:WikiProject Articles for creation/Participants]] can use the gadget. This appears to not be in effect on testwiki.

I believe it is in effect on testwiki.

Closing this in favor of T201253 (Special:NewPagesFeed should ignore ptrp_reviewed status for Drafts).

Sounds good to me.

@Esanders: Is that something that could actually be done in a meeting or would a spike be more appropriate?

@aezell - Nice work! Can you do the same for the newly colored version?

@MusikAnimal: Like this?

@aezell - Sorry, didn't mean to lick your cookie! I started on this a long time ago, but never finished it due to other priorities :P I wonder if we could just convert the PNG above to an SVG using one of those online image conversion tools.

Here's a PNG based on Niharika's old design. Still need to make an SVG out of it.

Looks a little close to:

Considering that I've been locked out of Gerrit for over a month now (due to T197083), and the other reasons mentioned by Max, Sam, and MusikAnimal, I'm going to endorse the suggestion of keeping the bot code on GitHub (but moving it under the Wikimedia project). Note that this only applies to this specific bot code. In general, we should continue hosting our MediaWiki-related projects on Gerrit.

@Cirdan: Where does that template definition live?

If you build this feature, be sure to test it with weird edge cases like https://en.wikipedia.org/wiki/Bonnie_and_Clyde and https://en.wikipedia.org/wiki/Thomas_Jefferson.

the word "century" is not compatible with the data model and should not be used anywhere in the user interface.

@Jc3s5h: As I've mentioned before, there are separate tickets for discussing both the century data model problem (T73459) and the use of "century" in the interface (T196674). Please stop spamming this ticket with those discussions. This ticket is purely about how to properly localize the century strings.

Confirmed that this is fixed. Thanks @Anomie, @phuedx, and @pmiazga !

Here's a screenshot of what the SVG Translate Tool Forge tool is supposed to look like (it's mostly broken currently):

If I wasn't going to be flying all day Monday, I would backport and deploy this. I'm honestly tempted to deploy it today even though it's Friday. @phuedx, anyone from your team want to SWAT deploy this on Monday?

May be related to https://gerrit.wikimedia.org/r/#/c/mediawiki/extensions/MultimediaViewer/+/182145/.

My initial thought is that regular requests to set preferences that are already set globally should fail by default, but the pref setting API should return a warning or error informing the requesting software that the preference was not successfully set due to the global preference. The requesting software can then inform the user, override the global pref (via the GlobalPrefs API), or do nothing.

@Framawiki - As a volunteer developer who helps us with our bot code, do you have any preference over whether it lives in Github or Gerrit?

@MMiller_WMF: You can also select "Reviewed cases" in the CopyPatrol interface if you want to comb through the resolved cases manually. I would not recommend trying to determine copyvio status yourself. It sounds easy, but is surprisingly hard.

@thcipriani: Some more information...

@Volker_E: Why do we need to make the full list item clickable? It's clear that the name of the template is a link. Personally, I hate this trend of making areas clickable rather than text or buttons. It makes it impossible to do normal browser functions like copying and pasting text.

This is probably going to be a WONTFIX. In order for Google OCR to work well, it needs to know what language it's reading. (You would be surprised at how bad it is at guessing.) Currently when you click the Google OCR button, it passes the language code for that wiki (under the assumption that most text on that wiki is going to be in the content language. We could add another step where it asks for the language explicitly, but that would needlessly slow down the process for the 99% of cases where the language of the text matches the language of the wiki. One workaround is to use https://tools.wmflabs.org/ws-google-ocr/ in those cases, since it allows you to specify the language of the text.

The lease time for an IP address can be very short, and there are no guarantee the IP address won't be reclaimed. The lease time is typically shorter for more crowded areas. Without knowing the lease time this will still be guesswork, only automated guesswork.

True, but that's the same for Special:Contributions. Regardless of whether you're talking about a single IP address or a range, there is no guarantee that it hasn't been reassigned. I think admins that do range blocks know that. Perhaps it would be worth adding more documentation to https://www.mediawiki.org/wiki/Help:Range_blocks though.

We still need to resolve two open questions around the draftquality model:
On which revision(s) should it be scored: earliest, latest, or all?

Probably latest.

How long should scores be retained? The original intention was to delete them after 30 days, but that is flexible.

We would need the draftquality scores to be retained for at least 90 days (assuming we are only retaining one score per article).

Also, if you read the full notes of the OSI meeting, you'll see that they didn't ultimately reject the WTFPL due to any reasons related to public domain in Europe. They rejected approving it because the license is redundant to an existing approved license, the "Fair License". Both licenses essentially say you can do whatever you want with the work as long as you retain the license. Apparently the WTFPL wasn't unique enough to be approved as the OSI doesn't accept "vanity and duplicative Licenses" regardless of whether they are free or not.

@Ricordisamoa - WTFPL is not a public domain dedication (despite the OSI's flippant dismissal). It doesn't renounce or waive the author's copyrights. It is simply an EXTREMELY permissive free license. The FSF considers it a GPL-compatible free license, although they obviously don't support its use since it isn't copyleft. The fact that there is no legal concept of public domain in Europe has no bearing on the WTFPL since it isn't a public domain dedication. As the Wikipedia articles says: "The license differs from public domain in that an author can use it even if they do not necessarily have the ability to place their work in the public domain according to their local laws."