Support for 3rd party users choosing a different fallback based on configuration, rather than a live-hack, is possible but isn't a trivial change. I don't see it as a blocker at this point based on the information I have.

I approve giving Mark access to stat1002

In T52355#2079713, @Esanders wrote:

@Ironholds the page has become a disambig since you filed. Looking at the history were you linking to https://en.wikipedia.org/wiki/Fulgencio_(Modern_Family) originally?

I approve giving Subbu access to ruthenium.

Approved.

As James's manager I approve.

I'd also like to suggest we try to achieve a happy medium. However, I'd also be in favor of reconsidering our approach in general here. I'm not a fan of how much color-coding we use in our interfaces. The occasional red button, used only when there's real danger in clicking it, is one thing - but I'm suspicious about color-coding all buttons. I'm pretty sure most users don't really understand why the buttons are different colors, and it just makes it harder to locate controls.

I, Trevor Parscal, hereby approve of giving Bartosz Dziewoński membership in the "researchers" and "statistics-users" groups.

I would support moving the MIDI file link to a lower-visibility affordance, such as a small icon or text link with a "Download MIDI file" tooltip or label respectively. I'm biased toward not wanting to dispense with this neat functionality because, as Ed put it, I've "actually used a synthesizer before". Nonetheless, if we can just make it far less prominent I think that would be a good balance.

Approved.

What about adding a config to RLIM to load both directions? For content-language specific icons, we will want to load both, but for interface-language specific icons we won't.

I propose that we add a new feature to widgets for them to have a screen reader label which is always hidden, and we set that using an aria attribute or hidden text nodes which are set manually using a specific property, or automatically if a manual setting is not specified using the title or label text if either exists.

There are 2 potential models here, and the current implementation is mixing them in a bad way.

Can we get some information about how or if this affects VisualEditor?

@TrevorParscal and family need a cab to the airport, leaving around 10:15. Our flight is at 14:45 from terminal 2, but we'd like to take some extra time to deal with the terminal 2 construction and buy some things at the airport. (same as @Catrope et al)

Approved.

Reproduced with Safari 8.0.4 on MacOS X 10.10.2.

Could not reproduce in Firefox 32, 34, 36 or Safari 8 on MacOS 10.10.2

Resolved in patch https://gerrit.wikimedia.org/r/#/c/197797/

The ideal system would be to use TemplateData to specify which parameters should be used to generate the name from, but in cases where there is no such data we still need a sensible fallback, and the current system has the advantage of using latin numbers, which work with other languages well.

Safari appears to block copy operations when the selection is collapsed. This doesn't occur if the selection is covering an element styled as "user-select: none", so I suspect there's a way to get around this without any browser selection rendering.

In the short term, let's just show the user an error if for any reason their query didn't result in one or more options. The error can say something like "We weren't able to automatically create a reference, please create your reference using a form".