It looks like T10814, specifically T10814#170824, provide some useful info. Thank you for that link!

I would like to submit a translation to upstream. Where do I start?

P1792 is the German example.

If you want to pursue i18n ahead of the upstream, T10814 has some walkthrough I did with another user. It's basically, dump strings into a file, translate, add to src/extensions. https://secure.phabricator.com/w/community_resources/#translations has examples of Chinese and German users have shared here.

Everything you mention is covered by this task.

In T5267#198537, @chad wrote:

The current status is the infrastructure is provided, but the translations are not (you need to either translate it yourself, or check the community wiki page here for community contributed translations). Then install said translations locally.

The current status is the infrastructure is provided, but the translations are not (you need to either translate it yourself, or check the community wiki page here for community contributed translations). Then install said translations locally.

I'd like to get this task un-stuck. I'm unclear on Phabricator's current internationalization capabilities.

This should be fixed in HEAD of master. Thanks for the report!

We can probably just use the merchant name for now. I could maybe imagine some "International Business Machines, Inc" vs "IBM" stuff down the line, but no immediate issue for "Phacility".

Do we need a new field for subjects or is Merchant Name enough? Not sure both are needed.

seems this is due to I didn't add the --lintall option,
the change is one line removal (existing file at the base commit)
thus it's considered as not concerned, but it is concerned actually because I didn't remove the entire function

In T3179#142498, @lfarkas wrote:

Trac wiki import to Phabricator's Phriction.

Based on svemir's anser in https://secure.phabricator.com/Q12 a not to nice not perfect but more then nothing:

https://github.com/lfarkas/phabricator/blob/master/scripts/util/trac_wiki_import.php

...and here are foreseeable issues with this mess occurring in the wild:

Broadly, I want to avoid implementing things that don't have good technical justifications.

I've done some more digging as well and it appears that this issue arose in the Go library already: https://github.com/golang/oauth2/issues/111

OK I imported some real great events:

Is "GitHub-specific OAuth" just normal OAuth with client_id / client_secret as parameters instead of in an "Authorization" header? The GitHub OAuth documentation seems to suggest passing these as parameters, too.

It seems like section 2.3.1 is poorly worded. They talk about a "client password" but the example request only includes client_secret as a POST variable. In the case of the Golang OAuth2 module (which Concourse uses), it sets the basic auth username to the client ID and the password to the client secret (https://github.com/golang/oauth2/blob/master/internal/token.go#L164).

I think the textarea predates using JS magic to make "copy" work. I think we could probably remove the "disable highlighting" mode now; I can't really imagine any legitimate reason to intentionally disable it in modern code, except maybe not realizing that "copy" will work correctly via magic.

I don't think we have a "client password" in this case -- I believe that refers to a mode that no one uses for anything (well, maybe a mode that Concourse uses, I guess), where the flow is actually handling normal user passwords?

I understand the situation. I will have a look myself.
Thanks for your answers!

Essentially, if there is a way to accomplish something in Phabricator, but it's not an install's ideal solution, we're not likely to add a second means of solving the same issue unless it meaningfully solves something new. We have 2 developers and thousands of tasks competing for upstream resources - so prioritization is difficult for tasks like this.

Then I'd recommend forking Phabricator to provide the functionality you seek.

We just want to connect 2 tasks, not to create one more task. If we add more tasks then the Task Graph get more complex.

In this case we have a new task for nothing

I don't know what you'd call this type of relationship

there are 2 tasks related to the same problem, but different isses

I think you meant to comment on my answer, not add a new one.

Protocol for URI "svn+ssh://..." MUST be "svn+ssh".

what

Please see and follow Contributing Feature Requests for what information is required in a feature request. Specifically we only take requests that state root problems, not just that a feature is desired.

That's too bad. I've done some testing and realized that the repositories that are exhibiting this behavior are non-bare, and one older repository that is bare is fully up-to-date in Diffusion's UI. (All are git repositories.)

@cspeckmim - Thanks for your answer! I will ask on the forum.

@remusvrm - Your question is probably best asked on Conpherence, IRC, or in the Ponder Q&A application. A Maniphest Task is meant to be representative of work to do and not a question.

?

+1 - quickly adding several tasks to a given column does currently feel quite tedious

I believe that using phid.query should be helpful.

I'm facing the exact same problem.

Phortune is prototype application, which means "The upstream does not offer support for these applications".

@rfreebern Nope, no clue how to debug it. We just don't use Diffusion any more and instead use the Bitbucket page, whose UI we anyway prefer to see commits and browse the code :/

@adityar7 Were you ever able to resolve this? I'm seeing the same behavior on my installation, which we recently transplanted to a new server and converted its ancient file://-based repositories to hosted. My suspicion is that there's something not quite right with user permissions on the system, but /var/tmp/phd/log/daemons.log doesn't have anything useful.

Actually probably moot if we can just provide a link to the new print view.

We can, but all styles need to be inline. DifferentialInlineCommentMailView is an example of an arbitrary-HTML-generating rendering class used in mail.

Calendar is a prototype application, and we don't accept bug reports against prototypes. See User Guide: Prototype Applications and Contributing Bug Reports.

See Contributing Feature Requests for a detailed breakdown of what a feature request needs to have before we'll accept it.

I'm building out a PhortuneReceiptView for the web, which I think we can also send as the HTML version in mail? Not sure if we can call custom HTML rendering in mail.