Description
Details
- Reference
- bz72525
| Subject | Repo | Branch | Lines +/- | |
|---|---|---|---|---|
| Migrate namespaces to canonical ones | mediawiki/extensions/ProofreadPage | master | +125 -0 |
| Status | Subtype | Assigned | Task | ||
|---|---|---|---|---|---|
| Open | Feature | None | T45934 harmonize namespaces towards languages and projects | ||
| Open | None | T74525 harmonize Wikisource namespaces used by the ProofreadPage extension | |||
| Open | None | T180885 Create maintenance script to renumber namespaces |
Event Timeline
The list of non-standard namespaces for Extension:ProofreadPage is given in https://noc.wikimedia.org/conf/InitialiseSettings.php.txt in the array `$wgProofreadPageNamespaceIds'.
This is not that simple because we'll have to update the templates and scripts etc across the wikis as well.
Change 169779 had a related patch set uploaded by Reedy:
Set a default for wgProofreadPageNamespaceIds
(In reply to Gerrit Notification Bot from comment #3)
Change 169779 had a related patch set uploaded by Reedy:
Set a default for wgProofreadPageNamespaceIds
I'm not sure if 104/106 are the values that we "want" to use, but that is what most sites are using. To that extent, I just made/extracted a default value for these, and removed the "duplicates".
This makes the config clearer, and more obvious to see the anomalies..
In this consultation, I note:
- the lack of strong support of Tpt, current current maintainer of Proofreadpage
- the very weak support of the proposal (but yes, it's a current recurring issue these last years)
- the need to take in account the charge in the databases
I consulted reedy on MediaWiki-General on the matter (who then created the patch noted in comment #3). Reedy considers "they're gonna be indexed updates, so it's a case of doing it as batched queries, waiting for slaves" and to not "see any obvious reason straight off why it shouldn't be doable".
As a next course of action, they suggests to count the number of affected pages, and to "come up with a rough plan of action".
Tpt knows of course well the issue to have play with this idea sometimes these previous years, so they is a good candidate for that.
[Taking back as NEW, the patch were only the first step to make the situation more clear in the configuration]
I support the project to move namespace ids for Page/Index namespaces to 250/252 that are the ones reserved by ProofreadPage extension. I'll be happy to help system admins in order to see if the migration if feasible on their side.
Change 169781 merged by jenkins-bot:
Adds an explicit default for $wgProofreadPageNamespaceIds
So if 250 & 252 are now the defaults, what needs to be done next to reflect that on any given Wikisource project?
I think that It only means that it'll be 250-252 unless overridden for the wiki (all wikis currently having different ids will continue to have that).
I don't think we actually do have a blocker for this now. We can update the configuration files easily but updating the database tables is going to be a complex issue here, I think. (cc @Springle) Can namespaceDupes.php handle this or should another script be written? Once that happens, on wiki templates and scripts could be updated.
@Tpt @Ricordisamoa @Glaisher could we plan an IRC meeting to solve this, and see how to write the maintenance script if needed? I'm fairly avaible between 14:00 and 00:00 UTC.
No, this bug is about standardization of Page: and Index: namespaces number to 250 and 252 and the other one is about removing not needed anymore configuration options from Wikimedia config
Could someone provide a list of fields which we have to modify? (i.e. fields where namespaces are stored)
Something similar to SELECT table_name, column_name, column_type FROM information_schema.columns WHERE table_schema = 'enwikisource' AND column_name LIKE '%namespace%'; would work?
mysql:wikiadmin@db1044 [enwikisource]> SELECT table_name, column_name, column_type FROM information_schema.columns WHERE table_schema = 'enwikisource' AND column_name LIKE '%namespace%'; +--------------------+-------------------+-------------+ | table_name | column_name | column_type | +--------------------+-------------------+-------------+ | abuse_filter_log | afl_namespace | int(11) | | archive | ar_namespace | int(11) | | click_tracking | namespace | int(11) | | cu_changes | cuc_namespace | int(11) | | edit_page_tracking | ept_namespace | int(11) | | externallinks | el_from_namespace | int(11) | | hidden | hidden_namespace | int(11) | | imagelinks | il_from_namespace | int(11) | | job | job_namespace | int(11) | | logging | log_namespace | int(11) | | logging_pre_1_10 | log_namespace | int(11) | | mark_as_helpful | mah_namespace | int(11) | | moodbar_feedback | mbf_namespace | int(11) | | page | page_namespace | int(11) | | pagelinks | pl_namespace | int(11) | | pagelinks | pl_from_namespace | int(11) | | povwatch_log | pwl_namespace | int(11) | | protected_titles | pt_namespace | int(11) | | querycache | qc_namespace | int(11) | | querycachetwo | qcc_namespace | int(11) | | querycachetwo | qcc_namespacetwo | int(11) | | recentchanges | rc_namespace | int(11) | | redirect | rd_namespace | int(11) | | templatelinks | tl_namespace | int(11) | | templatelinks | tl_from_namespace | int(11) | | titlekey | tk_namespace | int(11) | | watchlist | wl_namespace | int(11) | +--------------------+-------------------+-------------+ 27 rows in set (0.03 sec) mysql:wikiadmin@db1044 [enwikisource]>
Change 354881 had a related patch set uploaded (by Dereckson; owner: Dereckson):
[mediawiki/extensions/ProofreadPage@master] Migrate namespaces to canonical ones
Plan is to prepare a maintenance script to update namespaces.
Then, @Tpt and me will use a specific deployment window to do the following tasks:
- make the wiki read only to avoid data corruption
- run the new maintenance script to rename namespace
- run namespaceDupes to update the broken links
- reopen the wiki
We'll announce the date so wikisources won't be taken by surprise.
possible to advertise and publish the determined namespace allocations ahead of time? This will allow any hard-coded components to be prepared for a fix ahead of time Thanks.
possible to advertise and publish the determined namespace allocations ahead of time?
We are planning to use the namespaces owned by the ProofreadPage extension (already used by the new wikis since 2013):
- Page: would be 250
- Index: would be 252
See https://www.mediawiki.org/wiki/Extension_default_namespaces#Proofread_Page
@Dereckson Just ping me when you have the date and all other relevant information, and I'll add it to Tech News.
@Tpt Can we meet at Paris, Lille, Brussels or some other easily reachable city to work on that together a week-end?
At hackathons, you work on other topic, so that's a good candidate for a small "configuration" event.
that = write and test the maintenance script
Possible plan for the migration:
- Make sure that all Wikimedia beta/prod wiki is using the wgProofreadPageNamespaceIds configuration parameter and for none Page: or Index: namespaces are registered using [[ URL | wgExtraNamespaces ]] of other configuration variables.
- Migrate gadgets on the affected wikis to use the canonical namespace name instead of the namespace id to avoid breaks during the migration
- For each wiki, lock it, run the migration script, deploy a config change setting the namespace ids to 250 and 252 and unlock it
- When it's done, drop the dynamic namespace id lookup from ProofreadPage and drop wgProofreadPageNamespaceIds from site-config