Fri, Aug 16
Thu, Aug 15
As I mentioned here, I don't think this change is necessary. It only makes sense if there is more than one link that needs to be displayed, but since there is only a single link I'm not not sure why we'd make this change. To me it's really clear that it's a link by it's hover state and cursor change.
Wed, Aug 14
would we rather:
- Enable server-rendering which will allow us to display the message in the user’s language. This will require splitting the tool into two tools (which is trivial, imho, and can remain in a single repo if we want): https://lists.wikimedia.org/pipermail/cloud/2019-August/000774.html
- Leave the app as “static” and display the message in all languages?
Mon, Aug 12
Fri, Aug 9
I gave up and split the users. :)
Thu, Aug 8
FYI We discussed a possible different direction for this, I'll submit a patch for discussion.
It will use the languages in order, you can specify more than one language in Chrome. If English comes before Hebrew, that is the one that will be used. :)
Wed, Aug 7
Core Platform Team Would be nice to get a code review of this from your team. :)
Tue, Aug 6
Mon, Aug 5
Sat, Aug 3
Fri, Aug 2
Tue, Jul 30
Hmm, I suppose this is more of a product decision for @Niharika
Mon, Jul 29
Sat, Jul 27
Fri, Jul 26
Thu, Jul 25
@dmaza & @Mooeypoo Today @Tchanders and I were talking about this task, and we thought that perhaps it would be better to deprecate the GetBlockedStatus hook (See: T229035). Basically, while GetBlockedStatus technically works it's not ideal. Primarily because it allows an extension to mutate the entire User object rather than just the block. Also, it conflates adding blocks with altering (changing or removing blocks).