Packages is for distributing Arcanist packages (linters, etc) to your local
developers. I don’t expect Phragment to leave prototype.

I also see a Packages application as well, however both Packages and Phragment seems to be prototype application and uninstalled on our running instance. Perhaps Packages is what i need to look into as a substitute to Files because it seems to be more access control for creation. Does Phragment and Packages support S3 storage backend? How would i would about installing it back since it is indicated as uninstalled?

Versioned file distribution is part the Phragment project, but I think we plan to just roll that functionality up into Files first class.

When a user writes a Maniphest comment, I think fully and correctly populating the "Change Subscribers" field, including its new/upcoming additions, would be a good and unobjectionable feature. This would allow the currently unconditional additions to be removed manually prior to form submission. This would still be tedious, but at least I could make a comment without having to either mangle the quote or go back after commenting to perform a separate manual action unsubscribing the user that I didn't intend to add.

Arcanist is the command line tool for Phabricator. You should have installed it when you installed Phabricator.

You should install arc. arc is the script in arcanist/bin/arc

I am so sorry, if my comments look a little bit "dumb".

In T11471#190152, @epriestley wrote:

If you don't like the @mention-implies-CC behavior, you can disable it by applying this patch to your install:

[...]

You'll need to run arc liberate to pick up the new file so Phabricator can find it or put it in src/extensions. Then if you're an admin, go into Settings -> Global Default Settings, and change the install language there.

No i realized, that the File with the translation has to go to the "/root/libphutil/src/extensions" Folder, some Values are translated in the ui, but others aren't. Is there a file, where i can find all strings, to translate it? Or is there another way to find out how to translate a specific string?

My bad I didn't see the second comment by @chad. I know it is possible as @epriestley changed the language of this instance (see D16310#190724).

Let me add some note: A changing of the "Translation" - Dropdown in the individual account settings never makes a change. So it is not important if i choose german or something else. That is not influencing my request, but is that a normal behaviour? Or did i maybe make a mistake when i set up the system?

In P1821#4300, @devurandom wrote:

The default language can be changed using following patch (cf. T8916):

diff --git a/src/applications/settings/panel/PhabricatorAccountSettingsPanel.php b/src/applications/settings/panel/PhabricatorAccountSettingsPanel.php
index 72a2252..b233ba0 100644
--- a/src/applications/settings/panel/PhabricatorAccountSettingsPanel.php
+++ b/src/applications/settings/panel/PhabricatorAccountSettingsPanel.php
@@ -72,7 +72,7 @@ final class PhabricatorAccountSettingsPanel extends PhabricatorSettingsPanel {
 
     asort($translations);
     // TODO: Implement "locale.default" and use it here.
-    $default = 'en_US';
+    $default = 'en_P*';
     $translations = array(
       '' => pht('Server Default: %s', $locales[$default]->getLocaleName()),
     ) + $translations;
diff --git a/src/infrastructure/env/PhabricatorEnv.php b/src/infrastructure/env/PhabricatorEnv.php
index d5c4c34..3c09d0b 100644
--- a/src/infrastructure/env/PhabricatorEnv.php
+++ b/src/infrastructure/env/PhabricatorEnv.php
@@ -126,7 +126,7 @@ final class PhabricatorEnv extends Phobject {
 
     // TODO: Add a "locale.default" config option once we have some reasonable
     // defaults which aren't silly nonsense.
-    self::setLocaleCode('en_US');
+    self::setLocaleCode('en_P*');
   }
 
   public static function beginScopedLocale($locale_code) {

This is the full code of the file in my case.

Do you mean the patch, added by devurandom ? The first part of the patch ($default...) is not existing in my PhabricatorAccountSettingsPanel.php

Does T8916 help?

If you don't like the @mention-implies-CC behavior

This is not a demo bug tracker. Please Close this task and go to https://admin.phacility.com/auth/register/ to create a demo account for free.

To clarify these errors are being written to the logs continuously until the disk fills up and I have to delete the file. And, I'm not sure what triggered this behavior.

I understand where you're coming from, but the problem is I'm not sure what led to this happening so I'm not sure how to proceed. Can you tell me is there some information I could obtain for you that would be helpful? Otherwise would you recommend upgrading/reinstalling my instance?

https://secure.phabricator.com/diffusion/P/browse/master/webroot/rsrc/js/core/behavior-form.js:57
looks like it's supposed to be listening to submit, but there's no submit event being fired while in a dialog; It does fire when the same dialog is loaded as a full-page, so some magic is happening there.

.aphront-form-input input is to blame.

I'm also seeing this for failed builds:

Resolved by D16415.

Another possibility is to not rename any of the resources and just do the rename at the display level. This is a little messy, and occasionally a little confusing (instance newname will still have databases, backups, etc., named oldname) but we can probably do a fairly good job of covering that up.

Thanks - Q462

Probably best to ask that as a new question. I don't personally use Eclipse and just run arc from the command line.

Do you have any suggestion about performing arc commands directly from Eclipse ?

I'm going to upload a patch in a few minutes (I can't claim the task :-/).

Thanks for the report! This should be fixed in HEAD of master, and promote to stable in a few days. Let me know if I missed anything or you're seeing other issues.

I don't really have a pathway forward on this that I like, so I'm just planning to do the one outstanding request for this manually as a copy operation and kick the can down the road.

I think that makes things fairly easy technically:

I broke this in D16360, on August 1.

Thinking about the S3 issue, It's probably better to just migrate all the file data to the blob store, rename the database (which we have to do anyway), then migrate it out of the blob store.

I'm running into a need for this to make automated export reliable, too, and don't really want to put a second copy of set -o pipefail in the codebase.

I also encounter issues configuring the script and regex linter.
However, I use regex101 to test my regex, so I know that works.
If I remove the || true exit code workaround, I see that the right commands are issued, with the right stdout, so that works as well.

Yeah, I think splitting it out is reasonable. There are a lot of reasonable ways forward that make this more of a standalone app, and it's going to need its own storage to keep track of stuff you skipped, I think. We could probably shoehorn it into Config but I don't think there's any real downside/cost to splitting it.

Thanks for the detailed investigation -- glad we've root-caused this and proposed a solution :)