Page MenuHomePhabricator

Install Extension:Interlanguage on en.wikipedia
Closed, ResolvedPublic

Description

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:

  1. Setting up a new wiki for the links themselves.
  2. Testing the extension, probably in test.wikipedia.org.
  3. 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.
  4. 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.


Version: unspecified
Severity: enhancement
URL: http://meta.wikimedia.org/wiki/A_newer_look_at_the_interlanguage_link

Details

Reference
bz15607

Event Timeline

There are a very large number of changes, so older changes are hidden. Show Older Changes

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?

(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?

(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.

yonidebest wrote:

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.

(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:

The extension supports custom sorting orders, so that is not a problem. In hewiki's configuration, just add

$wgInterlanguageExtensionSortPrepend = array('en');

(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)?

(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.

(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

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?

amikeco wrote:

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.

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.

(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.

Wiki.Melancholie wrote:

(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)").

amikeco wrote:

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).

(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.

carn wrote:

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

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.
  1. 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.
  1. 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.

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.

(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.

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

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.

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.

alfred.maghi wrote:

(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?

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

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 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...

(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.)

(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,

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

yonidebest wrote:

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.

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.

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.

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.

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.

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?

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.

I have just committed r82539 with the ability to read the data from a foreign database.

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 :)

Indeed my userpage now works :) As well as other users and other namespaces Thanks.

Marking fixed since Nikola seems to have fixed it.

(I believe) I fixed all the known problems with the extension, but it still isn't implemented in Wikipedia.

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 );

Whole extension review on CR r82778.

  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.
  1. 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:).
  1. 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.

  1. 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.

(In reply to comment #62)

  1. 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.

(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.

  1. 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.

  1. 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:

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:

  1. 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.

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.

(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".

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.

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.

(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.

(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.

(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.

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.

I added support for edit links below the toolbox in r85233 and r85233.

The previous comment should read: below the language list in the language box.

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.

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.

It does point there, I just haven't advertised it ;)

Idea: The interlanguage wiki domain can be named http://mul.wikipedia.org . "mul" is the ISO 639 code for "multiple languages".

(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.

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.

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.

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

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. :-)

I believe that in r87753 I fixed all the remaining issues. If no new issues appear, the extension is good to go.

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.

Nudge :)

Is there any technical reason now not to deploy this? (Except developers' being busy with other things...)

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...

matthiasbecker1967 wrote:

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.

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

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.

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?

(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.

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).

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.

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

We do not use voting to define our priorities. Returning priority to previous value.

sumanah wrote:

(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.

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.

(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.

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.

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

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.

sumanah wrote:

Denny, could you please give an update based on the demo you gave at Wikimania? Thanks!

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.

sumanah wrote:

OK, closing as WONTFIX but in the kindest possible way. :-) Thanks everyone for your contributions and discussion.

\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.

(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 ***

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

@Amire80 : I think this request is no longer valid now we have Wikidata. Close it?

Nevermind. Why does this stupid system send out notifications for closed tasks that get moved around? :@