Hi,
These days I had a little time to clear my TODO list after Wikimania and I tried to find some information about the "central interwiki repository" idea. While it was fairly trivial to find info about the proposal itself [0] and the technical details proposed by Nikola Smolenski, it was not so easy as to discern the current status of the proposal.
What I want to know is: 1. Is there support from the community for some extended tests on this subject on the Wikimedia websites? 2. Are there plans to extend the current extensions in order to support something like [1], which would be much more interesting, but also much more challenging? 3. Perhaps there are alternate proposals which target the same problem?
Thanks, Strainu
[0] http://strategy.wikimedia.org/wiki/Proposal:A_central_wiki_for_interlanguage... [1] http://strategy.wikimedia.org/wiki/Proposal:A_central_repository_of_all_lang...
An'n 11.10.2010 16:13, hett Strainu schreven:
These days I had a little time to clear my TODO list after Wikimania and I tried to find some information about the "central interwiki repository" idea. While it was fairly trivial to find info about the proposal itself [0] and the technical details proposed by Nikola Smolenski, it was not so easy as to discern the current status of the proposal.
What I want to know is:
- Is there support from the community for some extended tests on this
subject on the Wikimedia websites? 2. Are there plans to extend the current extensions in order to support something like [1], which would be much more interesting, but also much more challenging? 3. Perhaps there are alternate proposals which target the same problem?
There was a Google Summer of Code project: http://www.mediawiki.org/wiki/User:Peter17/Reasonably_efficient_interwiki_transclusion. It's basically ready to use. About the _actual_ implementation you have to ask the Foundation developers.
Marcus Buck User:Slomox
2010/10/11 Marcus Buck wiki@marcusbuck.org:
There was a Google Summer of Code project: http://www.mediawiki.org/wiki/User:Peter17/Reasonably_efficient_interwiki_transclusion. It's basically ready to use. About the _actual_ implementation you have to ask the Foundation developers.
Marcus, I would hardly call that project "ready to use". It leaves many issues unresolved, such as: 1. local editing of the remote data with unified/non-unified accounts 2. automatic translation importing from translatewiki (people would probably want to use localized parameters/template names) 3. all the known limitations noted there :)
It looks like a good start, but I somewhat doubt we will be seeing it in production soon.
An'n 11.10.2010 20:13, hett Strainu schreven:
2010/10/11 Marcus Buckwiki@marcusbuck.org:
There was a Google Summer of Code project: http://www.mediawiki.org/wiki/User:Peter17/Reasonably_efficient_interwiki_transclusion. It's basically ready to use. About the _actual_ implementation you have to ask the Foundation developers.
Marcus, I would hardly call that project "ready to use". It leaves many issues unresolved, such as:
- local editing of the remote data with unified/non-unified accounts
- automatic translation importing from translatewiki (people would
probably want to use localized parameters/template names) 3. all the known limitations noted there :)
It looks like a good start, but I somewhat doubt we will be seeing it in production soon.
If in Nikola's solution all this works, I wasn't aware of it. #1 to me actually seems like an advantage. If data is changed for all wikis users must go to the central wiki to edit it. Otherwise it'll definitely lead to problems. #2 also is only a problem if we accept that #1 is wanted as a behaviour.
Actually I have no specific preference for any of the two solutions. I just wanted to hint at an alternative effort. The only thing I care about is, that _some_ solution is found and implemented. Both solutions can be implemented in a short period of time if only somebody cared to start the process. It's the most important development step for Wikimedia in years. Possibly ever. See e.g. http://lists.wikimedia.org/pipermail/foundation-l/2010-August/060628.html.
Marcus Buck User:Slomox
2010/10/11 Marcus Buck wiki@marcusbuck.org:
An'n 11.10.2010 20:13, hett Strainu schreven:
2010/10/11 Marcus Buckwiki@marcusbuck.org:
There was a Google Summer of Code project: http://www.mediawiki.org/wiki/User:Peter17/Reasonably_efficient_interwiki_transclusion. It's basically ready to use. About the _actual_ implementation you have to ask the Foundation developers.
Marcus, I would hardly call that project "ready to use". It leaves many issues unresolved, such as:
- local editing of the remote data with unified/non-unified accounts
- automatic translation importing from translatewiki (people would
probably want to use localized parameters/template names) 3. all the known limitations noted there :)
It looks like a good start, but I somewhat doubt we will be seeing it in production soon.
If in Nikola's solution all this works, I wasn't aware of it. #1 to me actually seems like an advantage. If data is changed for all wikis users must go to the central wiki to edit it. Otherwise it'll definitely lead to problems. #2 also is only a problem if we accept that #1 is wanted as a behaviour.
Well, Nikola's solution is limited to interwiki links (I think), so it has very little to do with those issues (only the name of the page in the central wiki, if I remember correctly). Regarding the local/remote editing, experience has shown me that most people hate to leave their home wiki, even if the new wiki is in their native language and has no radically different rules. This is especially true for small wikis. Editing the data on the central wiki will limit the number of editors. This could be a good thing, but I tend to believe it is overall better to have many people editing the data.
#2 is in no way linked with number 1. To use the example you have used on foundation-l, here is how {{town}} should look in English and French for Bucharest:
{{Town |name=Bucharest |country=Romania |pop=2,000,000 |lat=45.0 |lon=26.0 |elevation=12 |mayor=Sorin Oprescu }}
{{Ville |nom=Bucarest |pays=Roumanie |pop=2.000.000 |lat=45.0 |lon=26.0 |hauteur=12 |maire=Sorin Oprescu }}
As you can see, there are differences in both the syntax and the data of the template. The difference in the data can be avoided by keeping only the common parts, like the coordinates and the iw links, centralized. #2 refers specifically to the differences in syntax. If you keep this approach, you're basically keeping people who do not know English at bay from editing the central wiki. And I think this is a much more significant problem for smaller languages, which you want to help.
Actually I have no specific preference for any of the two solutions. I just wanted to hint at an alternative effort.
It was good to know the Foundation invested into that, thanks. :)
The only thing I care about is, that _some_ solution is found and implemented. Both solutions can be implemented in a short period of time if only somebody cared to start the process. It's the most important development step for Wikimedia in years. Possibly ever. See e.g. http://lists.wikimedia.org/pipermail/foundation-l/2010-August/060628.html.
I couldn't agree more on that. I am eager to see more effort into this problem.
Marcus Buck User:Slomox
Strainu
Template names can be solved by having redirects on the central template wiki (which may or may not be the same wiki as the central interwiki wiki).
Parameter names can be solved by interface messages like for example is done on Commons:
** Template:Town ** {| ! {{int:Name}} | {{{ {{int:name-param}} }}} |} or: {| ! {{Town/Country-label/{{int:Lang}}}} | {{{ {{Town/Country-param/{{int:Lang}} }}} |}
** Template:Ville ** #REDIRECT[[Template:Town]]
etc. you get the idea
Regarding the wikis being the same or not. I think it makes sense for them to be the same or atleast the same kind of wiki.
I noticed the current extension for Interlanguage links only extracts languagelinks (which are externally parsed) and puts them in the local article. However taking the interwiki transclusion project from GSoC it may be possible to use that for [[xx:interwikilinks]] aswell. This way things like {{FA|xx}} and {{Commonscat|Foobar}} for indicating Featured articles and interprojects can be transcluded along aswell.
-- Krinkle
Op 11 okt 2010, om 23:50 heeft Strainu het volgende geschreven:
2010/10/11 Marcus Buck wiki@marcusbuck.org:
An'n 11.10.2010 20:13, hett Strainu schreven:
2010/10/11 Marcus Buckwiki@marcusbuck.org:
There was a Google Summer of Code project: <http://www.mediawiki.org/wiki/User:Peter17/Reasonably_efficient_interwiki_tr...
.
It's basically ready to use. About the _actual_ implementation you have to ask the Foundation developers.
Marcus, I would hardly call that project "ready to use". It leaves many issues unresolved, such as:
- local editing of the remote data with unified/non-unified
accounts 2. automatic translation importing from translatewiki (people would probably want to use localized parameters/template names) 3. all the known limitations noted there :)
It looks like a good start, but I somewhat doubt we will be seeing it in production soon.
If in Nikola's solution all this works, I wasn't aware of it. #1 to me actually seems like an advantage. If data is changed for all wikis users must go to the central wiki to edit it. Otherwise it'll definitely lead to problems. #2 also is only a problem if we accept that #1 is wanted as a behaviour.
Well, Nikola's solution is limited to interwiki links (I think), so it has very little to do with those issues (only the name of the page in the central wiki, if I remember correctly). Regarding the local/remote editing, experience has shown me that most people hate to leave their home wiki, even if the new wiki is in their native language and has no radically different rules. This is especially true for small wikis. Editing the data on the central wiki will limit the number of editors. This could be a good thing, but I tend to believe it is overall better to have many people editing the data.
#2 is in no way linked with number 1. To use the example you have used on foundation-l, here is how {{town}} should look in English and French for Bucharest:
{{Town |name=Bucharest |country=Romania |pop=2,000,000 |lat=45.0 |lon=26.0 |elevation=12 |mayor=Sorin Oprescu }}
{{Ville |nom=Bucarest |pays=Roumanie |pop=2.000.000 |lat=45.0 |lon=26.0 |hauteur=12 |maire=Sorin Oprescu }}
As you can see, there are differences in both the syntax and the data of the template. The difference in the data can be avoided by keeping only the common parts, like the coordinates and the iw links, centralized. #2 refers specifically to the differences in syntax. If you keep this approach, you're basically keeping people who do not know English at bay from editing the central wiki. And I think this is a much more significant problem for smaller languages, which you want to help.
Actually I have no specific preference for any of the two solutions. I just wanted to hint at an alternative effort.
It was good to know the Foundation invested into that, thanks. :)
The only thing I care about is, that _some_ solution is found and implemented. Both solutions can be implemented in a short period of time if only somebody cared to start the process. It's the most important development step for Wikimedia in years. Possibly ever. See e.g. <http://lists.wikimedia.org/pipermail/foundation-l/2010-August/060628.html
.
I couldn't agree more on that. I am eager to see more effort into this problem.
Marcus Buck User:Slomox
Strainu
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
"Krinkle" krinklemail@gmail.com wrote in message news:05A42F47-1913-4B21-B9F7-100F4A1EA4D8@gmail.com...
Template names can be solved by having redirects on the central template wiki (which may or may not be the same wiki as the central interwiki wiki).
Parameter names can be solved by interface messages like for example is done on Commons:
** Template:Town ** {| ! {{int:Name}} | {{{ {{int:name-param}} }}} |} or: {| ! {{Town/Country-label/{{int:Lang}}}} | {{{ {{Town/Country-param/{{int:Lang}} }}} |}
** Template:Ville ** #REDIRECT[[Template:Town]]
etc. you get the idea
What do you do when you have a template name which translates to one term in one language, and another term in another language (like "hall" or "vice", to choose the first tenuous examples I can think of)?? The {{int: hack is precisely that, a horrible hack which plays havoc with caching and only just about works enough to continue to be allowed. A proper solution to this area will deal with these issues in a clean and sensible way, rather than continuing to use and abuse existing technology.
--HM
An'n 11.10.2010 23:50, hett Strainu schreven:
Well, Nikola's solution is limited to interwiki links (I think), so it has very little to do with those issues (only the name of the page in the central wiki, if I remember correctly).
Interwiki links were the design intent but technically it is a very small step to include any type of content.
Regarding the local/remote editing, experience has shown me that most people hate to leave their home wiki, even if the new wiki is in their native language and has no radically different rules. This is especially true for small wikis. Editing the data on the central wiki will limit the number of editors. This could be a good thing, but I tend to believe it is overall better to have many people editing the data.
If you use Commons you have to leave your home wiki too. How would you manage disputes about edits when these edits don't happen on-wiki? And Commons too is English-centered. Many people are working on improving the multilinguality of Commons and circumventing the limitations of MediaWiki (which really sucks at true multilingual support) and are quite successful. The localisation degree of Commons varies heavily between languages, but in languages with active localizers Commons is easily usable for non-speakers of English. Discussions can also be done in languages other than English, just general discussions are mostly English-only. But that's an inherent issue of any shared content and unfixable. The only alternative to that is to not share content (this alternative by the way is in no way limited by the existence of a shared depository. If you don't want to use the shared content you can always store it locally).
#2 is in no way linked with number 1. To use the example you have used on foundation-l, here is how {{town}} should look in English and French for Bucharest:
{{Town |name=Bucharest |country=Romania |pop=2,000,000 |lat=45.0 |lon=26.0 |elevation=12 |mayor=Sorin Oprescu }}
{{Ville |nom=Bucarest |pays=Roumanie |pop=2.000.000 |lat=45.0 |lon=26.0 |hauteur=12 |maire=Sorin Oprescu }}
There's a misunderstanding. The town template wouldn't be stored on en.wp or fr.wp. It would be stored on the central data repository. Therefore the population must be stored in plain numbers ("2000000"). Any formatting will be done on the local wikis only (via "formatnum"). The country will be stored as "RO", the ISO 3166 code and this code will be translated back to "Romania" or "Roumanie" on the local wiki. The city's name too needs to be stored in a format that makes the local name in each language accessible.
Marcus Buck User:Slomox
2010/10/11 Strainu strainu10@gmail.com:
Hi,
These days I had a little time to clear my TODO list after Wikimania and I tried to find some information about the "central interwiki repository" idea.
What I want to know is:
- Is there support from the community for some extended tests on this
subject on the Wikimedia websites?
I opened the bug in which i ask to enable Nikola's extension on Wikipedia two years ago. For what it's worth, most of the comments there approve of the idea and there's no strong opposition: https://bugzilla.wikimedia.org/show_bug.cgi?id=15607
See also http://meta.wikimedia.org/wiki/Talk:A_newer_look_at_the_interlanguage_link
- Are there plans to extend the current extensions in order to
support something like [1], which would be much more interesting, but also much more challenging?
It is possible to develop something more interesting and challenging, but it seems that Nikola's solution will work *now* to solve some of the problems of interwiki maintenance that have annoyed many people for more than five years.
In any case, when something more interesting is developed, it will be easier to migrate there from Nikola's solution than from the current state of affairs.
wikitech-l@lists.wikimedia.org