Where can I find the major features list, any document?

That setup is not supported, and we already raise a setup warning making it clear that major features will not work until the base URI is configured.

Actually, I want use Phabricator on intranet( IP address, https://192.168.1.10/) and internet(https://somedomain.corp...) with different URL, so I keep it empty.
If this is not a bug, can you add this to the section:Troubleshooting in diffusion_hosting.

Why did you choose to ignore the warning, considering that it says "major features will not work properly" until you configure it?

Yes, but I don't know it's related to ssh service.
This problem spend me about 4 hours, I checked everything ...

When phabriator.base-uri is not configured, you should receive this setup warning:

Thanks @epriestley for the reply. Seems like my mental model of "prototypes" along with the misleading wording of "future" threw me off.

@20after4, just a heads up:

As far as I understand, E66 acts as a prototyp (or template), providing defaults for when the individual instances are "materialized" later, when they are edited. Is that correct?

I also had the same problem and solved in the same way!...

Hi @epriestley, thank you for your explanation.

Looks like the JIRA's default door keeper worker. I guess it is automatically discovered when you run arc liberate command.

oh,I'm very sorry. I do a wrong job. manifest.search API can get tasks by milestone. the key phids in constraints support two methods to set. one way is to use project name(this doesn't work for milestone). other way is to use project phids(this work for milestone). I always use project name to set this key, so I can't get the right result. This task can be closed. I am sorry again.

e.g. this is a number1 milestone in Use to test object

Username

Terminate

If anyone else is looking for this, we have this extension in our local install P2019, which does custom things to a JIRA ticket based on Revisions.

E1218 seems to have worked properly after the patch, at least.

I'm pretty sure D16937 fixes this, thanks for the report! Let us know if you're still seeing issues after that.

I think this should be fixed in HEAD now, but you may want to wait a few days to update (e.g., until stable promotes on Friday) since a few bugs related to T11044 have been cropping up since it landed a couple days ago.

Thanks for the lightning response!

Yeah, looks like that reproduced it. Here are the caches:

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

Sorry, can't make it this time! I'll catch you guys next time for sure.

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

Hmm, can you try creating a test event on this install to see if you can reproduce it here? I played around with this a little bit locally but wasn't able to get it to break.

It's like before: Neither the orange thing appears nor am I listed as "busy" at my profile. I'm listed as available there.

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.

Thanks for the report! I think D16924 should fix this, and one other issue that came up too. Both these are related to supporting multiple partitioned masters in connection with T11044.

If this reproduces at HEAD, it's a bug. Please file a new bug report with complete reproduction steps and version information.