Broadly, DifferentialCustomField drives a very large amount of stuff in Differential. This was the first generation of custom fields, and is the most complex implementation.

This has been running cleanly in production for roughly two weeks, and appears stable. secure001 stopped writing Files data at F1943597 and we're now at F2078289 on secure003. We saw a couple of minor setup issues (mostly: exception messages not being tailored enough) but no fundamental issues.

I'm planning to support this in the arc experimental branch, although initial support won't be optimized. We can look at ControlPath and/or adding batching to the protocol layer to improve performance once it works.

This one is fine, I'm still going to fiddle with "in" too.

In T8510#200946, @aklapper wrote:

In https://phabricator.wikimedia.org/T76732#2803813 ksmith brings up that

In the search bar in the toolbar at the top of the screen, searching for "Maps" brings up Maps as the third option. Searching for "Discovery" brings up Discovery as the second option.
When editing a task and entering tags, autocomplete does bring up Maps and Discovery as the first items.

but that could be a separate (unprioritized) task I guess.

Feel free to file a new task when you encounter actual problems with real text and we can look at adjusting the limit, adding an additional block-level difference phase, rewriting PhutilEditDistanceMatrix in C (see T2312), or other approaches. We can make a better decision based on concrete examples of where the current solution is falling short than by guessing where issues might arise.

@epriestley thank you very much for the fast update and fix. It is working now with my example, and should be much better with a lot of pages.

After D16933, the behavior of arc browse <branch> on the experimental branch is:

Sure, not a problem.

We now export a frequency.json, with string keys in a list. Since we haven't actually collected frequency data, the order is currently (roughly) random:

https://secure.phabricator.com/source/translatewiki/browse/master/projects/phabricator/maniphest/frequency.json;00108900457eda804c9c786dd76ff96620a05195

We now export strings into projects/<project>/<group>/en.json, etc. For example, here are strings which appear ONLY in Maniphest:

Okay, I believe we already produce a format which is compatible with that definition:

1. Proto-english strings.
2. Nested English translations.
3. Variable types.
4. Usage frequency information ("this string has frequency 0.9 out of 1.0", or "this string is part of the 'most common 10% of strings' group").
5. Application groupings ("this string is part of Maniphest").
6. Places in the code where the string appears ("this string appears at x.php line 234").
7. Additional human-readable context information, like "qqq" (very rarely available).

Maybe it would be simplest if you just give me an example of exactly what you want us to emit?

What works out of the box is JSON files with string key-value pairs for source text. For documentation the qqq.json that is "just-another-language" is what we use most often. The strings of that file are parsed as wikitext using MediaWiki syntax and displayed automatically to translators.

That sounds fine to me. Do you have any preference on what format you'd like the proto-english + variable type annotations in? Maybe something like this, since it sounds like you're doing some level of custom stuff on your side anyway?

Okay, I have been thinking this for a bit. I don't have a perfect solution, but I have the following proposal.

I'm sure if I keep digging we'll be out of this hole in no time.

I'm not sure if D16857 is even close to the right level of generality or correct approach and the answer has yet to come to me in a dream, so I'm going to push forward on top of it and see how far I get. If too much stuff stacks up I'll maybe shove this stuff into an experimental branch for now until I decide whether I'm throwing it all away or not.

This seems to be working now. I'm going to let it sit in production for a while and see if any issues crop up before considering it resolved, but it seems like everything is working smoothly.

I configured 003 to replicate to 004:

Okay, we're headed back into readonly mode shortly to set up replication. I'm going to verify D16916 along the way so there may be some "partitions disagree about life" errors.

Here's what I've done so far:

I'm partitioning secure.phabricator.com now. Things will drop into read-only mode for a bit.

• T11908 is a followup for executing queries for multiple applications on a single connection. I believe the pathway for that is straightforward and fairly short, but that no install would really reap substantial benefits from it today, so I don't expect to pursue it for some time.
• I believe everything else is now complete, so I'll put this in production as soon as everything here lands and we can see what catches on fire.

We have at least one tricky issue remaining: when applying storage upgrades, we currently apply them like this:

General state of the world here:

Yeah, I tend to agree. I don't really see any approaches we can take here that don't make things a little worse for experienced users who already know what they're looking for, and I'm not sure there's too much of a use case left for less-experienced users.

The main concern for me would be typeaheads are for knowing what you're looking for already, and making that faster / easier. Browse interfaces are for discovery.

This is sort of what I was thinking about for the "Search Description" / "Usage Hint" (descriptions / projects are random examples):

(You could write some similar rules if you want to try something in that vein, although it's a pretty big pain to fork JS/CSS right now.)

I should make a Herald rule to auto-resign.

Okay well @chad resigned from D16893 as soon as he saw animation in a CSS file so I don't think that one's going anywhere.

In https://phabricator.wikimedia.org/T76732#2803813 ksmith brings up that

In the search bar in the toolbar at the top of the screen, searching for "Maps" brings up Maps as the third option. Searching for "Discovery" brings up Discovery as the second option.
When editing a task and entering tags, autocomplete does bring up Maps and Discovery as the first items.

but that could be a separate (unprioritized) task I guess.

Ah, thanks! I've asked downstream if anyone still runs into any issues, but so far I also believe this is now resolved.

Alright, I'm going to try this:

The most-likely-to-work secret magic for "Not in: Wikidata" is not(wikidata):

phabricator.wikimedia.org is running a version including these changes plus D16886 on top. So far it looks like a great improvement!

+1 to what 20after4 wrote. The approach is definitely helpful, and to make this look less cluttered and inconsistent ("are projects with longer descriptions which take up more vertical space somehow more important?"), cutting off project descriptions seems like a good compromise.

I caught another case of this: here, "Phacility" should be first, but is not.

Ah. I believe I fixed a simpler version of that case earlier, but not the specific case you describe. D16881 should fix that case.

@epriestley One issue that is still open is adding a change to the beginning and to the end of a large prose text. The diff of that becomes unusable. This is still reproducable with the current stable branch )(fc71a7e92dc26e0d93ec33d709391411d2bcd827 (Mon, Nov 14)). For details / reproduction steps please see T11825.