• D16853 tweaked one issue that I caught.
• T11881 is a followup for restoring code diffs in a small set of scenarios.
• I haven't seen other issues for a while, so I'm going to consider this resolved until they crop up. If you do run into cases where the new algorithm isn't doing a great job, let us know.

In T11034#199653, @epriestley wrote:

---

Now that this has been deployed for a while, I'm curious if there's any feedback about it? Specifically:

• Does this approach generally seem like it's a reasonable solution to the problem (if not in its current form, in some similar form which handles these issues more gracefully)? Or are we not really in the right ballpark?

It's entirely possible I missed some things in supporting the 25,000 different URI forms we now support, but just file a new issue if you run into anything since this task is now 200 years old with seventy pages of unrelated disucssion.

D16115 + D16847 + D16848 make these changes:

I think that will prevent these edits from occurring by accident via the web UI. Yell if you manage to trick it or it causes any weird stuff.

I believe this is now in reasonable shape, in the sense that the overwhelming majority of prose inputs I'm aware of produce reasonable, human-readable diffs. They aren't perfect in all cases and aren't necessarily the diffs that a human would produce, but they're useful and fairly sensible.

unit tests ftw

That seemed to just work? Slightly disconcerting.

Pretty sure this works as intended

Look at how much engagement we're generating!

comments

more

need

still

I would edit my comment to put a paragraph of text above the autoplay audio, but newsfeed caches the old comment. :3

I think we can safely conclude that autoplay audio in feed is an effective mechanism for disseminating important information.

We still do a pretty questionable job on the first case in T7643#180264, where a comma is removed from the middle of a sentence.

I suppose an alternate path is to enable Dashboards on Project homepages, and you can embed your project wiki or text panel for a really cool long description and information.

Would you fill out at least, like, 5 of them?

Hovercards, Search, Browse, etc. It could get used.

We could call it "Search Description" so it feels clear that it only displays in some UIs.

Yeah, I think it's pretty reasonable if people would actually fill it out. We could surface it in a few other places too (e.g., /projects/) without fallback. It just seems like there's a decent chance no one will ever fill it out and it will sort of just be cluttering up the UI. But the cost on our side is pretty small, so if some people claim that they'd probably want to fill it out I'm happy to move forward with it.

Provide an alternate, text-only field for "Project summary in typehaead results." which users only enter text into, so we don't have to worry about remarkup.

For reference, here's the current state of "discovery" downstream:

I believe this is now resolved, in the sense that I expect all specific, reproducible examples I'm aware of function in a way consistent with user expectation. In particular:

I have some possible approaches for cheating on the "more than 100 results" case, but I think we ultimately need to put the prefix paging rule on the server side, so we return all prefix matches and then all content matches. That's kind of a big mess, but all the ways we can cheat will break down at some point (e.g., when you have 100 "wikidata" projects that are alphabetically earlier than "wikidata") so I think it's not avoidable.

Pausing this from our perspective since we're waiting on guidance to move forward.

Sounds good, thanks!

In other words is your array syntax always messagekey[gender][plural] or could it also be messagekey[plural][plural] depending on the variables?

We support unlimited gender/plural variants in any order. We have a number of strings like this:

%s cannot be repeated as far as I know.

When multiple variants exist, should we export a nested structure like this?

[...]

"aBmeIEk": {
    "one": "%s star",
    "other": "%s stars"
},

In T5267#199335, @epriestley wrote:

Variables such as $1 are not part of the spec, and it makes no difference to us if you use %s instead. So unless this conversion is required by your system, you can drop it.

At least some translators are likely familiar with $1, {{GENDER:$1|X|Y}}, and so on, right? And you have documentation on this syntax to help translators who aren't familiar with it learn it?

Here are the current internal data formats:

Variables such as $1 are not part of the spec, and it makes no difference to us if you use %s instead. So unless this conversion is required by your system, you can drop it.

Some of the terms that I use below (e.g. outdated) are explained in https://www.mediawiki.org/wiki/Help:Extension:Translate/Glossary

The rTRANSLATEWIKI repository is now available. Here is an example of the en.json MediaWiki-style JSON string file we currently generate:

I don't know what this means. $ in the string contents isn't anything special for translatewiki.net.

• When exporting, I don't know how to escape $ for Translatewiki (this affects ~10 strings).

Likewise, when importing, I don't know how to unescape $.

The technical definition of "Limited" is that it has fewer than 512 strings, including 0 strings.

In T5267#199144, @epriestley wrote:

• Did you notice that "Spanish (Spain)" was under the "Limited Translations" heading, instead of the "Translations" heading?

I think D16810 should get this started, at least. Known technical issues:

@MZMcBride, couple of questions so we can improve this:

I've marked D16806 as resolving this. Once that lands, here's the state of the world in terms of how the product works:

I'm specifically interested in the arc diff --try part of this and would want that to be the configurable as the default behavior. For an installation that's using things like CircleCI integration to run tests asynchronously on a build server, it seems very plausible that reviewers will sometimes fail to notice that tests haven't finished running yet, which will lead to people landing broken code.

Duplicate thing filed in T11800.

I'm going to file the duplicate import thing as a separate task since it probably won't come up for a while and close this out.

(Google API integration is covered by T2334 -- you can already interact with Google Calendar via ICS files, but that will add support for using the API instead.)

The Gmail/ICS integration seems to actually work OK in practice, here's an event from this install working (modulo some stuff like us not exporting a host/organizer yet):

I would subscribe to the Paste, and spend 20 seconds updating the file if it changes. Like I mentioned before, this task has already been prioritized and we're not going to work on it until other things in the prioritization queue have been completed. I think self-maintaining is a reasonable work-around.

It looks like T10814, specifically T10814#170824, provide some useful info. Thank you for that link!