We can have a i18n option for both confirmDialog and alertDialog.... Let's do this, who is down?

In D25015#793, @dcog wrote:

In D25015#792, @dcog wrote:

Thanks -- Can anyone think of a more generic solution here as far as dialogs? Something for both confirm() and prompt().

One thing to note here: Native JavaScript blocks execution when these functions are used. This is apparently nearly impossible behavior to mimic exactly, but we can solve this with asynchronous functions with our generic and platform-specific confirm() and alert() functions. Otherwise, should there be an always-available global translation for both alert() and confirm()?

Example of custom confirm():

JX.confirm({
  message: "Form data may have changed. Are you sure you want to close this dialog?",
  buttonConfirm: "Discard Changes",
  buttonCancel: "Cancel",
  onConfirm: function() {
    // Something something
  }
});

But it would need translation added...

In D25015#792, @dcog wrote:

Thanks -- Can anyone think of a more generic solution here as far as dialogs? Something for both confirm() and prompt().

One thing to note here: Native JavaScript blocks execution when these functions are used. This is apparently nearly impossible behavior to mimic exactly, but we can solve this with asynchronous functions with our generic and platform-specific confirm() and alert() functions. Otherwise, should there be an always-available global translation for both alert() and confirm()?

Thanks -- Can anyone think of a more generic solution here as far as dialogs? Something for both confirm() and prompt().

In T15049#1329, @avivey wrote:

Sague font family is probably important on Windows.

... available by default for some reason on Garuda Linux, while Segoe UI is not available.

This might be a bug in Garuda? That sounds like a strange choice.

This revision only adds cross-platform default fonts and doesn't remove any of the existing ones.

The clone repo modal could really use some copy buttons.

Then maybe just show the monogram when logged in.

In T15048#1311, @Leon95 wrote:

^^ Awarding a Token to a "... awarded a token." Message would be a weird case. But what about removing this Message completely? (or add the Option to hide them) It bloats the history of some Objects imensely and is not that usefull in my opinion.

In D25022#768, @speck wrote:

Thinking about this a little more it could be intentional for these to not have monograms displayed in the page title. Tasks, Revisions, etc. are more meant to be directed to internal users of the system while Phame blog posts may also be directed to external users where a monogram might be more confusing. What do you think?

I mentioned on the diff but also mentioning here. Blog posts can be directed to users external of the system where monograms might be more confusing. Maybe we can find another place on the page to put the monogram that doesn't affect the title?

Marking as request changes during discussion

Thinking about this a little more it could be intentional for these to not have monograms displayed in the page title. Tasks, Revisions, etc. are more meant to be directed to internal users of the system while Phame blog posts may also be directed to external users where a monogram might be more confusing. What do you think?

lgtm - I compared to a few other views just to confirm this is the same approach for adding monogram to the title. Thanks!

In T15049#1329, @avivey wrote:

Sague font family is probably important on Windows.

Sague font family is probably important on Windows.

Referencing this "short" discussion that I remember from Discourse

Another, perhaps more useful example.

and yes, I'm also running phabricator on top of CentOS 7 (using PHP 7.x via SCL).

In T15047#1302, @Ekubischta wrote:

Isn't Centos End of Life soon?

^^ Awarding a Token to a "... awarded a token." Message would be a weird case. But what about removing this Message completely? (or add the Option to hide them) It bloats the history of some Objects imensely and is not that usefull in my opinion.

Is it possible to pick a branching off point?

Yep I think this makes sense and is why I think our first release should still support PHP 5.4 but we can move off it after that.

Is it possible to pick a branching off point?

Also, https://secure.phabricator.com/T7413 for the phone-home feature.

The kind of teams that use Centos/Redhat are very conservative - they're exactly the teams that would not install PHP from an "alternative" source (or from source code). They also tend to keep to older OS versions, as long as they are supported, and would not be happy with a single machine being different from the rest.
All that to say, it would make these teams sad to require an upgrade.

I'm mostly a Debian person (so I'm not aware of CentOS specifics) but my understanding is that CentOS 7 shipped with PHP 5.4 and has newer versions available via alternative repositories (not sure if official or not), while CentOS 8 (and Rocky Linux 8, if that matters) had PHP 7.2 by default and shipped a few years back. Is there a reason we're not basing our PHP support on latest distro releases (plus something like a year or two for a transition buffer), especially if newer PHP versions are available for older distro versions available as backports? I don't think requiring PHP / distro upgrades every few years is unreasonable.

Isn't Centos End of Life soon?

+1 for CentOS 7.

Agreed. We should aim to follow some specific conservative release. CentOS 7 seems reasonable.

Expressing the desired behavior here seems difficult to fit into Herald.

• Level: Global
• Trigger: When a task's status is changed
• Action: Move the task to a different column X on project Y

In D25015#735, @avivey wrote:

I may be late for the party, but can't the translated verbiage be provided to the dialog in the $form_attributes in AphrontDialogView.php:337, and read using form.getAttribute(key) in the js?

I looked at the $form_attributes a week or so back but I think those end up being transformed into the literal HTML attributes of the dialog's <form> element. I think we need to add a new field to the dialog, something like setMetadata() that @dcog found in the workboard view.

We should include the Diviner and tech docs generation as part of the upgrade process of this server, that should ensure it's always up to date.

@MikeCripps welcome aboard! I added you to trusted contributors group.

I think our general strategy here should be focused around the versions of PHP available from the default/common package repositories for major server-based Linux distributions. There might be some situations where those package repositories only support very old versions (e.g. CentOS 7) which we should only plan to provide documentation for how to get the required version of PHP installed.

Thanks for submitting this update!

I may be late for the party, but can't the translated verbiage be provided to the dialog in the $form_attributes in AphrontDialogView.php:337, and read using form.getAttribute(key) in the js?

I will note that also the tech docs aren’t fully generated since there should be docs for most of the phorge/phabricator classes. Also the arcanist docs aren’t generated at all.

The Server also needs to periodically rebuild the Diviner Books to keep them in sync with Source Code. Eg. just set up a crontab entry. Or later, if more traffic is on the page: rebuild it once a commit affecting the Docs is committed.

The Herald rule should be project specific. If X happens then move task to Project->Column

What if, to get this functionality pushed through, we for now change the verbiage to two English words -- "Discard changes?"

Any chance that anyone has insight on D25015? Specifically, a way to get l18n (internationalization/translation) information from PHP into JavaScript from a minimalist approach

In T15010#1272, @MikeCripps wrote:

Really glad to see Phabricator will live on - I've previously managed some bugfixes in an external repo and would love to try to get them into upstream. I've run Phabricator instances for 7 of the last 9 years (and was unable to convince my previous employer to switch) so I've got a bit of experience on the managing side as well.

Really glad to see Phabricator will live on - I've previously managed some bugfixes in an external repo and would love to try to get them into upstream. I've run Phabricator instances for 7 of the last 9 years (and was unable to convince my previous employer to switch) so I've got a bit of experience on the managing side as well.

In T15043#1258, @CSharp wrote:

Maybe the "move to column" rule should only apply if the task is already assigned to the project, if it isn't, it gets ignored.

In T15043#1256, @speck wrote:

Making this an object rule is not possible as it has to be a Maniphest Task rule, which do not support object rules.
My main reason to explore this, is that without column types, we can only create rules like this "If task status changes to complete, then move task into column DONE in Project A.". Which means we have to create this rule for every project. In the rule builder UI we would also have to load a list of all project boards and their columns, which could be quite a few. The herald rule doesn't know with which project a task will be connected.

Ah okay - I was thinking this would be a Project rule rather than Maniphest, which would allow it to determine what possible columns can be used in the rule/action definitions.

In T15043#1256, @speck wrote:

I think this will work out technically but it feels a bit nebulous to me, in that the rule isn't really clear about what it's doing as it's very dependent on the project workboard that gets triggered. For example some workboards might be roadmaps/planning and want to have columns for e.g. inbox, backlog, next_version, etc. but other workboards might be categorical in nature rather than planning and there would be no overlap between what column types exist on those boards. I think a solution revolving around Project-based rules should be investigated - for example is it reasonable/possible to have a herald rule on a project that says, "when a task on this project board changes status to: x, then move to column y"?

Dug up some more info as well...

Making this an object rule is not possible as it has to be a Maniphest Task rule, which do not support object rules.
My main reason to explore this, is that without column types, we can only create rules like this "If task status changes to complete, then move task into column DONE in Project A.". Which means we have to create this rule for every project. In the rule builder UI we would also have to load a list of all project boards and their columns, which could be quite a few. The herald rule doesn't know with which project a task will be connected.

Ah okay - I was thinking this would be a Project rule rather than Maniphest, which would allow it to determine what possible columns can be used in the rule/action definitions.

In T15043#1251, @speck wrote:

Maybe the herald rule should only apply to specific objects? I think there’s a concept like this already where certain rules can only be made at the object level and not global level, possibly for similar reasons.

@Leon95 updated/included some translated text for calendar widgets under D25016 which may also be useful as reference. However one big difference is that the calendar widget has its own explicit view/behavior, whereas front-end workflows have multiple varying uses with different content.

Thank you! This looks good and the translation stuff you used here answers some questions for me about how to get translated text into the front-end, something that has come up in D25015. I'll try to get this landed shortly.

Came across someone else's notes about submit/merge queues - https://epage.github.io/dev/submit-queue/

• use weekdays.length

In T15043#1244, @TitanNano wrote:

I started to implement this as a new herald action. There is just one major problem. I would have to load all columns from every project and present them to the user. A user could then select one specific column of one specific project for his herald action... This seems kind of pointless to me. It's way too specific to be usable.

I think we first need some way to target project columns in a more generic way. If columns had a type, like "backlog" or "in_progress", then we could say, move this task on every related workboard into a column of type "in_progress".

This describes how to set up an IRC nick for matrix users: https://gist.github.com/LorbusChris/d44a5dd4671796cbf8528ca133dd909b