Last modified: 2013-06-18 13:40:02 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T17308, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 15308 - Review Babel extension for deployment on Wikimedia Wikis
Review Babel extension for deployment on Wikimedia Wikis
Status: RESOLVED FIXED
Product: Wikimedia
Classification: Unclassified
Extension setup (Other open bugs)
unspecified
All All
: High enhancement with 8 votes (vote)
: ---
Assigned To: Roan Kattouw
http://www.mediawiki.org/wiki/Extensi...
: patch-need-review
Depends on: 16699
Blocks: 14207 15165 18461 23268 25817 29647
  Show dependency treegraph
 
Reported: 2008-08-25 19:51 UTC by ChrisiPK
Modified: 2013-06-18 13:40 UTC (History)
15 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments

Description ChrisiPK 2008-08-25 19:51:22 UTC
I am planning to start a vote about whether the Babel extension should be activated on the German wikipedia and maybe all other Wikimedia wikis. I was told that the developers need to review any extension before it can be activated, so I would appreciate it if you could check this extension before I start the votes. Thanks.
Comment 1 Marcus Buck 2008-09-15 12:34:35 UTC
<https://bugzilla.wikimedia.org/show_bug.cgi?id=14207> "Activate Extension:Babel on nds.Wikipedia" is related.
Comment 2 Siebrand Mazeland 2010-04-18 23:19:14 UTC
Assigning to Roan, mainly because he already has a few other Babel installation requests assigned.
Comment 3 Roan Kattouw 2010-04-19 08:18:25 UTC
(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.
Comment 4 Siebrand Mazeland 2010-05-30 11:00:54 UTC
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?
Comment 5 Robert Leverington 2011-01-21 20:58:51 UTC
Setting assignee to Tim Starling per bug 15165.
Comment 6 Rob Lanphier 2011-03-05 02:28:26 UTC
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.
Comment 7 Purodha Blissenbach 2011-03-05 04:37:59 UTC
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.?
Comment 8 Niklas Laxström 2011-03-05 09:16:17 UTC
What are those changes?
Comment 9 Sam Reed (reedy) 2011-03-05 13:47:02 UTC
I'm intrigued to know also..
Comment 10 Roan Kattouw 2011-03-05 21:48:52 UTC
(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.
Comment 11 Niklas Laxström 2011-03-12 11:12:49 UTC
A week has gone in silence, can we please move forward.
Comment 12 Roan Kattouw 2011-03-12 15:03:57 UTC
(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.
Comment 13 Purodha Blissenbach 2011-03-14 02:47:58 UTC
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.
Comment 14 Purodha Blissenbach 2011-03-14 02:58:40 UTC
(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.
Comment 15 Siebrand Mazeland 2011-03-14 10:26:01 UTC
(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.
Comment 16 Purodha Blissenbach 2011-03-14 11:07:14 UTC
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.
Comment 17 Roan Kattouw 2011-03-14 11:20:07 UTC
(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).
Comment 18 Robert Leverington 2011-03-14 18:31:12 UTC
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).
Comment 19 Tim Starling 2011-03-25 00:43:12 UTC
Is this still ready for review? Or is Purodha's work ongoing?
Comment 20 Purodha Blissenbach 2011-03-25 22:27:57 UTC
I am still at work and shall report, when done.
Comment 21 Robert Leverington 2011-06-29 20:56:04 UTC
Closing as WONTFIX, this will be obsoleted by the planned "structured profiles" feature (which is arguably a better implementation of the concept).
Comment 22 Helder 2011-06-29 20:59:05 UTC
(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
Comment 23 Robert Leverington 2011-06-29 21:01:16 UTC
Jumped the gun, sorry.
Comment 24 Mark A. Hershberger 2011-07-18 15:33:13 UTC
(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?
Comment 25 Siebrand Mazeland 2011-09-13 08:13:30 UTC
Roan, can you plan deployment?
Comment 26 Roan Kattouw 2011-09-14 12:52:12 UTC
(In reply to comment #25)
> Roan, can you plan deployment?
Scheduled for Wednesday, September 21, 12:00-13:00 UTC.
Comment 27 Robin Pepermans (SPQRobin) 2011-09-16 13:32:08 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.
Comment 28 Siebrand Mazeland 2011-09-16 13:35:35 UTC
Gerard Meijssen is preparing a techblog post.
Comment 29 p858snake 2011-09-20 09:27:39 UTC
(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
Comment 30 Roan Kattouw 2011-09-21 14:13:21 UTC
Babel is now deployed.

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links