Change #1060448 had a related patch set uploaded (by Urbanecm; author: Urbanecm):

[mediawiki/extensions/Babel@master] Move configuration to CommunityConfiguration

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

Change #1060447 merged by jenkins-bot:

[mediawiki/extensions/Babel@master] Do not use global keyword to access Babel config

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

Change #1060886 had a related patch set uploaded (by Urbanecm; author: Urbanecm):

[integration/config@master] [Zuul] Add CommunityConfiguration as Phan dependency for Babel

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

Change #1060886 merged by jenkins-bot:

[integration/config@master] [Zuul] Add CommunityConfiguration as Phan dependency for Babel

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

After that we should assist each community to migrate configuation to local site, and test how Babel Autocreate will work properly (it is currently blocked in multiple projects, see https://www.mediawiki.org/wiki/Special:CentralAuth?target=Babel+AutoCreate).

Change #1061128 had a related patch set uploaded (by Urbanecm; author: Urbanecm):

[mediawiki/extensions/Babel@master] [DNM] Use CommunityConfiguration by default

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

Using Community Conifiguation in itself won't solve any issues involving Babel AutoCreate. But most of those blocks are due to issues that were fixed a while ago, but the projects haven't noticed or cared.

In T328171#10055168, @Bugreporter wrote:

After that we should assist each community to migrate configuation to local site,

Absolutely. Migrating all config is of course planned as well.

and test how Babel Autocreate will work properly (it is currently blocked in multiple projects, see https://www.mediawiki.org/wiki/Special:CentralAuth?target=Babel+AutoCreate).

Would you mind providing more details? Is there something we should verify before deployment?

In T328171#10055417, @Pppery wrote:

Using Community Conifiguation in itself won't solve any issues involving Babel AutoCreate. But most of those blocks are due to issues that were fixed a while ago, but the projects haven't noticed or cared.

Absolutely. Maybe we should migrate blocks to BabelAutoCreate turned to false, and then ask communities to verify whether the autocreation can be re-enabled? Would that make sense?

In T328171#10055417, @Pppery wrote:

Using Community Conifiguation in itself won't solve any issues involving Babel AutoCreate. But most of those blocks are due to issues that were fixed a while ago, but the projects haven't noticed or cared.

Yes, and the community configuration will help projects easily turn the bot back on if needed.

In T328171#10055488, @Urbanecm_WMF wrote:

Absolutely. Maybe we should migrate blocks to BabelAutoCreate turned to false, and then ask communities to verify whether the autocreation can be re-enabled? Would that make sense?

I don't think it's a good idea :) Bots are either blocked physically or disabled in the settings, there is no need to disable the bot for all projects.

In T328171#10055504, @Iniquity wrote:

In T328171#10055488, @Urbanecm_WMF wrote:

Absolutely. Maybe we should migrate blocks to BabelAutoCreate turned to false, and then ask communities to verify whether the autocreation can be re-enabled? Would that make sense?

I don't think it's a good idea :) Bots are either blocked physically or disabled in the settings, there is no need to disable the bot for all projects.

Oh, I didn't want to turn the bot off everywhere. I was thinking about checking projects where it is blocked, and disable it (in CommunityConfiguration) only on those projects. Then, the bot can be safely unblocked, and CommunityConfiguration becomes the source of truth. Would that make sense?

In T328171#10055507, @Urbanecm_WMF wrote:

In T328171#10055504, @Iniquity wrote:

In T328171#10055488, @Urbanecm_WMF wrote:

Absolutely. Maybe we should migrate blocks to BabelAutoCreate turned to false, and then ask communities to verify whether the autocreation can be re-enabled? Would that make sense?

I don't think it's a good idea :) Bots are either blocked physically or disabled in the settings, there is no need to disable the bot for all projects.

Oh, I didn't want to turn the bot off everywhere. I was thinking about checking projects where it is blocked, and disable it (in CommunityConfiguration) only on those projects. Then, the bot can be safely unblocked, and CommunityConfiguration becomes the source of truth. Would that make sense?

Oh, sorry, I misunderstood you. Yes, that makes sense :)

Change #1061145 had a related patch set uploaded (by Urbanecm; author: Urbanecm):

[integration/config@master] [Zuul] Add CommunityConfiguration as a CI dependency for Babel

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

Change #1061145 merged by jenkins-bot:

[integration/config@master] [Zuul] Add CommunityConfiguration as a CI dependency for Babel

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

Add MLEB project since once this task is resolved we need to add CommunityConfiguration to MLEB as a dependency of Babel. Feel free to create a dedicated task but in my opinion this is a small change.

In T328171#10087096, @Bugreporter wrote:

Add MLEB project since once this task is resolved we need to add CommunityConfiguration to MLEB as a dependency of Babel. Feel free to create a dedicated task but in my opinion this is a small change.

While you're very welcome to add CommunityConfiguration to MLEB, I think that change is explicitly designed to use CommunityConfiguration as an optional dependency. So it should be fully possible to keep using Babel without it.

This is now ready technically-speaking. We reached out to Language, verifying this is OK to go ahead. We will proceed based on their response.

Can you clarify what is the fallback for MediaWiki messages when CommunityConfiguration extension is not present? I looked at the patch, but it seems to only include a few configuration variables, not matching the analysis in the task summary.

Because of T356847: Changing MediaWiki Language Extension Bundle (MLEB) Release Process I don't see any backwards compatibility blockers.

In T328171#10116036, @Nikerabbit wrote:

Can you clarify what is the fallback for MediaWiki messages when CommunityConfiguration extension is not present?

Certainly! If CommunityConfiguration is not present (or is present, but explicitly disabled via $wgBabelUseCommunityConfiguration = false, which is the proposed default), then Babel would fall back to the status quo and load its configuration from LocalSettings.php.

I looked at the patch, but it seems to only include a few configuration variables, not matching the analysis in the task summary.

I deliberately excluded (for now) the config located in on-wiki messages. I did that, because migrating those is not as straightforward as the LocalSettings variables. For LS variables, the change swaps one Config object for another, which is fairly straightforward. For on-wiki messages, all their usages need to be changed. That can be done as well, but in the second stage – it is effectively a fully separate migration, as the data source is different.

Now that I look at the patch again, I see it also excludes BabelAllowOverride (mistakenly called , BabelCategorizeNamespaces`, and BabelAutoCreate. As for BabelAllowOverride, I believe the analysis in the task description is incorrect – once the migration to CommunityConfiguration would be fully completed (including the i18n messages), that variable would make no sense (in a way, it would be replaced by BabelUseCommunityConfiguration, which cannot be in CommunityConfiguration for obvious reasons). I'll update the description. For the other two, that is an oversight – I'll include them in the current patch as well. Thank you for pointing this out!

Hopefully this clarification makes sense to you. If there is anything else we should clarify, please feel free to let us know.

I didn’t fully understand from your reply what the fallback mechanism will be for on-wiki messages. You mentioned it's a separate migration, but could you clarify? Is the plan to turn them into regular configuration variables that can be set either via LocalSettings.php or CommunityConfiguration (but not both)?

It seems we need to decide whether to include CommunityConfiguration as part of MLEB, and a reasonable fallback would keep both options open. By the way, have you considered bundling your extension with the tarball releases?

In T328171#10117087, @Nikerabbit wrote:

I didn’t fully understand from your reply what the fallback mechanism will be for on-wiki messages. You mentioned it's a separate migration, but could you clarify? Is the plan to turn them into regular configuration variables that can be set either via LocalSettings.php or CommunityConfiguration (but not both)?

Since we would have to support the current behaviour until the migration code runs, the fallback for on-wiki messages would be on-wiki messages. In other words, there should be no change expected unless wgBabelUseCommunityConfiguration is true. Internally, this would probably be accompanied by moving towards a Config implementation, since that is what CommunityConfiguration interfaces against, but there is no need to make them LocalSettings.php variables unless we want to.

To summarize, with wgBabelUseCommunityConfiguration being false, Babel would behave just as it does now and fetch some config from LocalSettings and some config from on-wiki messages. Once wgBabelUseCommunityConfiguration is turned to true, Babel would get all its config from CommunityConfiguration.

Does this clarify?

It seems we need to decide whether to include CommunityConfiguration as part of MLEB, and a reasonable fallback would keep both options open.

Sounds good. What should be the decision making process here? What would be the (dis)advantages of (not) doing so?

By the way, have you considered bundling your extension with the tarball releases?

Yes, with the conclusion of leaving that eventually for later, once the need for bundling arises. Would bundling the extension now help us with something Babel-related?

In T328171#10117110, @Urbanecm_WMF wrote:

To summarize, with wgBabelUseCommunityConfiguration being false, Babel would behave just as it does now and fetch some config from LocalSettings and some config from on-wiki messages. Once wgBabelUseCommunityConfiguration is turned to true, Babel would get all its config from CommunityConfiguration.

Does this clarify?

Yes.

What would be the (dis)advantages of (not) doing so?

Some quick thoughts:

• Depends on what third party users would prefer to use (something that we don't know, and would be hard to find out)
• We currently don't have "external" dependencies (though we might need to consider including composer deps soon, there is a task about it). Bundling an extension that isn't directly under our maintenance umbrella could complicate things if there are issues.
• If we bundle it now, we could ensure consistent behavior whether or not they have CommunityConfiguration from other sources now or in the future.

By the way, have you considered bundling your extension with the tarball releases?

Yes, with the conclusion of leaving that eventually for later, once the need for bundling arises. Would bundling the extension now help us with something Babel-related?

No, not immediately at least. We have also though of proposing to bundle (some or all) MLEB extensions with the tarball and discontinue MLEB as an independent thing.

It seems we need to decide whether to include CommunityConfiguration as part of MLEB, and a reasonable fallback would keep both options open.

Sounds good. What should be the decision making process here?

I would sidestep this question by saying that I don't see anything from our side that should block going forward with this task. The decision about MLEB bundling can be delayed until later.

In T328171#10116088, @Urbanecm_WMF wrote:

Now that I look at the patch again, I see it also excludes BabelAllowOverride (mistakenly called , BabelCategorizeNamespaces`, and BabelAutoCreate. As for BabelAllowOverride, I believe the analysis in the task description is incorrect – once the migration to CommunityConfiguration would be fully completed (including the i18n messages), that variable would make no sense (in a way, it would be replaced by BabelUseCommunityConfiguration, which cannot be in CommunityConfiguration for obvious reasons). I'll update the description. For the other two, that is an oversight – I'll include them in the current patch as well. Thank you for pointing this out!

Hi! Thanks for the fix! @Pppery, can you please check if the conclusions about BabelAllowOverride are correct :)

Urbanecm seems to be correct on that issue to me.

Looking at the code review history I only coded that variable so I could set it to false in the test suite for ease of testing the other parts of the extension without having to sprinkle knowledge of the override syntax. I can't imagine why any wiki would want to set it to false, and especially not with community configuration where the same people who could make use of it can set it to true.

Change #1061128 abandoned by Urbanecm:

[mediawiki/extensions/Babel@master] [DNM] Use CommunityConfiguration by default

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

Change #1060448 merged by jenkins-bot:

[mediawiki/extensions/Babel@master] Move configuration to CommunityConfiguration

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

Based on a discussion with @Sgs, I scoped this task down to only include LocalSettings.php variables. Moving messages to CommunityConfiguration is now filled as T374342: Use Community Configuration in Babel extension: interface messages, and can be worked on at any point after this block of work gets completed.

Do we know cases where wgBabelDefaultLevel is not set as N?

In T328171#10129638, @Trizek-WMF wrote:

Do we know cases where wgBabelDefaultLevel is not set as N?

I'm not aware of any. Both production as well as beta seem to have it as "N", with no overrides:

'wmgBabelDefaultLevel' => [
	'default' => 'N',
],

Should we keep it as a community configurable value?

I can't imagine a scenario using it (but I'm limited to my imagination); I see more cases where it could confuse users.

Change #1071809 had a related patch set uploaded (by Urbanecm; author: Urbanecm):

[mediawiki/extensions/Babel@master] CommunityConfiguration: Remove BabelDefaultLevel

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

In T328171#10129719, @Trizek-WMF wrote:

Should we keep it as a community configurable value?
I can't imagine a scenario using it (but I'm limited to my imagination); I see more cases where it could confuse users.

On second thought, we should probably remove it. I also cannot find any reason for changes here, and language-knowledge levels are reasonably well understood among the wikis. I uploaded a patch to that effect, which can be merged if there is no objection to removal.

I removed the line from the task description.

Documentation should be updated:

• Extension
• Community Configuration (using the interface messages)

Hi!

Just to be clear why I wanted Babel to have a CC: when the settings are in LocalSettings.php, everyone is afraid to come to the Phab and change them + no one ever knows what features are available in LocalSettings.php. Therefore, in my opinion, the CommunityConfiguration should reflect all the possibilities that extension provide and that can potentially be used in projects.

Second thought, this extension is used not only in the WMF wikis, if we want to prohibit users in WMF wikis from changing the "default level", then perhaps it is worth making a CC flag - "not used in the WMF".

So I'm not sure that removing the setting from the configuration and leaving it in the extension is a good idea :)

1. For "Category names per language level": A warning is required that these values ​​should be changed carefully, since when changing, old categories are not deleted, and new ones are not created automatically if the bot is disabled.

Be careful when changing values ​​from the default ones, especially if you already have language categories created in your project: they will not be removed automatically.

2. For "Automatically create babel categories": add information about the bot, you can even add it to the label.

Automatically create babel categories by Babel AutoCreate bot.

Change #1071809 merged by jenkins-bot:

[mediawiki/extensions/Babel@master] CommunityConfiguration: Remove BabelDefaultLevel

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

In T328171#10135789, @Iniquity wrote:

Second thought, this extension is used not only in the WMF wikis, if we want to prohibit users in WMF wikis from changing the "default level", then perhaps it is worth making a CC flag - "not used in the WMF".

So I'm not sure that removing the setting from the configuration and leaving it in the extension is a good idea :)

This is precisely why I needed a fresh perspective to go against my limited imagination. ;)

I would no include it in the default WMF CC though, for the reasons I gave (confusion, possibility of errors), but keep it as an option for third-party wikis.

@Etonkovidova FYI, this is now available for QA on all beta wikis (T374611: Switch BabelUseCommunityConfiguration to true on Beta cluster).

I agree with @Trizek-WMF this doesn't really make sense in WMF's case. I'm also questioning how much useful would this option alone be even on third party wikis. The default language level is intended to be the highest one existing. In the 1-5 and N levels system, this is always going to be N.

However, in LocalSettings.php, BabelCategoryNames allows you to not only specify the category names; it also allows you to use a different language levels system. This is not possible in CommunityConfiguration (the set of language levels is fixed to 1-5 and N at the moment). If a third party wiki is using different language levels than we do, it makes sense (to them) to also override the default level, as they might use different highest level than N (in fact, N might not even exist as a level).

Fully bringing this flexibility to CommunityConfiguration is not possible at this moment (we would need to add quite a lot of features to CC itself to make that possible). In the absence of any data on whether this is going to be needed by any third party, I think it would be best to wait for a possible future feature request to be filled on this, given the investment this would take.

While having just the default level in CC is certainly possible, I'm not sure whether that would be useful (it seems weird to set the default level in the middle; the only use case might be using the _lowest_ level as the default, rather than the _highest_). Of course, if a request comes for that, we can consider, but if not, it doesn't look like an useful thing to invest our resources to.

What do you think about leaving this conversation for later (when and if the feature request is filled), @Iniquity?

In T328171#10139852, @Trizek-WMF wrote:

I would no include it in the default WMF CC though, for the reasons I gave (confusion, possibility of errors), but keep it as an option for third-party wikis.

Third party wikis can already override any part of CC they want, and expand the scope of it (or limit it if they so desire). So, this should be already the case, I think.

In T328171#10140564, @Urbanecm_WMF wrote:

What do you think about leaving this conversation for later (when and if the feature request is filled), @Iniquity?

I agree leaving this conversation for later, for the WMF's wikis it doesn't matter. But just in case, I'll clarify that the highest level is 5 (professional), not N (native).
And some wikis might want to make 0 the default, so that users can specify their level of knowledge.

Hi, I haven't followed the discussions and the detailed technical work closely. I want to set the values in my home wiki but I can't find it in https://fa.wikipedia.org/wiki/%D9%88%DB%8C%DA%98%D9%87:CommunityConfiguration. Is it not enabled yet? Sorry for stupid question.

In T328171#10155161, @Ladsgroup wrote:

Is it not enabled yet?

Exactly. It was explicitly disabled in rOMWCd6e2c8c17d34577705b29d368beb44b0a4a1cb2d (although the extension’s default is also disabled, so this config is mostly a no-op). It’s enabled on beta cluster (e.g. beta fawiki).

In T328171#10140564, @Urbanecm_WMF wrote:

@Etonkovidova FYI, this is now available for QA on all beta wikis (T374611: Switch BabelUseCommunityConfiguration to true on Beta cluster).

I looked at the form on beta enwiki, and I’m a bit concerned about the Use user language setting. It warns the user that setting it to true may “fragment the parser cache”, but I don’t think an average wiki administrator knows what it means or what consequences it has for the operators. I also don’t think it’s realistically needed – it’s basically true for multilingual wikis and false for monolingual ones. So to avoid people unintentionally blowing up the parser cache, I’d remove this one as well from the community configuration. (By the way, the help text isn’t accurate: it says “if false”, but in the context of community configuration, it can be checked and unchecked, on and off, etc., but not true and false – true and false are for PHP code.)

In T328171#10140564, @Urbanecm_WMF wrote:

However, in LocalSettings.php, BabelCategoryNames allows you to not only specify the category names; it also allows you to use a different language levels system. This is not possible in CommunityConfiguration (the set of language levels is fixed to 1-5 and N at the moment). If a third party wiki is using different language levels than we do, it makes sense (to them) to also override the default level, as they might use different highest level than N (in fact, N might not even exist as a level).

Actually, I don’t know how much sense setting different levels makes in the first place – the level messages are part of the extension (translated on translatewiki.net), so if one changes the levels (except for removing levels), translations will be missing.

In T328171#10155161, @Ladsgroup wrote:

Hi, I haven't followed the discussions and the detailed technical work closely. I want to set the values in my home wiki but I can't find it in https://fa.wikipedia.org/wiki/%D9%88%DB%8C%DA%98%D9%87:CommunityConfiguration. Is it not enabled yet? Sorry for stupid question.

Hi! It's indeed not yet enabled. This is because we wanted to first sync regarding community communication internally. Unfortunately, in the past few weeks, at least one of us was unavailable, so we didn't yet have the chance to meet. We plan to sync regarding releasing this on Monday; after that, we'll update this task with the deployment timeline. Hopefully, this will be community-available soon. Sorry about the delay!

In T328171#10185960, @Tacsipacsi wrote:

In T328171#10140564, @Urbanecm_WMF wrote:

@Etonkovidova FYI, this is now available for QA on all beta wikis (T374611: Switch BabelUseCommunityConfiguration to true on Beta cluster).

I looked at the form on beta enwiki, and I’m a bit concerned about the Use user language setting. It warns the user that setting it to true may “fragment the parser cache”, but I don’t think an average wiki administrator knows what it means or what consequences it has for the operators. I also don’t think it’s realistically needed – it’s basically true for multilingual wikis and false for monolingual ones. So to avoid people unintentionally blowing up the parser cache, I’d remove this one as well from the community configuration.

Hmm... Good question. I agree that whether or not a wiki is multilingual should be the sole considered factor in whether "Use user language" is defined or not. However, I do not think that multilinguality is something decided at the beginning of a wiki, and then never changed. In fact, this comes from how the community actually makes use of the wiki.

There is nothing inherently multilingual about eg. Commons. Commons is multilingual solely because users decided to add content in more than one language. This seems to be the only way how multilinguality can be determined. There are Wikipedias that can be considered multilingual (Serbo-Croatian Wikipedia, to name one). We also have a non-content project that is single-lingual (Wikitech).

If multilinguality was something defined from the beginning of the wiki, then I'd agree it wouldn't make a lot of sense to make this field community-configurable – it would've been much simpler to just define that on wiki creation, and then never return to it. However, as demonstrated above, this doesn't seem to be the case.

Of course, the technical impacts of that option can be a concern. We should certainly rewrite the help text to be less technical and more easier to understand. I'm not sure if this level of user-caused fragmentation is acceptable – I'm curious if eg. @Ladsgroup has any thoughts on this.

(By the way, the help text isn’t accurate: it says “if false”, but in the context of community configuration, it can be checked and unchecked, on and off, etc., but not true and false – true and false are for PHP code.)

We can certainly adjust the copy. Since the scope of this task is already quite big, would it be possible to separate that conversation to a follow-up task?

---

In T328171#10140564, @Urbanecm_WMF wrote:

However, in LocalSettings.php, BabelCategoryNames allows you to not only specify the category names; it also allows you to use a different language levels system. This is not possible in CommunityConfiguration (the set of language levels is fixed to 1-5 and N at the moment). If a third party wiki is using different language levels than we do, it makes sense (to them) to also override the default level, as they might use different highest level than N (in fact, N might not even exist as a level).

Actually, I don’t know how much sense setting different levels makes in the first place – the level messages are part of the extension (translated on translatewiki.net), so if one changes the levels (except for removing levels), translations will be missing.

Since it is a single-wiki setting, you could create overrides in NS_MEDIAWIKI and get those messages. But yes, definitely not nice to use anyway, hence not a part of the CC implementation here.

Of course, the technical impacts of that option can be a concern. We should certainly rewrite the help text to be less technical and more easier to understand. I'm not sure if this level of user-caused fragmentation is acceptable – I'm curious if eg. @Ladsgroup has any thoughts on this.

Most people don't change the default and thus fragmentation caused by picking a different language than default is minimal. For example, even in non "multilingual wikis", people use en-gb in enwiki and that shows up but it's still quite small. I wouldn't worry about it.

Good enough for me, thanks @Ladsgroup!

In T328171#10140564, @Urbanecm_WMF wrote:

@Etonkovidova FYI, this is now available for QA on all beta wikis (T374611: Switch BabelUseCommunityConfiguration to true on Beta cluster).

Thx! Checked it as part when checked T374611. No issues found.

In T328171#10186694, @Urbanecm_WMF wrote:

However, I do not think that multilinguality is something decided at the beginning of a wiki, and then never changed. In fact, this comes from how the community actually makes use of the wiki.

It’s indeed not something that is never change, but it rarely happens, and it needs a lot of coordinated changes: for example, probably $wgForceUIMsgAsContentMsg also needs to be set, maybe Translate also needs to be enabled, if Wikibase Client is enabled, $wgWBClientSettings['allowDataAccessInUserLanguage'] should be turned on, and likely quite a few other things as well.

There are Wikipedias that can be considered multilingual (Serbo-Croatian Wikipedia, to name one).

Actually, I don’t think Serbo-Croatian Wikipedia is multilingual. It’s written in one language, Serbo-Croatian – there are people consider Serbian and Croatian separate languages, but they contribute to the Serbian or Croatian Wikipedia; Serbo-Croatian Wikipedia is for those who consider it one language. (It has two alphabets and thus uses language conversion, but that has nothing to do with multilinguality.)

Actually, I don’t know how much sense setting different levels makes in the first place – the level messages are part of the extension (translated on translatewiki.net), so if one changes the levels (except for removing levels), translations will be missing.

Since it is a single-wiki setting, you could create overrides in NS_MEDIAWIKI and get those messages.

The problem is that you’d have to create overrides in all languages. Assuming that you create a new level called M, you’d need to create MediaWiki:Babel-M/en for those who use {{#babel:en-M}}, MediaWiki:Babel-M/cs for those who use {{#babel:cs-M}}, MediaWiki:Babel-M/hu for those who use {{#babel:hu-M}}, and so on.