https://bugzilla.wikimedia.org/show_bug.cgi?id=14207 "Activate Extension:Babel on nds.Wikipedia" is related.

Assigning to Roan, mainly because he already has a few other Babel installation requests assigned.

(In reply to comment #2)

Assigning to Roan, mainly because he already has a few other Babel installation
requests assigned.

Unassigning from self; I don't have time to review the Babel extension any time soon, and I don't do shell requests any more.

It's been two years since bug 14207 was opened. In the meantime three other wikis have requested this extension to be enabled.

What can be expected here?

robert wrote:

Setting assignee to Tim Starling per bug 15165.

Bumping up to "high" because it will be good to get a ping from the bugmeister every month until this one is done. Removing as a blocker to bug 27339 because it doesn't belong there (it's not a regression, so it's not a 1.17 cleanup task). Unassigning from Tim because anyone on the review team should be able to look at this, and I don't think Tim specifically volunteered.

Requesting the review delayed because there are numerous (about 30) little changes needed before the extension will be suitable to all wikis that I am aware of, bugs removed, and ommissions filled in. I am currently working on them. I expect most modifications to be ready within few days.

So as to deliver the extension to many wmf wikis, individual parameters need to be set per wiki in each Localsettings.php file. I have a collection of those data for the majority of the wikipedias: is there a preferred way of selecting individual wikis, such as by database name, by url, etc.?

What are those changes?

I'm intrigued to know also..

(In reply to comment #7)

Requesting the review delayed because there are numerous (about 30) little
changes needed before the extension will be suitable to all wikis that I am
aware of, bugs removed, and ommissions filled in. I am currently working on
them. I expect most modifications to be ready within few days.

I was originally gonna review this starting Monday, but per your comment I'll hold off on that and review another few extensions first until you inform me you're done tweaking and fixing stuff.

So as to deliver the extension to many wmf wikis, individual parameters need to
be set per wiki in each Localsettings.php file. I have a collection of those
data for the majority of the wikipedias: is there a preferred way of selecting
individual wikis, such as by database name, by url, etc.?

See http://noc.wikimedia.org/conf/highlight.php?file=InitialiseSettings.php , which displays (one of) the live config files.

A week has gone in silence, can we please move forward.

(In reply to comment #11)

A week has gone in silence, can we please move forward.

I would've moved forward if I had had the time to. Last week was pretty crazy for me with the category collation deployment and personal / school-related things. I'm planning to review Babel next week if nothing else crazy happens.

Here is a quick, possibly incomplete, list of things I am working on:

• language code / locale code links to wrong pages.
• language code / locale code links cannot be avoided.
• some language codes / locale codes are not recognized when capitalized correctly as of BCP 47.
• some language codes / locale codes are not recognized at all.
• language codes are shown capitalized differently from user input.
• capitalization by user should be irrelevant.
• some localized messages in the extensions .i18n file are not found.
• wrong category links for skill levels used in inner Babel boxes.
• ISO 639-1 language codes are shown even though user choose ISO 369-3 codes.
• ISO 639-1 language codes are used even in wikis accepting ISO 369-3 codes only.
• correct ISO 639-3 codes without MessageXzz.php file in Mediawiki are collectively mapped to the wikis content language.
• base category names cannot be specified correctly for a number of wikipedias.
• base category sort keys are mostly wrong (because they are missing)
• contents of automagically created base category pages cannot be properly specified.
• categories of categories cannot be correctly assigned.
• categories of categories cannot be correctly named for many wikis.
• categories of categories need to have sort keys specified, when used.
• contents of automagically created category of category pages cannot be properly specified.
• some category inclusions are to be avoided on a per wiki basis, such as "zxx-0" in "user has command of zxx"
• there need to be exceptional category names for some languages in some languages.
• cannot link level code to something, e.g. an explanatory page or a category page.
• GENDER support missing in outer Babel box header and footer.
• cannot pass parameters to templates of the wiki.
• directionality handled incorrectly.
• either numeric level indicators of the wiki script are not recognized, or standard ones, but not both.
• native level indicators of the wiki other than "N" are not not recognized, or the standard "N" is not available.
• must be able to find language / locale codes independent of capitalization.
• lookup of language / locale code needs to return a list of ISO 639-X sets, to which a language code belongs.
• need to offer all ISO-X codes, and language names, and levels as parameters to various messages, and similar.
• some messages must know when a language name was not translated.
• configuration options using %percent% parameters should be using $1, $2, ... like other messages do.
• configuration %percent% parameters are insufficient (too few).
• should not said configuration parameters better be in the MediaWiki namespace than in LocalSettings.php?

I was too lazy to write individual bug reports.

(In reply to comment #13)
The last item in the ist is a question:

• should not said configuration parameters better be in the MediaWiki namespace than in LocalSettings.php?

Either has its (dis)advantages.

Localsettings may be easier to handle for a standard installation. Most settings are unlikely to be altered.

The MediaWiki namespace would be easier for WMF installatinos, since it does not require shell access and can be handled by individual administrators for many wikis without bothering server admins.

We could also make it "if not set here, then look there", possibly.

(In reply to comment #13)

I was too lazy to write individual bug reports.

That is very sad, because it actually makes the list completely untrackable and hence unusable. Once advise: commit early and commit often - preferably per feature or fix of issue. If you were to commit this in one batch, you can be almost certain it will be reverted.

Things are somewhat complicated. Several of the above overlap, or are interdependent, and cannot be tackled one after the other while maintaining error-free running code at the same time, I am afraid. Committing often would require a branch which is not neccessarily free of additional, temporary, issues all the time. If that is what you want, I shall go ahead when I am back from work.

(In reply to comment #16)

Things are somewhat complicated. Several of the above overlap, or are
interdependent, and cannot be tackled one after the other while maintaining
error-free running code at the same time, I am afraid. Committing often would
require a branch which is not neccessarily free of additional, temporary,
issues all the time. If that is what you want, I shall go ahead when I am back
from work.

You shouldn't commit one big "this fixes everything" commit, but it's also not always practical to commit separately for every issue when there are dependencies and reorganizations involved. But there's some middle ground there.

If you can reasonably split up a commit such that the parts make sense individually and things don't break in between, do so. In practice, this means you should avoid commits that fix two unrelated issues.

If you're doing a large-ish reorganization or something, it sometimes makes sense to split it up in multiple commits, leaving things slightly broken in the meantime. This is fine on occasion if the breakage isn't too bad and doesn't stick around for too long. For instance, it's not unusual to rename files in one commit (breaking things) and change some other things in a second commit a few minutes later (fixing things).

robert wrote:

Thanks for posting this list. I'd be happy to split the workload with you, though we would need to have separate bug reports for each item (a lot seem to be very related so could be combined in to a few larger reports).

I do think that its imperative to commit reasonably often as mentioned earlier, looking at these changes though there are a lot of items I do not believe this will result in any large-scale change. Additionally I don't think there is an issue with making a large number of commits out of branch (though please correct me if I'm wrong).

(In reply to comment #13)

Here is a quick, possibly incomplete, list of things I am working on:

• language code / locale code links to wrong pages.
• language code / locale code links cannot be avoided.
• some language codes / locale codes are not recognized when capitalized

correctly as of BCP 47.

• some language codes / locale codes are not recognized at all.
• language codes are shown capitalized differently from user input.
• capitalization by user should be irrelevant.
• some localized messages in the extensions .i18n file are not found.
• wrong category links for skill levels used in inner Babel boxes.
• ISO 639-1 language codes are shown even though user choose ISO 369-3 codes.

This was an intentional decision to normalise language codes so the same are used throughout the wiki. In the future ISO 639-5 will be in use which favours 639-1 codes.

• ISO 639-1 language codes are used even in wikis accepting ISO 369-3 codes

only.

I believe there is a bug reporting open for this, would be great to have this as an option.

• correct ISO 639-3 codes without MessageXzz.php file in Mediawiki are

collectively mapped to the wikis content language.

• base category names cannot be specified correctly for a number of wikipedias.
• base category sort keys are mostly wrong (because they are missing)
• contents of automagically created base category pages cannot be properly

specified.

• categories of categories cannot be correctly assigned.
• categories of categories cannot be correctly named for many wikis.
• categories of categories need to have sort keys specified, when used.
• contents of automagically created category of category pages cannot be

properly specified.

• some category inclusions are to be avoided on a per wiki basis, such as

"zxx-0" in "user has command of zxx"

• there need to be exceptional category names for some languages in some

languages.

• cannot link level code to something, e.g. an explanatory page or a category

page.

• GENDER support missing in outer Babel box header and footer.
• cannot pass parameters to templates of the wiki.
• directionality handled incorrectly.
• either numeric level indicators of the wiki script are not recognized, or

standard ones, but not both.

• native level indicators of the wiki other than "N" are not not recognized, or

the standard "N" is not available.

• must be able to find language / locale codes independent of capitalization.
• lookup of language / locale code needs to return a list of ISO 639-X sets, to

which a language code belongs.

• need to offer all ISO-X codes, and language names, and levels as parameters

to various messages, and similar.

• some messages must know when a language name was not translated.
• configuration options using %percent% parameters should be using $1, $2, ...

like other messages do.

These aren't messages.

• configuration %percent% parameters are insufficient (too few).
• should not said configuration parameters better be in the MediaWiki namespace

than in LocalSettings.php?

This was an intentional decision because changing the category format will result in the automatic creation of hundreds of categories and is not something that should be taken lightly. (And definitely not something that there should be the risk of administrators edit-warring over).

Is this still ready for review? Or is Purodha's work ongoing?

I am still at work and shall report, when done.

robert wrote:

Closing as WONTFIX, this will be obsoleted by the planned "structured profiles" feature (which is arguably a better implementation of the concept).

(In reply to comment #21)

Closing as WONTFIX, this will be obsoleted by the planned "structured profiles"
feature (which is arguably a better implementation of the concept).

For the record:
https://secure.wikimedia.org/wikipedia/mediawiki/wiki/StructuredProfile

robert wrote:

Jumped the gun, sorry.

(In reply to comment #20)

I am still at work and shall report, when done.

It looks like you haven't updated this since 3/18, and the only other updates are by SPQRobin.

Is this something we shouldn't worry about deploying?

Roan, can you plan deployment?

(In reply to comment #25)

Roan, can you plan deployment?

Scheduled for Wednesday, September 21, 12:00-13:00 UTC.

The wikis should be informed about the deployment. I put a section on http://meta.wikimedia.org/wiki/Babel_extension#Deployment and will spread the word.

Gerard Meijssen is preparing a techblog post.

(In reply to comment #26)

(In reply to comment #25)

Roan, can you plan deployment?

Scheduled for Wednesday, September 21, 12:00-13:00 UTC.

Can someone point me to a decent consensus for this to be rolled out globally?

Based on what I saw at the meta page last night it was lacking:

• in numbers to be considered anything near a global consensus (especially since the votes were over a large number of years)
• it lacked a lot of information for users to be able to make judgements before voting, and out of the questions/discussions of functionality I saw it was only after people asked
• Communities apparently need consensus to opt out, yet the first mention i've seen of it on en.wiki for example is from the 18th

Babel is now deployed.