Дана Saturday 14 March 2009 23:20:01 Amir E. Aharoni написа: wrote: Seconded. Brion's comments are: I don't fully understand them.

If you don't know what this is about, refer to: - http://www.mail-archive.com/wikitech-l@lists.wikimedia.org/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_interlanguag… Дана Tuesday 17 March 2009 07:01:39 Nikola Smolenski написа: 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.

2010/8/6 Nikola Smolenski <smolensk(a)eunet.rs>rs>: 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. 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? This is something the iwtransclusion branch also has to address. The current plan is to do that using a global templatelinks table. 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)