Re: [Wikitech-l] Central interwiki and similar proposals
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 (200).
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
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Central interwiki and similar proposals
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: 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? 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 ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Central interwiki and similar proposals
2010/10/11 Marcus Buck w...@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. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Central interwiki and similar proposals
An'n 11.10.2010 20:13, hett Strainu schreven: 2010/10/11 Marcus Buckw...@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. 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 ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Central interwiki and similar proposals
2010/10/11 Marcus Buck w...@marcusbuck.org:
An'n 11.10.2010 20:13, hett Strainu schreven:
2010/10/11 Marcus Buckw...@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.
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
Re: [Wikitech-l] Central interwiki and similar proposals
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 w...@marcusbuck.org:
An'n 11.10.2010 20:13, hett Strainu schreven:
2010/10/11 Marcus Buckw...@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.
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
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
