I'm 100% fine with that, I have no idea if there's some ugly interactions here, just wanted to chime in that we were affected too. The average skill level of users interacting with Phabricator makes the workarounds not a big deal in general (although I think an administrator can lock users out of the necessary IE settings to turn off compatibility mode)

T6547 was the other task, which points to a conversation on GH which no longer exists.

I vaguely remember these headers really not being very simple last time this came up, too, although maybe I'm misremembering and can't immediately find the discussion.

I think the incidence of this is so low (and should continue to fall in the future) that it's not worth bringing upstream.

Did you guys know that Microsoft is offering a FREE upgrade to Windows 10!
[ Schedule Upgrade NOW ] [ YES! ] [ W-o-w ] [ Reserve Your Windows 10 Today ]

I don't know if @epriestley thinks we should force the header at the PHP level or not. We get roughly 1 report of this per year. Win7 was EOL'd in Jan 2015, so I'm surprised people are still installing it fresh.

This only affects badges awarded before we began tracking who awarded them. Badges is a prototype application, and I don't think it's worthwhile to maintain code to do something nicer in this case, since the number of affected awards is maybe in the realm of 200 worldwide for all time, of which 80 are on this install.

The meta header causes all IE versions to re-render the page twice, incurring a performance penalty.

Yeah, we're also affected by this... it's mostly a non-issue since no one really uses IE but IE11 renders incorrectly in IE7 compatibility mode since the Phabricator server is determined to be in the intranet domain.

The phd user has /bin/false as it's shell on our production instance, and it seems to work fine.

T6806 might be ripe to resolve one way or another, too.

Thanks for looking into this @epriestley!

From T10822, we currently choose [Changed Subscribers] as a stronger action than [Merged] for tasks in some cases in email subject lines. This is probably not the correct heuristic, [Merged] is normally a strong action.

(@eadler's retitle of this bug is fine and I agree that [Merged] should be a stronger action than [Changed Subscribers], I'll make a note about this on T8952.)

We'll take this feedback into account when making future changes to workboards.

When a group of transactions makes several changes, we guess at which change is most likely to be interesting and include that change as the action in the subject line.

The issue may be more general than the new title, but this is more actionable (I think).
Note that I don't work for Phacility.

You can either solve this by not sending such emails when a task is merged (but they you don't notified of merged tasks which is bad), or by having a dedicated subject / body for merged task notifications, which then:

1. solves this bug
2. improves the UX since you now get a notification email that actually reflects the action that happened

I really don't think this task should be closed. This is a user experience bug, independently of any underlying good reason there might be in the implementation.

T9412 might be helpful in understanding this in the future.

You're getting this cause a task was merged, not because of the changed subscribers. The logic roughly looks like if (get mail for any reason) { send entire email; }. If you look at the full headers you should see a list of 'mail-tags'. If you're notifications are set to email for any one of those tags you'll get the email.

It looks like the changed subscribers results from a merged task, so maybe this case is not handled?

I've been looking at this the last couple of days as it's a pain point for me -- I'd like to host my repositories on Diffusion, and I would like to stay with Mercurial rather than git..

In T9897#161715, @chad wrote:

Looks like maybe Macros aren't visible to outside people. Found https://phabricator.wikimedia.org/phame/post/view/1/what_s_new_lots_of_improvements_on_phabricator.wikimedia.org/

Problem solved, had to add a:
case "es_ES"
on line 166 of PhutilTranslator.php. Otherwise it fails, and the catch Exception also fails as Language is not initialised.

This is now in production and appears to be working properly.

Thanks for the report! I think D15719 should fix this; it should be available in master later today and stable in about 24 hours.

Thank you for the update, I didn't think of using Conference. I haven't found anything that directed me to /status, just had the url as part of our validation after an upgrade, and went to use it.

Not managing to get it working. I see the locale, but when creating the PhabricatorSpanishSpainTranslation (I think you put Spanish instead of Spain by error), and renaming the class that way, translations aren't shown.

There's a new status panel in Config → Notification Servers. I'm consolidating cluster status information there.

Following the upgrade, is there a way to send test notifications and /notification/status/ is now a 404 error?

Amazing quickness with your comments. Will start translating most used sentences, and when I reach something useful for others I will upload it.

Yup, though I want to point out in this case the default IE 11 install on win7 forces compat mode on intranets. so it's more a case that your administrator needs to force it off, or you need to do it yourself to get phab working.

For completeness, see http://stackoverflow.com/questions/26346917/why-use-x-ua-compatible-ie-edge-anymore

IE7 and IE8 were end of lifed in January. I think most sites wouldn't work anymore with Compatibility Mode on. If a administrator forces it on, it's on. Not much we can do.

We could maybe git ls-tree -r -d -- <tree> and then parse that. Still a lot of stuff, but somewhat less than the other approaches -- it only takes about 20ms to generate for phabricator/. If that output more than 5K paths or whatever we could give up and fall back to an unfolded list.

Looks like this will require either an uncomfortable number of calls to git ls-tree, or a call to git ls-files followed by a possibly very large filtering and groking of its output.

A big chunk of this is finally in production and seems to be working, which I'm thrilled about.

The best might be to have a configuration option for this linter to add extra allowed characters.

This comment was removed by the ghost of Christmas past.

Feel free to contribute back to the Paste file in P1970 so others may benefit.

I've added the base language to libphutil, This should make things a little easier. Your next steps would be, if you've already set up Phabricator, to add a new file with your translations.

There are a few parts to this. The good news is everything, or at least 98% of everything is translatable, the bad news is we don't ship anything other than silly translations like Pirate. Basically if you want to start and share a Spanish (international?) version, we can help you get started. Let me write this up as a wiki doc, so it's more easily found by others.

This is happening generally as part of T10751. I'm just going to close this out since I don't think it's useful as a separate task.

You don't need any plugins with staging. Just set up a parameterised build, use a parameter for the commit and call directly from harbormaster. That's reason for staging repos, regular git tooling can work with them.

The logs themselves are a bug that's been around for a while, but I think they're from a race condition that I believed only caused things to log messages with no ill effects.

Hmm, this is pretty interesting. There was a configuration change right at the time of impact: