Page MenuHomePhabricator

Offer contentlanguage targeting for CentralNotice banners
Open, NormalPublic

Description

CentralNotice banners are displayed per language. We usually mean for a Polish translation of a banner to be displayed at the Polish Wikipedia, the German translation to be displayed at the German Wikipedia, etc.

If Universal Language Selector is set to use the same language as the wiki's content language, then this works as expected.

However, if ULS is set to use a language that does not match the content language of the wiki (e.g., English on the Polish Wikipedia), then ULS's language is the one that determines which translation of a banner you see (probably good) and, for banners that are not applicable to 100% of projects, whether you see one at all (bad).

This means that a banner intended only for the German Wikipedia will display for any German-using editor at any of the Wikipedias (e.g., Chinese), and that a Chinese-language banner intended for all editors at the Chinese Wikipedia will not be displayed to anyone who has changed the ULS settings to anything other than Chinese.


Version: unspecified
Severity: enhancement

Details

Reference
bz51475

Event Timeline

bzimport raised the priority of this task from to Low.
bzimport set Reference to bz51475.
bzimport added a subscriber: Unknown Object (MLST).

To be clear this isn't just a ULS thing, the current default rule for CN is to always use the 'user' language rather then the content language. This is, essentially, a request to change to contentlanguge :)

Rephrasing summary.

awight set Security to None.
Pcoombe raised the priority of this task from Low to Normal.Jan 23 2015, 11:55 PM

This also means that CentralNotice content doesn't get converted to the correct language variant. For example:

@AndyRussG: I just noticed that CNBannerChoiceDataResourceLoaderModule might have a caching bug here... If context->getLanguage() is UI language, and we're caching for project/content language combination, then there's a chance of incorrect data getting into the cache?

Change 197741 had a related patch set uploaded (by Awight):
CentralNotice uses content rather than interface language

https://gerrit.wikimedia.org/r/197741

If we decide this is the right thing to do, here's a patch... https://gerrit.wikimedia.org/r/197741

I'm not sure how to solve the variant issue, however. I don't think the content language variant is available to the ResourceLoader startup module, nor would it be used to split the cache?

Gotcha for local testing: on the production site, ?variant=tg-latn will set the RL lang=tg-latn param, but I don't know what the correct LocalSettings config would be to make that happen. Locally, I see lang=tg when I use variant, and lang=tg-latn if I use the uselang param instead.

@Nemo_bis
I'd be curious what you think of this feature request, do you agree that it makes more sense than targeting banners by MediaWiki interface langauge?

@Nemo_bis
I'd be curious what you think of this feature request, do you agree that it makes more sense than targeting banners by MediaWiki interface langauge?

No. I can't imagine a case in which it would make sense, other than as workaround for T50956.

@Nemo_bis, could you clarify your comment?

Imagine that I go to the Italian Wikipedia. Imagine that my interface language is set to English there. Imagine that CentralNotice is running banners in Italian (but not English), specifically for the Italian Wikipedia, about something that affects that particular wiki.

Should I (a) see the banner in Italian or (b) see nothing?

I am not sure if this proposal is a good idea in the way it has been described above: as I read there to replace the system from user language to content language. If it is additional to the current setup, maybe it is possible, but in replace of it I am against.

The strength of the CentralNotice system is that it communicates to the user in the language they have set for themselves. The proposal above seems to aim in removing this strength...

@Romaine
Great points, I think you're right that we need to offer both flavors of language targeting.

awight renamed this task from Use contentlanguage for CentralNotice banners to Offer contentlanguage targeting for CentralNotice banners.Oct 27 2015, 10:08 PM

I think we need to separate receiving from sending. The problem is that the sender isn't thinking in terms of people who speak Dutch. The sender is thinking in terms of people at the Dutch Wikipedia.

Imagine that we are posting a message that is available in Dutch (only) and that is useful for all contributors at the Dutch Wikipedia (only). (Perhaps we are announcing a local election.) What we have now is this:

Project the user is atLanguage the user has setResult
DutchDutchmessage in Dutch (good!)
DutchEnglishno message (bad!)
EnglishDutchmessage that is irrelevant to this user (bad!)

What we want is this:

Project the user is atLanguage the user has setResult
DutchDutchmessage in Dutch (good!)
DutchEnglishmessage in English if English is available, and a message Dutch if English is not (improvement!)
EnglishDutchno message (improvement!)
Restricted Application added a subscriber: Cosine02. · View Herald TranscriptDec 27 2016, 6:32 AM
Jseddon added a project: Fundraising-Backlog.
mmodell removed a subscriber: awight.Jun 22 2017, 9:33 PM
Jseddon added a comment.EditedMay 24 2018, 5:03 AM

This issue affected T194939 and in place of CentralNotice three seperate sitenotices will be used

Change 197741 abandoned by Awight:
CentralNotice should use content rather than interface language

https://gerrit.wikimedia.org/r/197741