implementing the Interlanguage extension

classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|

implementing the Interlanguage extension

Amir Elisha Aharoni
Sorry about bugging the list about it, but can anyone please explain
the reason for not enabling the Interlanguage extension?

See bug 15607 -
https://bugzilla.wikimedia.org/show_bug.cgi?id=15607

I believe that enabling it will be very beneficial for many projects
and many people expressed their support of it. I am not saying that
there are no reasons to not enable it; maybe there is a good reason,
but i don't understand it. I also understand that there are many other
unsolved bugs, but this one seems to have a ready and rather simple
solution.

I am only sending it to raise the problem. If you know the answer, you
may comment at the bug page.

Thanks in advance.

--
Amir Elisha Aharoni

heb: http://haharoni.wordpress.com | eng: http://aharoni.wordpress.com
cat: http://aprenent.wordpress.com | rus: http://amire80.livejournal.com

"We're living in pieces,
 I want to live in peace." - T. Moore

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: implementing the Interlanguage extension

Andrew Garrett
On Sun, Mar 15, 2009 at 4:10 AM, Amir E. Aharoni <[hidden email]> wrote:
> Sorry about bugging the list about it, but can anyone please explain
> the reason for not enabling the Interlanguage extension?
>
> See bug 15607 -
> https://bugzilla.wikimedia.org/show_bug.cgi?id=15607
>

In general, extensions with this status haven't been implemented
because they haven't been reviewed by a highly experienced developer.


--
Andrew Garrett

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: implementing the Interlanguage extension

Amir Elisha Aharoni
2009/3/15 Andrew Garrett <[hidden email]>:

> On Sun, Mar 15, 2009 at 4:10 AM, Amir E. Aharoni <[hidden email]> wrote:
>> Sorry about bugging the list about it, but can anyone please explain
>> the reason for not enabling the Interlanguage extension?
>>
>> See bug 15607 -
>> https://bugzilla.wikimedia.org/show_bug.cgi?id=15607
>>
>
> In general, extensions with this status haven't been implemented
> because they haven't been reviewed by a highly experienced developer.

Brion wrote a few comments there, but i didn't understand what exactly
is the problem.

--
Amir Elisha Aharoni

heb: http://haharoni.wordpress.com | eng: http://aharoni.wordpress.com
cat: http://aprenent.wordpress.com | rus: http://amire80.livejournal.com

"We're living in pieces,
 I want to live in peace." - T. Moore

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: implementing the Interlanguage extension

Nikola Smolenski
Дана Saturday 14 March 2009 23:20:01 Amir E. Aharoni написа:
> 2009/3/15 Andrew Garrett <[hidden email]>:
> > On Sun, Mar 15, 2009 at 4:10 AM, Amir E. Aharoni <[hidden email]>
wrote:

> >> Sorry about bugging the list about it, but can anyone please explain
> >> the reason for not enabling the Interlanguage extension?
> >>
> >> See bug 15607 -
> >> https://bugzilla.wikimedia.org/show_bug.cgi?id=15607
> >
> > In general, extensions with this status haven't been implemented
> > because they haven't been reviewed by a highly experienced developer.
>
> Brion wrote a few comments there, but i didn't understand what exactly
> is the problem.

Seconded. Brion's comments are:

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

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

I don't fully understand them.

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: implementing the Interlanguage extension

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

I think that it is a request to start looking into ways to handle
interwiki links from the inside, rather than still relying on bots to
update the pages.

The interlanguage extension is a nice first step towards the inclusion
in core of all the work that we are currently doing with interwiki
bots. But why would we rely on, again, client-side bots to update
anything? The bot work seems to be smaller with this system, agreed.
But perhaps these new type of bots updates could simply be transformed
into Jobs and put in the Job queue.

At least the idea is to try to find a workflow that could be included
in the server as much as possible instead of saying that client-side
bots will handle the update tasks.

2009/3/17 Nikola Smolenski <[hidden email]>:

> Дана Saturday 14 March 2009 23:20:01 Amir E. Aharoni написа:
>> 2009/3/15 Andrew Garrett <[hidden email]>:
>> > On Sun, Mar 15, 2009 at 4:10 AM, Amir E. Aharoni <[hidden email]>
> wrote:
>> >> Sorry about bugging the list about it, but can anyone please explain
>> >> the reason for not enabling the Interlanguage extension?
>> >>
>> >> See bug 15607 -
>> >> https://bugzilla.wikimedia.org/show_bug.cgi?id=15607
>> >
>> > In general, extensions with this status haven't been implemented
>> > because they haven't been reviewed by a highly experienced developer.
>>
>> Brion wrote a few comments there, but i didn't understand what exactly
>> is the problem.
>
> Seconded. Brion's comments are:
>
>> 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?
>

>
> I don't fully understand them.
>
> _______________________________________________
> Wikitech-l mailing list
> [hidden email]
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l



--
Nicolas Dumazet — NicDumZ [ nɪk.d̪ymz ]

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: implementing the Interlanguage extension

Nikola Smolenski-2
In reply to this post by Nikola Smolenski
If you don't know what this is about, refer to:

- http://www.mail-archive.com/wikitech-l@.../msg01907.html
- https://bugzilla.wikimedia.org/show_bug.cgi?id=15607
- http://www.mediawiki.org/wiki/Extension:Interlanguage
- http://meta.wikimedia.org/wiki/A_newer_look_at_the_interwiki_link
-
http://strategy.wikimedia.org/wiki/Proposal:A_central_wiki_for_interlanguage_links

Дана Tuesday 17 March 2009 07:01:39 Nikola Smolenski написа:

> Дана Saturday 14 March 2009 23:20:01 Amir E. Aharoni написа:
> > 2009/3/15 Andrew Garrett <[hidden email]>:
> > > On Sun, Mar 15, 2009 at 4:10 AM, Amir E. Aharoni
> > > <[hidden email]>
>
> wrote:
> > >> Sorry about bugging the list about it, but can anyone please explain
> > >> the reason for not enabling the Interlanguage extension?
> > >>
> > >> See bug 15607 -
> > >> https://bugzilla.wikimedia.org/show_bug.cgi?id=15607
> > >
> > > In general, extensions with this status haven't been implemented
> > > because they haven't been reviewed by a highly experienced developer.
> >
> > Brion wrote a few comments there, but i didn't understand what exactly
> > is the problem.

I talked with Brion about the extension at the 2009 developers meeting in
Berlin (I'm sorry it took me so long to report on this). He considered the
extension a good idea in general, and he clarified to me what did he mean in
his bugzilla comments. So:


"The lack of automatic updates seems less than ideal" - we actually skipped
this. One of the problems is that there is no way for the new links to
automatically propagate from the central wiki to the client wikis. In order
for the links to propagate one has to edit the page or purge the page cache
on the client wikis for every change on the central wiki.

Currently, if the extension would be implemented, this would either not be
done at all (causing a delay in the interwiki propagation) or be done by bots
(which is stupid). I guess the solution is to add a hook to
ArticleSaveComplete on the central wiki that would go around and purge caches
(how? via API again?) on the client wikis.



"as does the multiple fetching of link data over the HTTP API on every page
render" - Brion would like the links to be fetched directly from the database
of the central wiki (similar to how Commons image description is fetched
now), instead of via API as is the case now. This should be very easy to do.
(I'd keep fetching via API in the extension in case someone would like to
play with it, but fetching from the database should be the default.)


"Management UI by manual editing of offsite pages looks pretty ugly; what
could be done to improve this?" - Brion thought that the interwiki management
on the central wiki should be done on the client wikis.

The first idea was to create some special page for the client wikis that would
enable the editors to add the links to some central database (wouldn't even
have to be a wiki). But this was dropped: it wouldn't be possible to control
who added a link, where, someone could simply delete all the links etc.

Long story short, the final idea was to, basically, enable editing of the
central wiki through the client wiki. Editors of the client wiki could,
probably on some special page, edit the list of interwikis, and these edits
would affect the articles on the central wiki, be viewable in recent changes
and article histories there etc.

This would be humongously complicated and I don't think it could be done in a
reasonable time, if at all. So, I don't think it should be done.

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Interlanguage Extension - going on

Nikola Smolenski-2
Interlanguage Extension (
http://www.mediawiki.org/wiki/Extension:Interlanguage ) is a MediaWiki
extension that enables keeping the interlanguage links for all the languages
at a central wiki, without the need for the herd of bots that maintain the
links. Introducing it to Wikimedia projects is a featured proposal on the
Strategic Planning wiki (
http://strategy.wikimedia.org/wiki/Proposal:A_central_wiki_for_interlanguage_links ).

I have recently fixed some of its shortcomings (see
https://bugzilla.wikimedia.org/show_bug.cgi?id=15607#c41 and onward) and I
believe that the extension is now ready for practical use. Could anyone
interested review the code and see if it is technically good enough, and if
there is anything else that needs to be done? And if it is good enough and
there is nothing critical missing, what would be the steps to test it in the
real world and actually deploy it?

The only things that I see remain to be done, from the programming
perspective, are:

- Reading the links from a foreign database instead of via the API. Is there
a "proper" way to do this?

- Updating links on dependent wikis when deleting, undeleting etc. articles on
the central wiki.

- Purging the pages on dependent wikis via the API, or smarter way of purging
without the API. Why does purging via the API require login, when purging the
usual way does not?

- Smarter way of handling job queues, probably separating each page to a
separate job or similar.

But in my opinion, real world testing could start without any of that.

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Interlanguage Extension - going on

Roan Kattouw-2
2010/8/6 Nikola Smolenski <[hidden email]>:
> I have recently fixed some of its shortcomings (see
> https://bugzilla.wikimedia.org/show_bug.cgi?id=15607#c41 and onward) and I
> believe that the extension is now ready for practical use. Could anyone
> interested review the code and see if it is technically good enough, and if
> there is anything else that needs to be done? And if it is good enough and
> there is nothing critical missing, what would be the steps to test it in the
> real world and actually deploy it?
>
When it has passed review, I suppose we could set up a few wikis at
prototype.wikimedia.org and test it there. It was originally set up
for the usability initiative but it seems to be used for increasingly
random testing purposes now, and we have no other proper place for
this.

> - Reading the links from a foreign database instead of via the API. Is there
> a "proper" way to do this?
>
Yes. You can obtain a connection to a foreign DB with wfGetDb(
DB_SLAVE, array() 'wikiID' ); . Both the wiki ID and the API URL can
be obtained from the interwiki table now (that is, there are fields
for them, we're not actually filling those fields yet), as part of
Peter's work on the iwtransclusion branch for GSoC. How have you been
obtaining API URLs anyway?

> - Updating links on dependent wikis when deleting, undeleting etc. articles on
> the central wiki.
>
This is something the iwtransclusion branch also has to address. The
current plan is to do that using a global templatelinks table.

> - Purging the pages on dependent wikis via the API, or smarter way of purging
> without the API. Why does purging via the API require login, when purging the
> usual way does not?
>
That's a bug in the API purge module; I'll fix it later today. Again,
the iwtransclusion branch also needs to take care of purging. There's
no code for it yet, but I don't think it involves more than updating
page_touched in the remote DB and notifying Squid.

Roan Kattouw (Catrope)

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Interlanguage Extension - going on

Nikola Smolenski-2
On 08/06/2010 11:51 AM, Roan Kattouw wrote:

> 2010/8/6 Nikola Smolenski<[hidden email]>:
>> I have recently fixed some of its shortcomings (see
>> https://bugzilla.wikimedia.org/show_bug.cgi?id=15607#c41 and onward) and I
>> believe that the extension is now ready for practical use. Could anyone
>> interested review the code and see if it is technically good enough, and if
>> there is anything else that needs to be done? And if it is good enough and
>> there is nothing critical missing, what would be the steps to test it in the
>> real world and actually deploy it?
>>
> When it has passed review, I suppose we could set up a few wikis at
> prototype.wikimedia.org and test it there. It was originally set up
> for the usability initiative but it seems to be used for increasingly
> random testing purposes now, and we have no other proper place for
> this.

Great! :) Note that, for testing purposes, it is possible to keep the
pages of the central wiki in a separate namespace or as subpages.

>> - Reading the links from a foreign database instead of via the API. Is there
>> a "proper" way to do this?
>>
> Yes. You can obtain a connection to a foreign DB with wfGetDb(
> DB_SLAVE, array() 'wikiID' ); . Both the wiki ID and the API URL can
> be obtained from the interwiki table now (that is, there are fields
> for them, we're not actually filling those fields yet), as part of
> Peter's work on the iwtransclusion branch for GSoC. How have you been
> obtaining API URLs anyway?

I'm using $wgInterlanguageExtensionApiUrl variable that has to be set in
LocalSettings.php

>> - Updating links on dependent wikis when deleting, undeleting etc. articles on
>> the central wiki.
>>
> This is something the iwtransclusion branch also has to address. The
> current plan is to do that using a global templatelinks table.

Interlanguage extension was lucky in that the articles that need to be
updated are exactly the ones that the interwikis link to :)

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l