I've updated the erroneous screenshot in both stores.

It's been approved now, and is appearing in searches: https://chrome.google.com/webstore/search/who%20wrote%20that

Some new maps here: https://en.wikipedia.org/wiki/Wikipedia_talk:WikiProject_Western_Australia#New_region_maps%3F

The Chrome review is taking longer than it's ever done before, I suspect because we've changed the name (removed 'beta') so it's waiting for extra scrutiny.

update the order of the screenshots on both the stores to match my comment?

This is ready for QA again.

All CommTech engineers are now authors on both Chrome and Firefox extensions, with full access to both (including to add new authors). The shared account still doesn't have 2FA, but this shouldn't matter as we don't need to log in to it ever.

Correct length-checking is merged.

Patch ready for review: https://gerrit.wikimedia.org/r/c/mediawiki/core/+/556102

In T239840#5822102, @dom_walden wrote:

@Samwilson The German version has no description. Should it fall back to English? (https://addons.mozilla.org/de/firefox/addon/whowrotethat/)

First non-beta version is 0.15.1.

PR for deployment and proxy docs: https://github.com/wikimedia/WhoWroteThat/pull/148

All the issues here have been fixed now. Ready for QA from the current master branch.

Oh right, that makes sense.

If they want assurance that the line won't be broken between the number and the percent sign (which is why they're using nbsp), we could add white-space:no-wrap to that strong element. Is that worthwhile?

PR is merged.

Both browser stores have now been updated with 0.14.0.

I've added the four screenshots to both Chrome and Firefox (it turns out that despite what the documentation says, FF does support more than one screenshot).

Oh yes, and we also have https://tools.wmflabs.org/wsexport-test/ — not sure if we want to migrate that as well?

PR for if the zh-hant → zh-cn mapping is correct: https://github.com/wikimedia/WhoWroteThat/pull/142

To simplify this: is it okay to use translations in zh-hant (Traditional Chinese) for zh-cn (Chinese, China)? This is what's currently shown at https://addons.mozilla.org/zh-CN/firefox/addon/whowrotethat-beta/ — is this correct?

Note that wsexport did used to be on its own VPS, at wsexport.wmflabs.org. I can't find anything about why it was moved. I guess it was just easier to maintain (and maybe some required packages became available on toolforge?).

I've had a go at fixing the colours for the drop zone and bottom buttons:

The above patch is waiting for the help page to be more than a placeholder before it can be merged.

Thanks for catching that @dom_walden.

The main ticket for the screenshots is T236873, it has all the details.

I'm not sure why it's not available in preferences; I assume because not all essential MediaWiki messages have been translated for it yet.

It looks like keeping the original content attached to the DOM does avoid the issues with re-attaching a deep clone of it. At least, the wikiminiatlas behaves itself, with its mis-nested elements. :)

I've updated the Chrome screenshot to this not-wonderfully-prepared thing:

Dupe of T236873?

No worries; closing this in favour of that one. Note however that there isn't much difference between a plain issue and a 'Bug'-labelled one (as far as I know, it's just the red 'bug' thing!).

Oops, I missed your later update, so prob didn't need to restart the enwiki job; no matter. The web service should be running again now. I'm not sure why it was not responding (the job was still running).

Ah, it's a different job; the restart_plagiabot.sh command is something else.

I'm not familiar enough with how eranbot works. It doesn't look like the restart command has fixed things (or does it just take a while for the reports to start being added to the DB?).

The most recent report looks to be from 2020-01-04 16:05:36:

in some cases (like Arabic numerals) the + *does* need to be on the right side

I've not got that extension installed, but Firefox's contrast checker highlights the text on background #657d91 as the problematic parts. Is this correct? i.e. the 'Drop files here' and row of buttons along the bottom of the area should all be higher contrast? Could you attach a screenshot of the areas of concern?

A fix for this is to ensure we lowercase the language code. PR: https://github.com/wikimedia/WhoWroteThat/pull/132

You're quite correct @dom_walden :) Those glob strings should be URL encoded. Not that the docs would say so, of course. :-P

Removing myself because I'm no longer working on this. (I'm more in favour of moving graph storage out of the wiki, which seems like it should be a new extension.)

We don't need to map them to the different codes in the json files in the project, because those are all correct for MediaWiki use (which is where most of them are used). The incorrect mapping is just for the name and description, where we need to copy them in accordance with Firefox's language codes. That's a manual process anyway, so it's probably okay to make the mapping from zh-hant to zh-tn manually (i.e. hardcoded as we are doing for e.g. pt to pt-pt).

PR for the qqq typos, and to fix some parameter lists: https://github.com/wikimedia/WhoWroteThat/pull/129 (this PR is maybe useful even if we get rid of the lego messages).

What it should be: "Error: Please contact us about this issue" or something similar. The reason it has "to contact us" is probably because the translation message for "contact" is standalone, outside the main sentence.

Yes, the reason that partners is different is that it's a bi-directional link between pages and so can be defined from either end. That means that rather than defining a partner page and outputting its link at the same time (as works for parents) it's necessary to define it (with zero output) and then use {{#genealogy|partners}} to output the list of partners (which will include all partners including those defined from other pages). For example, the following first defines up to three partners, then prints them all together (with any externally-defined ones):

I've updated the version on the genealogy demo site to 1.9.2, and Miraheze is now updated to that version too (the PRs I sent were merged within seconds!).

there is only the detail added by the name space when linked to another biography. It would be good to omit it

It would be necessary to create another name space in order to test (in tools genealogy).

Good point! :)

Nope, it should just work.

Genealogy links in any namespace should now work as expected, including in tree generation.

Does it need to be a specific list of namespaces, or could it just permit use in all namespaces? That'd be simpler, I think.

I am seeing the WWT link on pages like the Main_Page or in other namespaces (e.g. User_talk).

I've created a tool to check the listings' name and summary. PR ready for review: https://github.com/wikimedia/WhoWroteThat/pull/125

Now available on test.wikipedia.org and test2.wikipedia.org; ready for QA. Also available on beta.

Is the "MB" unit really decimal-based (common language millions of bytes, i.e. 10^6=1000*1000) ?
Shouldn't it be "MiB" (binary-based "mebibytes", i.e. 2^20=1024*1024) ?

(As well as test.wikipedia.org, I meant!) Anyway, the above patch enables it on both test wikis.

Do you prefer that we have it up on testing on beta or test wiki?

Thanks @Volker_E. That makes sense; most datetime pickers are pretty confusing. Will there be a timepicker of any sort in the future? Or just text fields?

I've tried to fix it up, but there seems to be something odd going on with the isCached thing. Anyway, here's a PR to switch to using jQuery's fadeIn(): https://github.com/wikimedia/WhoWroteThat/pull/123 (I think the other code dated from before we switched to using jQuery there, so this seemed cleaner; happy to change it though).

Oh! Yes, I see. I think I should brush up on my reading skills. ;-)

The Help page should perhaps be Help:Password_Reset, since this mirrors Special:PasswordReset.

Nope, no reason! :) I figured the datetime one would be more complicated, and so tried it first. The date one should be pretty straight forward I think.

According to this, the other translations are only imported when the extension is created the first time, and not when it's updated.

I have figured out a fix. Basically, it looks like we add to the Resource Loader queue before it's finished being set up.

I've been experimenting with splitting out the graph-rendering to a service:

I think I meant that having a new input type was not a good idea, and that it'd be better to change the existing ones to use OOUI instead of jQuery UI. I have been meaning to get back to that patch and fix it up. Feel free to grab it if it's useful; I don't think I'll get to it before the end of the year.

Thanks!

I think the recent z-index increment from T234709 might have also solved this.

I've also asked about other ways of doing this. The other issue with automating this is that when we upload a new version, we have to supply the source code, and there is currently no way to do that via the API.

I will bring all languages on both stores up to date with the latest (short) descriptions from the current i18n files. This will make the store descriptions match what's seen in the extension lists after installation.

Merged, and deployed to https://tools.wmflabs.org/wsexport-test/

The double-shimmer fix is here: https://github.com/wikimedia/WhoWroteThat/pull/112

Fixing this up now.