Hi everyone,
2012/8/11 Rob Lanphier robla@wikimedia.org:
To recap, Jeroen submitted changeset 14295 in Gerrit https://gerrit.wikimedia.org/r/#/c/14295/ with the following summary:
This commit introduces a new table to hold site data and configuration, objects to represent the table, site objects and lists of sites and associated tests.
The sites code is a more generalized and less contrived version of the interwiki code we currently have and is meant to replace it eventually. This commit does not do away with the existing interwiki code in any way yet.
The reasons for this change where outlined and discussed on wikitech here: http://lists.wikimedia.org/pipermail/wikitech-l/2012-June/060992.html
Thanks Brian for summarizing an important point:
On Fri, Aug 10, 2012 at 6:33 AM, bawolff bawolff+wn@gmail.com wrote:
First and foremost, I'm a little confused as to what the actual use cases here are. Could we get a short summary for those who aren't entirely following how wikidata will work, why the current interwiki situation is insufficient?
The use case is the following: in order for Wikidata to be able to provide language links for the wikis using Wikidata, we need to use consistent global IDs when communicating about the involved wikis (i.e. if a "client wiki", i.e. a Wikipedia like fr.wp, asks Wikidata for the language links for an article X, the client and the repo need to know that e.g. "enwiki" refers to en.wp. Right now the table does not sport any such field -- the local prefix "en" might be differently defined on fr.wp and fr.wikinews, for example, and we obviously do not want to break that).
We further made some configurations explicit that are as of now embedded in the code using the current interwiki table.
The change also facilitates synchronizing that data, but this is part of another changeset and of other code.
I am a bit confused here. As far as I can see everyone agrees that this changeset goes in the right direction. I also did not see contentions about how the changeset is working that have not been resolved yet. The reservations that are raised are that the changeset does not go *far enough*. Considering that we want to keep changesets small, and that this changeset keeps the old system in place and thus should not break anything, wouldn't that be a good first step?
If this is the case, why do we not move by taking this step and continue to discuss about how to iterate further from there to an even better and more comprehensive solution?
Cheers, Denny