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 :)

Should I just put this officially into a Guides app, or keep it squirreled away in Config. I suspect if these do well we'll build others.

I agree that there *shouldn't* be any extra cost purely owing to having more fields if I'm only editing one and it is default-focused, but I'd argue that having a more complex form will still slow humans down (at least initially).

There is no actual cost to the form having more fields though, right? It doesn't actually slow you down, it just "feels" more complex?

Is this really "Make Workboards look and feel exactly like Trello"?

This has been live for several weeks without causing any apparent issues, so I believe we're in good shape.

It sounds like you really want Workboards to work exactly like Trello, not just to be able to customize the form? That is, if we let you simplify the form down to this:

More fields means

This should be fixed in HEAD of master, and in the documentation on this host whenever it regenerates (every other rainy Tuesday during a full moon).

I'm just going to merge this into T5028 since I think that ultimately is essentially the same issue.

We are unable to reproduce this, and haven't received more information in about a week. Feel free to file a new task if you're able to develop reproduction steps which we can follow to reproduce the issue.

Why does having more fields make creating a task slower? I'm not able to create tasks any more quickly using a form with fewer fields.

thanks Evan, that did the trick!