We don't officially support localization, though you may use it if you feel adventurous.

I'm going to merge this into T5267, which discusses a larger-scale effort to translate Phabricator in the relatively near term. We'll be interested in feedback like this once that's a little further along.

I'm going to merge this into T5267, which is more actionable in the short term.

Naturally people can work on what they want – that is the promise of open source. I am not contesting that. What I do want to make sure is that our values and goals are aligned. For example you and we recommend people to collaborate first. If we are sufficiently aligned, I don't see much need to continue discussing about things that might or might not happen.

Competing translations are waste of resources and choice is not good for users.

If we submit patches, say once or twice a week, will you be able to review and merge them before the become stale?

Usually, yes, but I can't promise we'll always be able to review patches promptly.

I do not know what are you main concerns [with direct commit access].

Like you say, Phabricator is a big project. This means I am willing to give some amount of special treatment to it that I would not give to smaller projects because that would not scale. For example, requiring all messages to have message documentation up-front is unreasonable. But a good way forward would be to establish good practices such as:

• having message documentation for new or changed messages;
• accepting bug reports and patches about source texts;
• and enhancing and enforcing best practices in code review with regards to parameters, plural handling etc.

In T5267#176885, @epriestley wrote:

• We get a "sync" process working, so strings can be imported from Phabricator to Translatewiki.
• We get an "export" process working, so strings can be exported from Translatewiki to a format we can read.

I think the largest source of concern here is the (1b) and (3) rules: we aren't willing to exclude translations from other sources, and we aren't willing to give anyone direct commit access to the upstream. But Phabricator supports loading translations from external libraries, so we don't actually need to resolve these issues.

One also needs to patch libphutil/src/internationalization/PhutilTranslator.php:

diff --git a/src/internationalization/PhutilTranslator.php b/src/internationalization/PhutilTranslator.php
index 21e4620..dfbf729 100644
--- a/src/internationalization/PhutilTranslator.php
+++ b/src/internationalization/PhutilTranslator.php
@@ -165,6 +165,7 @@ final class PhutilTranslator extends Phobject {
       case 'en_P*':
       case 'en_R*':
       case 'en_A*':
+      case 'de_DE':
         list($singular, $plural) = $translations;
         if ($variant == 1) {
           return $singular;

I'd translate 'Set Sail for Adventure' => 'Segel setzen' and add 'German' => 'Deutsch' (and similar for the other languages).

Thanks @CamilleBouliere we have a requirement to provide FR translations in our organization, so this was invaluable. I hope it is eventually incorporated upsteam!

I'd like to translate Phabricator in French, if the support for translatewiki.net is implemented.

I'd like to have Vietnamese for Phabricator as well. My team can manage the translation

I've just shared some common strings into french. It's on GitHub : Phabricator French Translation.

two added translations and a typo-fix:

See also T5267. I found that task by searching for "translatewiki" in the global search.

As I wrote at T10015 Translatewiki is maybe a good, free way to translate it. They translate open source projects like mediawiki, or like phabricator maybe in future. See here for details.

• Send rules upstream for now (like with the Korean rules).
• We'll probably make this modular eventually.

Add a new Locale file here:

In T9285#134333, @epriestley wrote:

If you're trying to translate into another human language (like French or Spanish or Italian), I'll accept new PhutilLocale subclasses into libphutil (with corresponding rules in PhutilTranslator) if you want to send a diff.

We don't have any current plans on shipping i18n inside Phabricator yet. When we do, it's because we'll support what we ship. For now I think what some German users are doing (sharing a Paste file here, P1792) is perfectly fine.

Correction: "Blocked" -> "Blocked By"

imported, Thank you @theunreplicated

Extended Task to include Batch Editor

I expect to move this stuff into Locale subclasses eventually, but it's potentially performance-sensitive so I want to be careful when doing so.

In T1139#132636, @lschabel wrote:

Internationalization is very important for non-technical users. I'll contribute a German translation.

Internationalization is very important for non-technical users. I'll contribute a German translation.

I would note that Calendar is a prototype, and probably shouldn't be on this list (as we don't consider apps "production-ready" as a prototype). https://secure.phabricator.com/book/phabricator/article/prototypes/

Hi,I have added some translations,those can be added into this paste here as well.But I haven't tested those with Umlaute like äüö because I didn't manage them to show up in my local phabricator windows installation(I've inserted those translations as a hack into PhabricatorVeryWowEnglishTranslation.php because putting this file into the xtensions folder will not show them up in them in settings>account>translation nad arc liberate fails seems to fail on windows)

In T9168#132007, @devurandom wrote:

If only someone would read these explanations...

If only someone would read these explanations...

Well... Phriction is not wiki, nor is diffusion repository ;) When You boy for example car from Tesla named "Model S" do You complain that it's not named "Sedan"? Imagine all those Ford Sedans, Mazda Sedans, Toyota Sedans... Branding is important. Before Wikipaedia, how would You call Wiki-style page editing?

We aren't interested in pursuing this for a bevy of technical and product reasons.

I wrote a gettext translator plugin for Phabricator (you can take a look here):

Yeah that's true. Good point.

Then we'd need serious + non-serious locales in every language.

https://secure.phabricator.com/book/phabcontrib/article/adding_new_classes/

I think it's run arc liberate from the command-line to pick up a new file, then restart apache/php-fpm to cache it.

thank you very much for the translation file. I added this to an existing Phabricator installation which is 1 week old so I suggest it should be compatible. Unfortunately it looks like it was not enough to copy it to the corresponding folder. I restarted phd and also apache / php but the resource does not get recognized. Do you have any ideas or is there a HOWTO where I can have a look ? I did not find a corresponding document. Any hint is appreciated. Thank you in advance !

Suggesting to prioritise this task. Non-English interface on Phabricator would be useful, as it would let people file non-English bugs. This is useful for two purposes:

• Development initiatives within non-English-speaking Chapters. While there usually is at least one English-speaking person within the Chapter who could handle the translation, it would be more convenient for them to have the list of non-English issues on phabricator and translate them routinely than having them on a piece of paper and file them "later". This way the reporter is up-to-date on the progress of the bug, and the bug tracker is there to dump everything on it in the first place so that things are not lost.
• Gathering feedback from end users. This is more interesting: I saw Mozilla come to it over the years to the extent of establishing a special 'user feedback' tag on their issue tracker, and writing a special code on their knowledge base site for users to type their problem and submit it to bugzilla without interacting with bugzilla directly (this knowledge base site is aggressively multilingual with lots of readers in each language for about a decade at least).

Now, I don't have to do all this, because the information freedom movement does not need to be centralized; I should be free to mirror any Wikimedia project and play with my software issue tracker whimsicals there, and leave you with the task of needing to merge my software and my content back at your discretion. But the way Mozilla does the international scope of the movement is nice and I would not mind it if Wikimedia considered following it, as it would unleash some more potential and merging back would be easier, as you would be informed of the things happening at these non-English projects. :-)