https://www.mediawiki.org/wiki/Extension:ExtraLanguageLink
https://gerrit.wikimedia.org/r/p/mediawiki/extensions/ExtraLanguageLink.git
Version: unspecified
Severity: normal
Description
Description
Details
Details
- Reference
- bz64903
| Status | Subtype | Assigned | Task | ||
|---|---|---|---|---|---|
| Open | Feature | None | T18962 Provide a non-JavaScript means of including a "Complete list" link in the interlanguage sidebar | ||
| Resolved | None | T34189 An interlanguage link to oldwikisource is required | |||
| Declined | TTO | T66786 Review the ExtraLanguageLink extension for deployment | |||
| Declined | None | T66903 Arch/Performance review of ExtraLanguageLink for WMF deploy |
Event Timeline
Comment Actions
I see you can find pages using this extension using Special:PagesWithProp or API action=query&list=pageswithprop. But there doesn't seem to be any way to search for pages using this extension for particular links short of reading and parsing the property for every page using the extension. Should there be such a way? I'd think yes.
For comparison, real langlinks can be queried using API action=query&list=langbacklinks and interwiki links using API action=query&list=iwbacklinks.
Gerrit change 111390 avoids this problem because the non-language langlinks added via that patch do get recorded in the langlinks table.
Comment Actions
(In reply to Brad Jorsch from comment #1)
I see you can find pages using this extension using Special:PagesWithProp or
API action=query&list=pageswithprop. But there doesn't seem to be any way to
search for pages using this extension for particular links short of reading
and parsing the property for every page using the extension. Should there be
such a way? I'd think yes.
I can add an API module to search for uses of {{extralanguagelink}}, but I can't see any way of making it very efficient. Can API modules be marked expensive, or limited to a small number of results (10 or 20) at a time?
Gerrit change #111390 avoids this problem because the non-language langlinks
added via that patch do get recorded in the langlinks table.
It's not always appropriate to include extra language links in the langlinks table; hence this extension.
Comment Actions
(In reply to This, that and the other from comment #2)
It's not always appropriate to include extra language links in the langlinks
table; hence this extension.
It seems odd to me that the links would be appropriate to display in the langlinks area of the web UI but not to include in the langlinks table.
Not storing them in langlinks might also have trouble with code (e.g. mobile) that fetches the langlinks via the API and constructs its own UI to display them.
Comment Actions
I would welcome review/merge of Gerrit change 111390; if that patch proves insufficient for resolving the two dependencies of bug 64786 then we can pick this up again.