Last modified: 2014-09-23 22:42:15 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 T17607, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 15607 - Install Extension:Interlanguage on en.wikipedia
Install Extension:Interlanguage on en.wikipedia
Status: RESOLVED DUPLICATE of bug 44515
Product: MediaWiki extensions
Classification: Unclassified
WikidataClient (Other open bugs)
unspecified
All All
: Low enhancement with 36 votes (vote)
: ---
Assigned To: Wikidata bugs
http://meta.wikimedia.org/wiki/A_newe...
:
Depends on: 28194 28255
Blocks: 31235
  Show dependency treegraph
 
Reported: 2008-09-14 21:24 UTC by Amir E. Aharoni
Modified: 2014-09-23 22:42 UTC (History)
44 users (show)

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


Attachments

Description Amir E. Aharoni 2008-09-14 21:24:24 UTC
I hope that this is the right place to bring this up; if not, please let me know where would it be.

There's an extension called "Interlanguage" that is designed to make the maintenance of interwiki links much easier.

I tried it in its test wiki and it worked very well.

Can it be enabled in Wikipedia?

This will require:

# Setting up a new wiki for the links themselves.
# Testing the extension, probably in test.wikipedia.org.
# Copying links with no conflicts to the new wiki. This can be done by a bot and is not really a part of this bug report. At this point the old and the new ways of interlanguage linking can coexist - i tested it and it appears to work.
# Resolving the remaining interwiki conflicts. I am already working on it manually, but the new extension will make it easier and more efficient.

Thanks in advance.
Comment 1 Melancholie 2008-09-15 16:14:35 UTC
Not just for Wikipedia, please. Wikimedia is more...
Comment 2 Amir E. Aharoni 2008-09-15 17:19:08 UTC
> Not just for Wikipedia, please. Wikimedia is more...
> 

I mostly work on Wikipedia (in many languages), but if anyone thinks that it's useful for other projects, then go for it.
Comment 3 Kunal Mehta (Legoktm) 2008-09-16 01:25:35 UTC
I believe that there is no consensus right now to implement this.
Comment 4 Amir E. Aharoni 2008-09-16 05:46:52 UTC
(In reply to comment #3)
> I believe that there is no consensus right now to implement this.
> 

Did anyone express express an actual objection?

There are many supporters at http://meta.wikimedia.org/wiki/Talk:A_newer_look_at_the_interlanguage_link

Of course it must be tested in an environment that is more demanding that its current test wiki, but i believe that this should start.
Comment 5 Niklas Laxström 2008-09-18 17:23:08 UTC
I don't see such extension in the MediaWiki code repository.
Comment 6 Nikola Smolenski 2008-09-20 07:46:05 UTC
That's no excuse, as Chad offered me to put it in the SVN ;)

I have just started a discussion on Wikitech-l regarding the technical feasibility of using the extension, so perhaps we should first wait for the verdict there.
Comment 7 Arno Lagrange 2008-10-06 15:04:28 UTC
It would be a great improvement. I think about such a feature since more than 4 years ! 
Comment 8 Woojin Kim 2008-10-07 12:08:47 UTC
Hmm. I don't agree. Wikipedia User may be very confused when this extension implemented! I think implementing this extension must be agreed by all users who participate in wikimedia projects. Huge change will make some users be angry. 
Comment 9 Marcus Buck 2008-10-07 12:19:05 UTC
Why should anybody be angry? It's an improvement and has no negative side-effects, cause the old system still will be fully working. The implementation of the extension will be a great relief for smaller projects. The smaller the project, the bigger the share of bot edits of the total edit count. Small projects' edit histories are flooded with bot edits. But bigger projects too will notice the difference.

I see really no point why anybody should become confused or angry.
Comment 10 Nikola Smolenski 2008-10-07 12:51:12 UTC
(In reply to comment #8)

The extension is compatible with the usual interlanguage links. If a project doesn't want to use it, it doesn't have to use it.
Comment 11 Ficell 2008-10-08 12:25:34 UTC
(In reply to comment #8)

Why do you disagree? Just because confusion when it implemented? If so, enough notice can solve that problem.
Comment 12 Nikola Smolenski 2008-12-11 20:08:49 UTC
The extension is now in SVN, at http://svn.wikimedia.org/svnroot/mediawiki/trunk/extensions/Interlanguage/
Comment 13 Brion Vibber 2008-12-11 21:20:28 UTC
I don't quite understand what this extension is meant to accomplish, or how the workflow is envisioned. What are the user interface and performance considerations?

The lack of automatic updates seems less than ideal, as does the multiple fetching of link data over the HTTP API on every page render. Management UI by manual editing of offsite pages looks pretty ugly; what could be done to improve this?
Comment 14 Nikola Smolenski 2008-12-11 22:02:21 UTC
General idea is to ease work with interlanguage links and improve their contemporarity by centralizing their maintenance. Workflow: whenever someone creates a new page, he/she should add an interlanguage link to it, but on the central wiki instead of the wiki where the page is; alternatively, this could be done by a bot like it often is today.

User interfact considerations: it should be easier to maintain a single link than a dozen of interlanguage links; it should be easier to do nothing than to operate a herd of bots. I tried to initiate discussion on performance considerations on Wikitech-l to which, wisely, no one answered.

The lack of automatic updates should not pose a problem, since updates will likely still happen more often than bot updates would, and also they could be automated if needed (by bots that would purge pages with new interlanguage links).

The multiple fetching of link data over the API could be a problem, see performance considerations comment above. On the other hand, this multiple fetching may still be better for wikis that (should) have more bot edits than real edits. Perhaps using a few wikis to experiment could give better answer to this question. The extension isn't all-or-nothing, it's compatible with current interlanguage link system, and not every project has to have it.

Manual editing of offsite pages may seem unwieldy, but on the other hand it requires little retraining of editors. You could say the same WRT Commons: why wouldn't any image uploaded to any wiki be available to every wiki? Well, it isn't, and what we have is the second best.
Comment 15 Chad H. 2008-12-11 23:19:28 UTC
(In reply to comment #13)
> [snip]
>
> The lack of automatic updates seems less than ideal, as does the multiple
> fetching of link data over the HTTP API on every page render. Management UI by
> manual editing of offsite pages looks pretty ugly; what could be done to
> improve this?
> 

Added some caching in r44476
Comment 16 Brion Vibber 2008-12-11 23:24:28 UTC
(In reply to comment #14)
> General idea is to ease work with interlanguage links and improve their
> contemporarity by centralizing their maintenance. Workflow: whenever someone
> creates a new page, he/she should add an interlanguage link to it, but on the
> central wiki instead of the wiki where the page is; alternatively, this could
> be done by a bot like it often is today.

If we're going to create a special tool, there's no point in stopping so short that we still have to rely on somebody to run client-side bots to make it work properly. We've got a site with shared databases and the ability to queue updates automatically on the server side... take advantage of it!
Comment 17 Amir E. Aharoni 2008-12-12 08:24:16 UTC
> We've got a site with shared databases and the ability to queue
> updates automatically on the server side... take advantage of it!

I don't understand which updates are you talking about. Do you propose to leave the current interwiki linking scheme but queue a bot on the main server to update the pages? It doesn't help much, because an edit action is still recorded in the page's history and shows up in RC and the watchlist.

Using this extension the update is immediate and only one edit action is needed.

Or did i completely misunderstand Brion?
Comment 18 Chad H. 2008-12-12 11:19:59 UTC
(In reply to comment #17)
> > We've got a site with shared databases and the ability to queue
> > updates automatically on the server side... take advantage of it!
> 
> I don't understand which updates are you talking about. Do you propose to leave
> the current interwiki linking scheme but queue a bot on the main server to
> update the pages? It doesn't help much, because an edit action is still
> recorded in the page's history and shows up in RC and the watchlist.
> 
> Using this extension the update is immediate and only one edit action is
> needed.
> 
> Or did i completely misunderstand Brion?
> 

I think what he's suggestion is rather than put this through Http calls to the API, why not push the data out from the central wiki (via DB) to the target wikis?
Comment 19 Amir E. Aharoni 2008-12-12 11:51:48 UTC
(In reply to comment #18)
> (In reply to comment #17)
> > > We've got a site with shared databases and the ability to queue
> > > updates automatically on the server side... take advantage of it!
> > 
> > I don't understand which updates are you talking about.
> > ...
> > ... did i completely misunderstand Brion?
> > 
> 
> I think what he's suggestion is rather than put this through Http calls to the
> API, why not push the data out from the central wiki (via DB) to the target
> wikis?

I suppose that it's OK to push updates in batches if it may hurt performance.

It is still better than having to edit pages in several wikis just to update one link or to see endless bot updates.
Comment 20 yonidebest 2008-12-12 12:02:21 UTC
One note regarding implementation features:

The Hebrew Wikipedia has the interwikis ordered differently than in the English Wikipedia. The basic rule is that the English interwiki is always first, and the rest are followed alphabetically. I am sure that other Wikipedias have custom rules of their own, so this feature should be taken into account.

Comment 21 Amir E. Aharoni 2008-12-12 12:10:55 UTC
(In reply to comment #20)
> One note regarding implementation features:
> 
> The Hebrew Wikipedia has the interwikis ordered differently than in the English
> Wikipedia. The basic rule is that the English interwiki is always first, and
> the rest are followed alphabetically. I am sure that other Wikipedias have
> custom rules of their own, so this feature should be taken into account.
> 

Thanks for the comment - it is discussed here:

* http://meta.wikimedia.org/wiki/Talk:A_newer_look_at_the_interlanguage_link
* https://bugzilla.wikimedia.org/show_bug.cgi?id=2867
Comment 22 Nikola Smolenski 2008-12-12 12:14:26 UTC
The extension supports custom sorting orders, so that is not a problem. In hewiki's configuration, just add

$wgInterlanguageExtensionSortPrepend = array('en');
Comment 23 Nemo 2009-02-03 07:48:30 UTC
(In reply to comment #18)
> 
> I think what he's suggestion is rather than put this through Http calls to the
> API, why not push the data out from the central wiki (via DB) to the target
> wikis?
> 

Perhaps with sort of (selective) transclusion (http://www.mediawiki.org/wiki/Extension:Labeled_Section_Transclusion)?
Comment 24 Nikola Smolenski 2009-02-03 19:38:07 UTC
(In reply to comment #23)
> (In reply to comment #18)
> > I think what he's suggestion is rather than put this through Http calls to the
> > API, why not push the data out from the central wiki (via DB) to the target
> > wikis?

I am still not sure what Brion was thinking, I have even asked him in a personal email to clarify but it seems he missed it somehow.
 
> Perhaps with sort of (selective) transclusion
> (http://www.mediawiki.org/wiki/Extension:Labeled_Section_Transclusion)?

I don't see at all what it has to do with this.
Comment 25 Nemo 2009-02-10 23:17:50 UTC
(In reply to comment #24)
> > Perhaps with sort of (selective) transclusion
> > (http://www.mediawiki.org/wiki/Extension:Labeled_Section_Transclusion)?
> 
> I don't see at all what it has to do with this.
> 

Maybe http://wiki-tools.com/wiki/TransWiki (suggested also for bug 14759)? 

Nemo
Comment 26 Amir E. Aharoni 2009-03-13 11:21:22 UTC
I am reading the comments and trying to understand what is the problem with enabling this extension.

Naming of the "article" in the common wiki?

Performance?

Integration problems with current software?

Disagreements of local language communities?
Comment 27 Slavik IVANOV 2009-03-14 15:35:45 UTC
It's a great tool as everybody seems to agree.

Let us just enable it!

If you need several wikis to try it on, put os.wikipedia on the list. I will be very glad to ban all the interwiki bots with their messing the "history" pages.
Comment 28 Marcus Buck 2009-03-14 16:58:52 UTC
>If you need several wikis to try it on, put os.wikipedia on the list. I will be
>very glad to ban all the interwiki bots with their messing the "history" pages.

And nds.wikipedia will gladly join the list of volunteer projects.

Look at a version history like <http://nds.wikipedia.org/w/index.php?title=Burkina_Faso&action=history>. It's ridiculous! Between the creation of the article and the most recent update there were 75[!] bot edits just interrupted by three human edits. Between March 2007 and February 2009 there were 52[!] consecutive bot edits. And I did no long search for the most extreme example, the same is true for most country articles and all articles which are likely to have many translations.
Comment 29 Chad H. 2009-03-14 22:20:30 UTC
(In reply to comment #26)
> I am reading the comments and trying to understand what is the problem with
> enabling this extension.
> 
> Naming of the "article" in the common wiki?
> 
> Performance?
> 
> Integration problems with current software?
> 
> Disagreements of local language communities?
> 

Or the fact that this still hasn't been reviewed thoroughly by a senior dev. That coupled with the fact that Brion seemed iffy about the implementation 4 months ago.
Comment 30 Melancholie 2009-03-15 17:49:25 UTC
(In reply to comment #28)
> Look at a version history like
> <http://nds.wikipedia.org/w/index.php?title=Burkina_Faso&action=history>. It's
> ridiculous! Between the creation of the article and the most recent update
> there were 75[!] bot edits just interrupted by three human edits. Between March
> 2007 and February 2009 there were 52[!] consecutive bot edits. And I did no
> long search for the most extreme example, the same is true for most country
> articles and all articles which are likely to have many translations.

See also bug 16228 ("filter history of edits on bots (hidebots=1)").
Comment 31 Slavik IVANOV 2009-03-15 18:39:23 UTC
> See also bug 16228 ("filter history of edits on bots (hidebots=1)").

But:
1. Still many interwiki edits are done by scripts without bot flag, unfortunately. I usually block such bots at os.wiki, if they edit too much, the practice I've borrowed from Tajik admins.
2. Another frequent case is human interwiki change by guests from other wikis: a man comes just to change an interwiki -- then why we have it in the history and why we need to check this edit (before you see the diff, such edits are always suspicious for vandalism).
Comment 32 Amir E. Aharoni 2009-03-15 18:41:39 UTC
(In reply to comment #30)
> (In reply to comment #28)
> > Look at a version history like
> > <http://nds.wikipedia.org/w/index.php?title=Burkina_Faso&action=history>. It's
> > ridiculous! Between the creation of the article and the most recent update
> > there were 75[!] bot edits just interrupted by three human edits. Between March
> > 2007 and February 2009 there were 52[!] consecutive bot edits. And I did no
> > long search for the most extreme example, the same is true for most country
> > articles and all articles which are likely to have many translations.
> 
> See also bug 16228 ("filter history of edits on bots (hidebots=1)").

I don't want the bots hidden - i want them to stop doing it and to move to centralized interwiki management. In fact, in the current state of affairs, i very much do want to see what the bots are doing, because sometimes they are not doing the right thing.

But this comment does bring up a different problem - if this extension is enabled and the links are edited in a different wiki, i don't see changes of links in my watchlist. It is a disadvantage, although i am ready to live with it, because this extension has enough advantages.

I'll write about this problem in the discussion page in meta.
Comment 33 Carn 2009-03-16 22:42:37 UTC
If this implement can be added slowly - we need to start it now. Test it in languages projects - we need discussion to begin implementation, we need example to begin discussion - example which most of users can understand - among the articles they used to edit.

[[:w:ru:User:Carn|I]] can help to socialize process in ru.wp
Comment 34 SJ 2009-04-18 21:54:17 UTC
I agree with most of the recent posters : this is a most useful improvement.  I hope it gets tested and implemented soon, at least on the small wikis. 

1. the overhead of handling bot requests on small wikis, for nothing but interwiki link fixing, is sufficiently large that there is separate global-bot policy addressing it and making their bot flagging more automatic.  of course those bots can still misfire, and you want to be able to see what bot edits are being made to actual content and userpages rather than to interwiki lists at the end of content -- having a separate wiki where all these edits can be made together and can have a more limited impact would be handy.

2. We will surely update how this process works over time.  It has been broken for many years; we can at least begin to fix it in this way, which many would welcome.

3. It makes sense to me to have a single community / area where everyone doing interwiki link maintenance cna see one another's changes, have their own RC, and discuss interwiki policy across wikis.  This will stop flooding small wikis and also create a mroe sustainabile community among the hundreds of people running related bots today -- which you can discover by visiting the village pump of any poor small wiki which is overrun with english-language 'requests' for bot flags, also flooding the bot-flagging process on meta.
Comment 35 SJ 2010-03-22 12:21:04 UTC
Any thoughts on implementing this?  It is as badly needed as ever.  I tried to explain to a coder at LibrePlanet yesterday how we handly interwiki linking, and his head almost exploded.
Comment 36 Amir E. Aharoni 2010-03-22 12:33:09 UTC
(In reply to comment #35)
> Any thoughts on implementing this?  It is as badly needed as ever.  I tried to
> explain to a coder at LibrePlanet yesterday how we handly interwiki linking,
> and his head almost exploded.

Actually a few days ago i had a chat with Nikola, the developer of the extension, and he explained to me in human terms the technical problems that are related to the implementation of this extension, most importantly - that the links on the language wikis may not be updated after they are changed on the interlanguage wiki.

This, however, doesn't seem to me half as bad as the current situation with the horrible, endless, sisyphean bot work and the need to solve all conflicts manually - a task that needs to be done, but that only a handful of people dare to do.
Comment 37 Nikola Smolenski 2010-03-22 12:43:26 UTC
Just to clarify, it's not that they may not be updated, it's that right now they are not automatically updated. See http://lists.wikimedia.org/pipermail/wikitech-l/2010-February/046962.html
Comment 38 Dan Barrett 2010-05-17 18:24:02 UTC
I just came across the Interwiki extension and we tried it in my company. The idea is GREAT, but the lack of automatic updates is VERY confusing for authors, particularly for translators. When new interlanguage links don't show up in articles, people think the wiki is broken.
Comment 39 Dan Barrett 2010-05-17 18:26:29 UTC
To solve the "no automatic updates" problem, why not pull the interlanguage links into each translated article using AJAX, without caching? The page will render quickly, while the interlanguage links fill in afterward.
Comment 40 Al Maghi 2010-07-01 16:52:33 UTC
(In reply to comment #39)
> To solve the "no automatic updates" problem, why not pull the interlanguage
> links into each translated article using AJAX, without caching? The page will
> render quickly, while the interlanguage links fill in afterward.

Good idea! The javascript do not need to be executed if the interwiki section is collapsed. And if JavaScript is not running, a link to the interwiki page should be displayed instead. The Dan Barrett solution is probably solving the update issue, isn't it?
Comment 41 Nikola Smolenski 2010-07-25 20:07:01 UTC
I have solved the problem of automatic updates. I have made another extension, called Interlanguage Central extension, that works in pair with Interlanguage extension and purges appropriate pages on dependent wikis when interlanguage links are changed on the central wiki.

The source code is on http://www.mediawiki.org/wiki/Extension:Interlanguage#Source and it is installed on http://testwiki.smolenski.rs
Comment 42 HenkvD 2010-07-26 17:58:36 UTC
What I miss is the possiblity to edit or link to the list of interwiki when you are for instance on [http://enwiki.smolenski.rs/index.php?title=Los_Serrano Los Serano on enwiki]. 
I woild suggest some kind of link or button at the In other languages box at tah page.
Comment 43 Nikola Smolenski 2010-07-27 05:57:14 UTC
I could add the edit link, but I have no idea where to put it, how should it work (only for registered users?) or how should it look like...
Comment 44 Amir E. Aharoni 2010-07-27 08:12:01 UTC
(In reply to comment #42)
> What I miss is the possiblity to edit or link to the list of interwiki when you
> are for instance on [http://enwiki.smolenski.rs/index.php?title=Los_Serrano Los
> Serano on enwiki]. 
> I woild suggest some kind of link or button at the In other languages box at
> tah page.

I think that the best idea would be to have on the editing page, like links to template pages: When you edit a page, you see a list of links to templates that it uses below the editing pane. Add a link to the interwiki list there.

This is actually the first thing that i wrote on
http://meta.wikimedia.org/wiki/Talk:A_newer_look_at_the_interlanguage_link

(Curiosity: If you google for "a newer look", that page is the first result.)
Comment 45 HenkvD 2010-07-27 17:34:51 UTC
(In reply to comment #43)
> I could add the edit link, but I have no idea where to put it, how should it
> work (only for registered users?) or how should it look like...

It should work for everybody as unregistered users should be able to understand the interwiki's as well, and they are allowed to edit them too.

I would suggest to link the "In other laguages" text to http://testwiki.smolenski.rs/index.php?title=Los_Serranos From there the users can use the edit button. Alternatively you can link direct to the edit page http://testwiki.smolenski.rs/index.php?title=Los_Serranos&action=edit

It would also be possible to add a line like English, called Interlanguage or so, and link to one of the above links,
Comment 46 Nikola Smolenski 2010-07-30 20:34:56 UTC
This is now done too, per Amir's suggestion. The link(s) are displayed below the edit form when the page is edited.

The source code is also on
http://www.mediawiki.org/wiki/Extension:Interlanguage#Source and you can see it in action on http://enwiki.smolenski.rs
Comment 47 yonidebest 2010-07-30 21:50:56 UTC
Nikola, it is not convenient to have to edit the page in order to get to the corresponding interlanguage link page. I suggest you add an option in the preferences which will allow the user to add a link to said page also in the "in other langs" box (at the end, perhaps).

on a diff topic, some wikis choose their own order of the interlanguage links. for instance, a wiki would like to have en first, then ru, the ar, and then the rest in alphabetic order according to name. Thus, i suggest a system page be created in which you can define the order of the links. i.e. [[wikimedia:interlanguage links order]]:
* en
* ru
* ar
* rest
the extention will take this wikisite prefernce into account when adding links to pages. "rest" can indicate that the rest of the langes should follow, otherwise, only the listed langs be shown.

Nikola, good job.
Comment 48 Nikola Smolenski 2010-07-31 05:40:48 UTC
It is no less convenient than editing interlanguage links is now, and putting the edit link on the "in other langs" box would be much more difficult.

It is possible to set custom sort order by using the $wgInterlanguageExtensionSortPrepend variable. This isn't something that wikis change very often, so I don't think there is need for a MediaWiki page.
Comment 49 HenkvD 2010-07-31 09:07:47 UTC
I agree: it is not convenient to have go to edit a page. If it is difficult to program an edit link on the "in other langs" I sugest to just allow "test" as a language. No programming needed for that.
Comment 50 Nikola Smolenski 2010-07-31 12:13:17 UTC
That is possible and would require minimal adjustments to the extension. Probably it is also possible for someone who is more versed in Javascript than me to make a gadget for this like there is a gadget for editing categories.

However, at this point I would first like to know whether other developers and admins think that the extension is technically good enough to be used, whether the WMF is willing to create a new project, what would be the plan for the extension's deployment, and then we could see what are the finishing touches.
Comment 51 HenkvD 2010-08-09 18:29:00 UTC
I made an Plan for implementation on http://testwiki.smolenski.rs/index.php?title=Interlanguage_Extension. Let's discuss it there.
Comment 52 HenkvD 2010-09-18 18:18:24 UTC
Is the intelanguagelink gadget broken? It does not work any longer om my userpage. (see http://enwiki.smolenski.rs/index.php?title=User:HenkvD). There used to be interlanguage links.
Comment 53 Nikola Smolenski 2010-09-19 08:56:57 UTC
It is not broken. I am developing a new version, that reads the data directly from the database, and not via the API (it is enabled on enwiki and srwiki IIRC). However, while API version supports reading from various namespaces on the central wiki, the database version does not.

Now, the question is should the central wiki keep all the interlanguage links in its main namespace, or should it keep them in their appropriate namespaces? For example, should the template namespace on the central wiki be used for interlanguage links between templates in dependent wikis, or should it be used exclusively for templates of the central wiki, and interlanguage links between templates be kept in the main namespace?
Comment 54 HenkvD 2010-09-19 11:42:32 UTC
For sure the central wiki will also have Users, Categories, Templates etc. that should have interwikis to the language wikis.

It is not essential that the interlanguage links are stored on other namespaces, but it would be easier for those cases to link to User:Xxxx instead of creating an additional page User-Xxxx or so to link to. 

Furthermore the page User:Xxxx on the central wiki should have also {{interlanguage:User-Xxxx}} to be able to really have one central page for maintaining the interlanguages.
Comment 55 Nikola Smolenski 2011-02-20 22:00:35 UTC
I have just committed r82539 with the ability to read the data from a foreign database.
Comment 56 Nikola Smolenski 2011-02-25 01:56:13 UTC
To be a bit more verbose, in r82539 and now in r82778 I believe I have fixed all the issues raised by other developers to r74204 and r74208. Now someone needs to review the fixes, review the new feature (reading links from a foreign database), and if everything is all right, let's see what is the next step.

Also, Henk's userpage now works :)
Comment 57 HenkvD 2011-03-02 19:18:10 UTC
Indeed my userpage now works :) As well as other users and other namespaces Thanks.
Comment 58 Mark A. Hershberger 2011-03-19 04:05:02 UTC
Marking fixed since Nikola seems to have fixed it.
Comment 59 Nikola Smolenski 2011-03-19 06:02:45 UTC
(I believe) I fixed all the known problems with the extension, but it still isn't implemented in Wikipedia.
Comment 60 Tim Starling 2011-03-22 02:05:21 UTC
We can't enable extensions that don't allow DB replication and load balancing. CentralAuth and the commons file repo were migrated to use LBFactory long ago. This extension seems to be based on those modules before they were migrated. 

Basically, instead of configuring complete DB constructor parameters, you just need a DB name, and the rest is done in $wgLBFactoryConf. Then to get a connection, use:

$lb = wfGetLB( $dbname );
$dbw = $lb->getDB( DB_MASTER, array(), $dbname );
$dbr = $lb->getDB( DB_SLAVE, array(), $dbname );
Comment 61 Tim Starling 2011-03-23 06:25:50 UTC
Whole extension review on CR r82778.
Comment 62 Erik Moeller 2011-03-24 07:35:52 UTC
1) What's the proposed name of the central repository? I would suggest something like data.wikimedia.org so we can potentially expand it in future for other cross-project data sharing.

2) Would this be used for the non-article namespace? If so I assume we'd have to make sure that the central repository has equivalents for all namespaces that are commonly used (including things like Portal:).

3) Would this be used for InterProject links? Potentially any link list could point to any Wikimedia project, and the script could filter it down to something appropriate. For example, if the link lists includes all the Wikipedia articles for "Dog", plus all the Wiktionary entries, on the English Wikipedia it could pull the Wikipedia interlanguage links + English Wiktionary, on the German Wikipedia it could pull the German Wikipedia interlanguage links + German Wiktionary, etc.

It seems wise to start with Wikipedia only, but I think it's worth thinking about the other projects now. We almost certainly don't want an interlanguage link wiki for each of the multilingual Wikimedia projects, IMO. Bug 708 is also one of the most popular feature requests.

4) Finally, on the user experience side, in addition to formatting the links in the content area (see http://meta.wikimedia.org/wiki/A_newer_look_at_the_interlanguage_link/Central_wiki_style_straw_poll ), I think we'll need to think about how you access the link list in the first place. IMO an edit link in the sidebar that pops up an editing interface on the local wiki would be preferable to sending people to an external site.
Comment 63 Purodha Blissenbach 2011-03-24 15:40:01 UTC
(In reply to comment #62)
> 2) Would this be used for the non-article namespace? If so I assume we'd have
> to make sure that the central repository has equivalents for all namespaces
> that are commonly used (including things like Portal:).

Since external namespace names do not play any role on the central wiki, we do not need any for interlanguage linking. Thus, we can use namespaces on the central wiki to distinguish various kinds of interlanguage links. Such as the namespaces "Wikipedia:", or "Wikipedia-Interlanguage:" for the interlanguage links between Wikipedias, and the namespace "Wiktionary:" for those between Wiktionaries, etc.
Comment 64 Tim Starling 2011-03-24 23:47:34 UTC
(In reply to comment #62)
> 1) What's the proposed name of the central repository? I would suggest
> something like data.wikimedia.org so we can potentially expand it in future for
> other cross-project data sharing.

I'm not aware of any proposal. The current software makes it necessary to have one wiki per second-level domain.

> 2) Would this be used for the non-article namespace? 

The software won't restrict it to the main namespace, so yes, I imagine it will be used for other namespaces.

> 3) Would this be used for InterProject links? 

No.

> Potentially any link list could
> point to any Wikimedia project, and the script could filter it down to
> something appropriate. For example, if the link lists includes all the
> Wikipedia articles for "Dog", plus all the Wiktionary entries, on the English
> Wikipedia it could pull the Wikipedia interlanguage links + English Wiktionary,
> on the German Wikipedia it could pull the German Wikipedia interlanguage links
> + German Wiktionary, etc.

Sure, anything's possible, with sufficient software development resources. But such resources have not materialised, so I'm just looking to enable this extension with a few minor tweaks.

If we need to have a stopgap solution, I'd prefer it to be implemented in a way that doesn't lock us in to a particular architecture going forward. We are talking about having a special syntax for interlanguage link references in articles:

{{#interlanguage: Pied Currawong}}

As long as we stick with something simple like that, and don't expose implementation details to the users on the content wikis, then we can easily change the data source in the future.

In particular, I don't want to see:

{{#interlanguage: Wikipedia-Interlanguage:Pied Currawong}}

> 4) Finally, on the user experience side, in addition to formatting the links in
> the content area (see
> http://meta.wikimedia.org/wiki/A_newer_look_at_the_interlanguage_link/Central_wiki_style_straw_poll
> ), I think we'll need to think about how you access the link list in the first
> place. IMO an edit link in the sidebar that pops up an editing interface on the
> local wiki would be preferable to sending people to an external site.

Sure, it's possible, if resources can be allocated for it. Note that there will be a need for policy, review and access control. Nothing is ever simple on a wiki.
Comment 65 Erik Moeller 2011-03-25 07:20:28 UTC
I think deploying to Wikipedia-only without significant feature additions makes sense for now; that'll give us some real-world usage characteristics. 

But, is there a reason to not add at least a "manage links" link to the bottom of the language link list of any page that has the {{#interlanguage}} invocation, pointing to the relevant page? IMO this is a deployment blocker because without it, the external management interface is not discoverable at all. Also, if we do deploy, I would suggest putting this new wiki into the list of auto-login wikis.
Comment 66 Amir E. Aharoni 2011-03-25 12:48:53 UTC
(In reply to comment #65)
> But, is there a reason to not add at least a "manage links" link to the bottom
> of the language link list of any page that has the {{#interlanguage}}
> invocation, pointing to the relevant page? IMO this is a deployment blocker
> because without it, the external management interface is not discoverable at
> all. Also, if we do deploy, I would suggest putting this new wiki into the list
> of auto-login wikis.

This is already implemented. You can see it on the test wiki:
http://enwiki.smolenski.rs/index.php?title=Belgrade&action=edit

There's a link at the bottom under the title "Pages with interlanguage links".
Comment 67 Erik Moeller 2011-03-26 08:19:12 UTC
Amir, I'm glad there's a link, but from a usability standpoint this is a pretty terrible implementation. In order to follow that link you have to a) notice it in a place that's already fairly cluttered, b) make the mental connection between "interlanguage links" and the links that _aren't even visible_ while editing the page. Moreover, the passive "Pages with interlanguage links" does not suggest any action that can be taken, and indeed, takes me to a "view" page which then separately has to be edited.

I would strongly suggest putting an "edit" link at the bottom of the language links instead when the page is rendered. Yes, there may be edge cases where multiple such links need to be rendered, but let's not design for edge cases. Yes, the user may not have rights to edit, but again, let's not design for edge cases -- it's more efficient to send them to &action=edit, even if that's a "view source" page in a few rare circumstances.
Comment 68 Nikola Smolenski 2011-03-26 10:58:09 UTC
I can add the edit links to the bottom of the toolbox if that is desirable, but adding them to the bottom of the language links would require a new MediaWiki hook so it can't be done as an extension at this point.

Regarding use for multiple projects, it is possible to do it in multiple ways with slight tweaks. For example, it would be very easy to make each project use a disambiguation word after a title, and you wouldn't have to type it in on the project (so on Wikipedia {{interlanguage:category:dog}} fetches the links from central wiki article [[Category:Dog (Wikipedia)]] and on Wiktionary {{interlanguage:category:dog}} fetches the links from central wiki article [[Category:Dog (Wiktionary)]]. Having each project in its separate namespaces would also be possible but more difficult.
Comment 69 Mark A. Hershberger 2011-03-26 18:04:18 UTC
(In reply to comment #68)
> I can add the edit links to the bottom of the toolbox if that is desirable, but
> adding them to the bottom of the language links would require a new MediaWiki
> hook so it can't be done as an extension at this point.

Created Bug #28255 to request the creation of this hook.
Comment 70 Purodha Blissenbach 2011-03-27 05:08:01 UTC
(In reply to comment #63)
> 
> Since external namespace names do not play any role on the central wiki, we do
> not need any for interlanguage linking. Thus, we can use namespaces on the
> central wiki to distinguish various kinds of interlanguage links.

Just to clarify: This is not to be misunderstood, I am proposing to keep all kinds of name space links intermingled in ONE namespace in the central wiki - after all, name spaces are crosslinked interwikiwise at times, e.g. Portal with (main), or Help and Project are common examples, so we cannot avoid crossnamespace links anyways.

I do NOT, however, propose to add a central wiki namespace name in the {#interwiki...} syntax on individual project wikis. The central wiki namespace name, if any, should be set once per project wiki when the extension is installed, and should be implicit from a users standpoint of view. I suggest using what the pywikipediabot framework calls "wiki family" for the central wiki namespace name, but that's a different subject matter.
Comment 71 Purodha Blissenbach 2011-03-27 06:32:44 UTC
(In reply to comment #66)
> 
> This is already implemented. You can see it on the test wiki:
> http://enwiki.smolenski.rs/index.php?title=Belgrade&action=edit
> 
> There's a link at the bottom under the title "Pages with interlanguage links".

When I follow that blue link at the bottom, and get to the central wiki page, and it does not yet exist, there is a red link as well in the article or article preview. When I follow the red link, I get to another central wiki page named "ZZ Top?action=edit" for instance.

There is a need to treat URLs differently, depending on whether or not an "?" is already present in them, before appending another one.
Comment 72 Nikola Smolenski 2011-03-30 04:57:49 UTC
So, in r84997 I have added support for the load balancer. In previous revisions I have (hopefully) fixed all the objections that Tim raised in his code review, or came to the point where further changes in MediaWiki are required to fix them. A new review might be in order.
Comment 73 Nikola Smolenski 2011-04-03 07:56:19 UTC
I added support for edit links below the toolbox in r85233 and r85233.
Comment 74 Nikola Smolenski 2011-04-03 08:00:54 UTC
The previous comment should read: below the language list in the language box.
Comment 75 Tim Starling 2011-04-05 06:47:45 UTC
I've reviewed it again, see CR. In brief, here's what I need before deployment:

* setProperty()/getProperty() in the content wikis.
* A LinksUpdate hook in the central wiki.
* Table-based content display on the central wiki, per the meta straw poll.
Comment 76 Erik Moeller 2011-04-05 18:32:15 UTC
I'm asking Brandon to take a quick additional look at this from an interaction design perspective.

Nikola, thanks for making the suggested change. I would also suggest pointing the link directly to &action=edit -- yes, there may be permission issues, but for frequent link workers it's probably preferable to have that additional edit action removed from the workflow. And many of the permission issues can IMO be addressed by adding the new link wiki to the auto-login list.
Comment 77 Nikola Smolenski 2011-04-06 18:48:15 UTC
It does point there, I just haven't advertised it ;)
Comment 78 Amir E. Aharoni 2011-04-12 20:24:25 UTC
Idea: The interlanguage wiki domain can be named http://mul.wikipedia.org . "mul" is the ISO 639 code for "multiple languages".
Comment 79 Nemo 2011-04-12 20:51:03 UTC
(In reply to comment #78)
> Idea: The interlanguage wiki domain can be named http://mul.wikipedia.org .
> "mul" is the ISO 639 code for "multiple languages".

In case we created a single wiki for all projects, it would be mul.wikimedia.org; otherwise, this would block bug 13334 for Wikisource and Wikiversity, but this bug is obviously much higher priority.
Comment 80 Waldir 2011-04-12 21:20:57 UTC
I like Erik's suggestion (comment #62) of data.wikimedia.org, since the central repository could later be enhanced with the ability to share other stuff (tabular data for infoboxes, etc). I assume that wouldn't be incompatible with the changes introduced to mediawiki by the Interlanguage extension.
Comment 81 Tim Starling 2011-04-13 03:56:08 UTC
I think interlanguage.wikipedia.org is the obvious choice for now, per comment #65. We can have data.wikimedia.org when we have software for it.
Comment 82 Brandon Harris 2011-04-13 21:16:27 UTC
Per Erik's request, I have made a design pass for the interface of this extension.  It describes an ideal situation, with notes about minimal improvement.

It is available here: http://www.mediawiki.org/wiki/Extension:Interlanguage/WMF_Design_Pass
Comment 83 Erik Moeller 2011-04-13 22:59:05 UTC
Thanks, Brandon. I agree with all your design recommendations. The main additional point I would make is that it may be more desirable to work towards an inline editor (adds a row with editable cells right on the page) rather than a modal pop-up editor.

From a deployment standpoint, can we target having the minimally improved edit links (per Brandon's spec) and the minimally improved table display (already in Tim's list)?

For the table, if we have fields like "Notes" or "Descriptions", we'll need a standardized wiki markup representation so that it can be cleanly manipulated either through a UI or through wikitext.

Regarding the wiki, I'll go on record as saying that I'd still prefer data.* because it'll avoid renaming nightmares later (and it's quite likely that we'll end up overloading the project with additional features given its currently very narrow scope), but I'll leave it at that to avoid bikeshedding. :-)
Comment 84 Nikola Smolenski 2011-05-09 18:40:32 UTC
I believe that in r87753 I fixed all the remaining issues. If no new issues appear, the extension is good to go.
Comment 85 denny vrandecic 2011-05-13 22:30:31 UTC
I really love the idea of the extension, and think that this will reduce dramatically maintenance efforts on the Wikipedias.

My concern is that it's design has redundancy, and it is unclear what it means if the two sides get out of sync.

The local wiki states on page Y:

{{interlanguage:X}}

and the central wiki then links back to Y. So the information that X maps to Y is still saved at two places (which is still better then the current situation, where this information is saved in (n = number of language) places instead of merely in two).

A system that merely uses 

{{interlanguage}}

would work, since the central wiki knows the page when it makes the request.

Don't regard this as a blocker though, just mentioning how to make it even simpler.
Comment 86 Amir E. Aharoni 2011-05-30 13:02:27 UTC
Nudge :)

Is there any technical reason now not to deploy this? (Except developers' being busy with other things...)
Comment 87 Helder 2011-05-30 13:18:10 UTC
It is on the review queue:
https://secure.wikimedia.org/wikipedia/mediawiki/wiki/Review_queue#Extensions
but I think the problems mentioned on r82778#code-comments were fixed in subsequent revisions.

I don't know the current status of the "Server-side migration script" mentioned in the queue...
Comment 88 Matthias Becker 2011-10-06 19:10:01 UTC
There has been a related discussion on this started at:
http://de.wikipedia.org/wiki/Wikipedia:Projektdiskussion/Wikidata
German Wikipedia users discuss here what they expect from a central data repository, off course from the (mainly) wikipedians point of view.

Pitifully at this moment no english abstract available.
Comment 89 denny vrandecic 2011-10-07 07:09:51 UTC
There is an English version of the whole proposal for Wikidata. The German abstract mentioned in Comment 88 is indeed just the translation of the English abstract.

http://meta.wikimedia.org/wiki/New_Wikidata
Comment 90 Erik Moeller 2011-12-28 19:14:14 UTC
This bug has been quiet for a long time, and people are legitimately asking whether this is something we're ever going to deploy or not.

I've asked Siebrand whether this is something he would like to take on with the internationalization team. Here's a quick take from my end:

I've just poked at the last version of it. It looks like it's now using a special parser tag called {{languagelink}} to render the language links both in the sidebar and the wiki page.

This is better, but I'd still like to get this closer to the design/workflow proposed in http://www.mediawiki.org/wiki/Extension:Interlanguage/WMF_Design_Pass , specifically, to have a custom UI for adding (and ideally editing) links.

Intuitively, I'd prefer a less verbose syntax for managing the links, such as:

<languages>
de|Wikipedia:Hauptseite|This is the new German Main page, it used to be at [[Hauptseite]]
en|Main Page
</languages>

(This matches the <gallery> syntax.) It could then be parsed into a nice table and made editable as such.

It'll also need a final code review before it's deployable.
Comment 91 Maarten Dammers 2011-12-28 21:36:19 UTC
Having read plenty of discussions about interwiki/interlanguage links I always notice two things getting mixed:
* The interlanguage model
* The implementation of this model

Say [de, en, fr, nl] are sets of articles in different languages.

If de:A, en:A, fr:A & nl:A and all exist and are about the exact subject these should all be linked. That's the easy model. The current implementation is Pywikipedia bots (with shitloads of edits).

But we don't live in an ideal world. For clearly defined subjects the interwiki's are clear, but for not so clearly defined subjects or broad subjects you end up with things like:

de:A -> en:A -> fr:A' -> nl:A -> de:A'

We call these interwiki conflicts and some can't be solved, ever. How does this extension deal with this situation?
Comment 92 Amir E. Aharoni 2011-12-28 21:41:03 UTC
(In reply to comment #91)
> We call these interwiki conflicts and some can't be solved, ever. How does this
> extension deal with this situation?

Last time i checked, this extension just co-exists with the current implementation. You can use both the extension (star model) and the links inside the articles (diamond model). So it definitely doesn't interfere and doesn't make things worse.

It will probably make things better, because it will become much easier to manually solve the conflicts that can be solved.
Comment 93 Krinkle 2011-12-29 09:36:51 UTC
I'd also like to repeat the idea mentioned in other threads about limitations to this model and possible overlap (or even superseded by) interwiki transclusion.

One way to utilize that is to transclude the interwiki links from the central wikis. This also has the advantage of the ability for things like {{FA|..}} or perhaps even {{commonscat}} to come along.

Also, Templates {{FA}}, {{Commonscat}}, {{Information}} etc. would be centralized on a wiki (internationalized and all).
Comment 94 Erik Moeller 2011-12-30 06:15:52 UTC
Timo: Yeah, though the interwiki transclusion system introduces additional layers of complexity that haven't yet been fully examined. It's currently targeted to receive a more comprehensive review around March 2012 at which point we'll get a good sense of how realistic a near term roll-out of that is.

If we have a standard format for the links it should be relatively straightforward to migrate in the event we want to use a consolidated transclusion system later, no? And it seems to me that regardless of the transclusion mechanism, we'd want to have 1) a nice UI for managing the links, 2) a standard format for parsing them that's a bit more flexible and expressive than "a bunch of links or templates next to each other".

In any case, IMO the only way the Interlanguage extension will realistically receive some love in the near future is if the i18n team decides to take it on. Siebrand will deliver an initial review on that within a couple of weeks.
Comment 95 Jan Kucera (Kozuch) 2011-12-30 15:45:00 UTC
Because of votes rasing importance/priority according to following scheme:
15+ votes - highest
5-15 votes - high
Community must have a voice within development.

Regards, Kozuch
http://en.wikipedia.org/wiki/User:Kozuch
Comment 96 Brandon Harris 2011-12-30 17:53:43 UTC
We do not use voting to define our priorities.  Returning priority to previous value.
Comment 97 Sumana Harihareswara 2012-04-04 14:25:25 UTC
(In reply to comment #94)
> In any case, IMO the only way the Interlanguage extension will realistically
> receive some love in the near future is if the i18n team decides to take it on.
> Siebrand will deliver an initial review on that within a couple of weeks.

Siebrand, sounds like the ball is in your court. :-)  Any word?

Nikola, it would be great if you could put this extension into https://www.mediawiki.org/wiki/Git/Conversion/Extensions_queue so it can be migrated to Git, since that's now a prerequisite for WMF deployment.

Thanks.
Comment 98 Siebrand Mazeland 2012-04-04 15:13:58 UTC
This issue was discussed by e-mail between the Wikidata people (Denny), Erik Moeller, Alolita Sharma, Robla and Tim Starling end of december 2011, beginning of 2012. In the e-mail thread, I asked Denny to update the status of this issue, and he confirmed he would on 2012-01-06. I guess he didn't get to that.

So here's my relevant text from that thread:

As promised my feedback. I'll be short, given the earlier input, not in the least by Denny. Given the near 100 comments on bug 15607, the years of discussion that already preceeded the opening of bug 15607 in 2008 and my personal in-depth knowledge of the incredible efforts and resources that it takes to maintain interlanguage links in Wikipedia alone, let alone for Wiktionary and other projects -- SieBot has made over 10 million interwiki edits -- this is a hot topic in a part of the (very active) (bot running) community.

Partly because this issue has been open and actively discussed for this long, and because of the WMDE run Wikidata project's goals and timeline, I think it's not a good idea to shepard an interim solution now-ish and try AND implement a solid future proof solution based on Wikidata before the end of 2012. Despite the relatively easy technical transition for the interlanguage extension, these types of changes require large community engagement efforts to implement successfully, and doing that twice in one year would, frankly and in my opinion, be sub-optimal use of our time. If there is substantial pressure from the Wikimedia executives, I wouldn't resign over it, but for now I would prefer to not spend my team's resources on it. Is that okay with you, Erik?

I would like to ask Denny to update bug 15607 with the current insights and a timeline.
Comment 99 Nikola Smolenski 2012-04-05 12:00:44 UTC
(In reply to comment #97)
> Nikola, it would be great if you could put this extension into
> https://www.mediawiki.org/wiki/Git/Conversion/Extensions_queue so it can be
> migrated to Git, since that's now a prerequisite for WMF deployment.

I have put it in the queue, since it might be useful for someone else and the code might be reused for Wikidata.
Comment 100 denny vrandecic 2012-04-05 12:05:58 UTC
Sorry, indeed I failed to update the info on this bug.

We have Nikola working with us on Wikidata, and we will take some code and his experience into Wikidata. The functionality discussed here is our first priority, and we expect it to be deployment-ready by August (that is the current plan, it might shift forward or backward). A demo will be given at Wikimania in July.

I hope that helps.
Comment 101 Helder 2012-04-07 11:20:35 UTC
For the record: this bug was mentioned in a talk page of the [[m:Wikidata]] project. Here is the link in case it is relevant:

https://meta.wikimedia.org/wiki/Talk:Wikidata/Technical_proposal#Interlanguage_links
Comment 102 snaevar 2012-04-07 16:24:25 UTC
The "minor fixes" mentioned in the Review queue needs to be removed from the waiting list as they have already been fixed per comments 72-75, comment 84 and bug 28194.
Additionally, the "waiting for [...] insights and timeline from Denny" needs to be removed from the Review queue as well, as he has already written those at comment 100.

In my opinion, the next logical step would be discussing the "server-side migration script" (mentioned in the Review queue), that is what the script would do or whether that has already been done.

Siebrand: Two Interlanguage messages are not on translatewiki.org, one in InterlanguageCentral.i18n.magic.php and the other in InterlanguageCentral.i18n.php.
Comment 103 Sumana Harihareswara 2012-08-17 18:51:02 UTC
Denny, could you please give an update based on the demo you gave at Wikimania?  Thanks!
Comment 104 Amir E. Aharoni 2012-08-17 18:53:13 UTC
Just for the record: As the opener of this bug, I am very happy with Wikidata as a replacement.

I hope that the comments here are useful to Wikidata developers.
Comment 105 Sumana Harihareswara 2012-08-17 20:08:48 UTC
OK, closing as WONTFIX but in the kindest possible way. :-) Thanks everyone for your contributions and discussion.
Comment 106 Amir E. Aharoni 2013-03-07 05:34:44 UTC
\o/

Just a symbolic gesture to celebrate the deployment of the Wikidata client to all Wikipedias.

Wikidata developers, thank you so much for the hard work.
Comment 107 Nemo 2013-03-07 10:21:14 UTC
(In reply to comment #106)
> \o/
> 
> Just a symbolic gesture to celebrate the deployment of the Wikidata client to
> all Wikipedias.
> 
> Wikidata developers, thank you so much for the hard work.

And here's the relevant bug for clarity. :)

*** This bug has been marked as a duplicate of bug 44515 ***
Comment 108 jeblad 2013-03-07 11:28:53 UTC
Thanks! :)
Comment 109 Nemo 2013-05-02 07:30:51 UTC
For an "even newer look at the interlanguage link", see the UniversalLanguageSelector proposal at http://thread.gmane.org/gmane.org.wikimedia.mediawiki.i18n/662
You can already see reports being filed about it <https://bugzilla.wikimedia.org/buglist.cgi?query_format=advanced&short_desc=INTERLANG&short_desc_type=casesubstring> and help testing at http://dev.translatewiki.net

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


Navigation
Links