?action=delete doesn't show the reasons listed on https://no.wikibooks.org/wiki/MediaWiki:Deletereason-dropdown. It shows: spam, Vandalisme, Opphavsrettsbrudd, På forfatters forespørsel & Råtten omdirigering.
See also: T50956: Can't override optional message in all languages with local customisation
| Subject | Repo | Branch | Lines +/- | |
|---|---|---|---|---|
| Set valid content language for Norwegian wikis | operations/mediawiki-config | master | +10 -1 |
| Status | Subtype | Assigned | Task | ||
|---|---|---|---|---|---|
| Resolved | Krinkle | T151247 Message overrides not working on no.wikibooks.org | |||
| Resolved | Krinkle | T126146 Norwegian messages inContentLanguage look for on-wiki overrides at the /nb subpage, not the root page |
> var_dump( $wgContLanguageCode ); string(2) "no" > var_dump( $wgContLang->getCode() ); string(2) "nb"
Wait, what?
I made https://no.wikibooks.org/wiki/MediaWiki:Deletereason-dropdown/nb for this case
WMF config is broken, I don't know how we missed that: https://gerrit.wikimedia.org/r/#/c/48077/1/includes/DefaultSettings.php
Change 277519 had a related patch set uploaded (by Nikerabbit):
Set valid content language for Norwegian wikis
Does anyone from the local community want to check the patch before I schedule it for SWAT deployment? Basically I am setting the content language code to nb instead of no. The first just fallbacks to latter, so there should be no visible change other than fixing this bug.
https://gerrit.wikimedia.org/r/252009 tries to apply the mapping from $wgDummyLanguageCodes to $wgLanguageCode by using $wgContLang->getCode().
If I remember correctly in production this might not only need a DB change but also an update of the cache or file backed representation if it is not a cache. See T113034 for what will make this less insane.
@JanZerebecki Please clarify what needs to be done so that we can deploy https://gerrit.wikimedia.org/r/277519 to fix T151247 (UBN!).
Or could those DB updates be done at a later time?
I don't think Jan is actively following stuff in these days so you may want to look out for other reviewers.
Change 277519 abandoned by Nikerabbit:
Set valid content language for Norwegian wikis
Reason:
I have waited over three months. Please restore this patch when it is going to worked on, or upload it in your name.
This is blocking an UBN! task, so setting this appropriately. Please re-triage accordingly if the blocked task is not actually UBN! or this is not actually a blocker.
I don't see how this is Wikidata related. Jan was reviewing this when he was a WMDE employee. His -1 could easily have been overruled by someone else, if you believe he was wrong and the patch correct.
I also don't see how a months old patch can become "unbreak now". What broke today?
I can confirm that this is also a bug for Wikimedia Norge's wiki. For example, the sidebar's content matches what's in [[MediaWiki:Sidebar/nb]], not [[MediaWiki:Sidebar]], which is especially weird considering that AFAIK MediaWiki:Sidebar won't change based on language (it's a definition message much like [[MediaWiki:Common.css]]). Also, to enable local uploads there we had to put some content in [[MediaWiki:Licenses]], but that didn't work until we tried putting it in [[MediaWiki:Licenses/nb]].
It's not that anyone believes he is wrong, it's more the fact that Jan left that comment, making everyone nervous that the patch would break things, and then he never followed it up. Given the lack of action here, it seems that only Wikidata team members, and possibly SRE people, might know the impact of changing a wiki's content language on Wikidata DB records.
Adding SRE in the further hope of un-stalling this task...
@greg: Looks like the urgent priority in T151247 is because stuff got deleted (and restored by @Krinkle). I would suggest to create a separate ticket for this, otherwise it will happen again.
@TTO: Why do you think this has something to do with "Wikidata DB records"? The patch in question here changes operations config for some Norwegian wikis. Not Wikidata. Not even MediaWiki core.
Wikidata is an international project like Wikimedia Commons. It supports whatever languages MediaWiki core supports (plus a few additions, but this is not relevant for this ticket). I just checked: currently all Wikimedia wikis allow me to set my user interface to both "nb" and "no" in my users settings. I don't know if it makes sense to have both, if one is meant to be an alias. But as long as MediaWiki's Language class lists both, Wikidata will support both, and not forward one to the other. The moment one is dropped, Wikidata will not allow users to edit values in that language any more. The community will then run a bot and migrate or delete the outdated values. But nothing will break and nothing will be blocked because of this.
The fact that @JanZerebecki's short comment made you "nervous" is, in my opinion, a strong hint that it was probably a good decision to not merge the patch, at least not at that time. Things may have changed since then.
The only thing the Wikidata team can do is to remove "nb" from the list of languages MediaWiki-extensions-WikibaseRepository supports for labels, descriptions, aliases and monolingual text values. Please tell us.
Because Jan seemed to imply that it did have something to do with sites data, which is Wikidata-related, and didn't clarify. It's not reasonable to expect me (or any other developer who knows nothing about Wikidata internals) to be able to understand the ramifications of such statements, so a "better safe than sorry" principle is followed.
But nothing will break and nothing will be blocked because of this.
That is very helpful; thank you.
Unfortunately, the last SWAT of the year has passed us by, so we may have to wait until January to deal with this.
The only thing the Wikidata team can do is to remove "nb" from the list of languages MediaWiki-extensions-WikibaseRepository supports for labels, descriptions, aliases and monolingual text values. Please tell us.
That might be worth discussing in another task :)
"Sites" is not a first-class Wikibase concept. It was meant to replace core's interwiki map. This never happened, so we are still stuck with at least three different places that need to be synced whenever a sister project is added, removed or changed. It appears Jan was talking about this. From what I know "no" got added everywhere in the meantime (@aude or @hoo, can you verify?).
See T113034: RFC: Overhaul Interwiki map, unify with Sites and WikiMap for the current approach to resolve this on a higher level. Also pinging our architect @daniel as he is driving this.
No, no, no, no, no, no, no. Don't even consider doing that. I don't know why Wikidata was brought into this in the first place, this bug has absolutely nothing to do with Wikidata.
Are you saying "Sites" or some (other) aspect of Wikibase (database table? changed via maintenance script?) does or does not need to be updated when the content language (wgLanguageCode) is changed for Norwegian wikis as per https://gerrit.wikimedia.org/r/#/c/277519/1/wmf-config/InitialiseSettings.php?
@Krinkle: The sites table must be updated to reflect the change from https://gerrit.wikimedia.org/r/277519. It has a site_language column that contains no for the sites in question here. These should be updated to nb.
This is not a blocker for anything, as far as I'm aware of, but should not be forgotten.
As said this is not exclusive to Wikibase. The sites table is a core concept. It was introduced by the Wikidata team a long time ago. It's not used much outside of Wikidata, and will probably be removed some day (see T113034). A few Wikidata concepts rely on it, like the "in other projects" sitelinks, as well as ArticlePlaceholder. I checked and believe that nothing will break if sites is not updated immediately with the config change. Should be in sync anyway.
Mentioned in SAL (#wikimedia-operations) [2017-01-04T14:32:45Z] <zfilipin@tin> Synchronized wmf-config/InitialiseSettings.php: SWAT: [[gerrit:277519|Set valid content language for Norwegian wikis (T126146)]] (duration: 00m 41s)