For the record we are up to 22 user in the channel currently.

So, I sent a community registration ticket back in July,and never heard back. They say they have a backlog. I think though it would be easier if we do a project registration and have it be done by somebody who can verify that they represent Phorge. (either through a file on the web root or else DNS)

@io for GitHub we have a task (T15046)

Hi all,

For the rest, I think they can be created on an as-needed basis.

In T15006#1429, @speck wrote:

I can provide more information later this weekend but I think it would help if we set up a virtual meeting with anyone interested in helping to get this done.

In T15006#1429, @speck wrote:

I can provide more information later this weekend but I think it would help if we set up a virtual meeting with anyone interested in helping to get this done.

• update celerity map

• update celerity map

No Problem. Lets drop the other Flags then.

• Use css flag for webkit

Also this Vagrant pattern should work first-run with vagrant up: https://we.phorge.it/T15027#852

In T15006#1429, @speck wrote:

I can provide more information later this weekend but I think it would help if we set up a virtual meeting with anyone interested in helping to get this done.

Yes - I could have some availability - Normally evenings (US Central Time) -

I can provide more information later this weekend but I think it would help if we set up a virtual meeting with anyone interested in helping to get this done.

@speck What can I help with here? - Are we waiting on upstream for anything currently?

Since it matches the other user select that’s setup in this file this is fine but it could just be the standard + WebKit one

• Add browser-specific css flags

The effort to rebrand Phabricator is going to result in changes to a lot of text which would likely invalidate a large number of translation entries.

At my company we have a similar situation however our management system is something we also actively develop. We solved this problem by configuring a web hook to hit an endpoint for the activities we are interested in having people track. The endpoint receives the transactions, pulls some additional info, and creates time-tracked activities for them in an aggregated list. Employees review the list and update time for each activity. It works pretty well and is not limited to activities from Phab allowing other systems to post activity to report, and for employees it’s nice because we can present the activity they’ve done and only require they estimate time spent as all other context is linked up.

Could you describe in more detail what this change is doing? - Because I am not familiar with celerity, I did read through https://secure.phabricator.com/book/phabdev/article/celerity/ for some background.

Thanks!

@Leon95 - I think this revision will be approved with just including the webkit alternate -

In D25015#826, @speck wrote:

I think that makes sense. Could you make a task to address this so we don’t lose track of it? Then let’s get this landed.

In D25023#827, @speck wrote:

Because of security issues related to this I’d like to have a verification of this type of change since this inherently defines the trust used by arc.

Maybe 2 core members independently verify the these certificate changes? Is there an fast way to verify the individual certs changed here?

Because of security issues related to this I’d like to have a verification of this type of change since this inherently defines the trust used by arc.

I think that makes sense. Could you make a task to address this so we don’t lose track of it? Then let’s get this landed.

Ah interesting. Could we follow the information you found and just include the WebKit one for now. I’m not as concerned with consistency after your findings. I appreciate that you investigated!

A friend of mine is able to reproduce this error on an updated Fedora 34 as well.

Things seem wildly inconsistent for this particular css string https://we.phorge.it/source/phorge/browse/master/?grep=user-select

It seems like only the WebKit variant may still be necessary. What do you think about updating both areas to just have the WebKit version in addition to the standard?

In D25022#774, @bekay wrote:

Then maybe just show the monogram when logged in.

I feel like we should move translation to a new revision, so we can move forward with this one.

I tested this revision on Edge just to make sure there were no negative side effects - No issues to report.

Let’s update to include the same set of user-select cross-browser as the blame info

I tried on Firefox on mac and there are tabs included

Happens with Firefox on Windows too. Chome and Edge are not including tabs, but when selecting from bottom to top and ending the selection while hovering a line number, one tab gets copied. This is also prevented with this patch.

l got this behaviour using Firefox on a Linux system. I have no Windows at Hand Right now, but will check it tomorow with different browsers.

I am not seeing this behavior. (Using Edge)

Oh my, sorry for the noise; my search-foo didn't find that.

This is a duplicate of T15051 and potentially solved with D25023

I'm down to do a https://meet.jit.si/ with someone else who is also down for this idea as well as the idea of translatable generic confirm() and alert() dialogs that can trivially go from pht() in PHP to JavaScript. Anyone?

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.