Hey,
You mean site_config?
You're suggesting the interwiki system should look for a site by
site_local_key, when it finds one parse out the site_config, check if it's
disabled and if so ignore the fact it found a site with that local key?
Instead of just not having a site_local_key for that
Hi Daniel,
thanks for your comments. Some of the suggestions you make would
extend the functionality beyond what we need right now. They look
certainly useful, and I don't think that we would make implementing
them any harder than it is right now -- rather the opposite.
As usual, the perfect and
Hey,
You mean site_config?
You're suggesting the interwiki system should look for a site by
site_local_key, when it finds one parse out the site_config, check if it's
disabled and if so ignore the fact it found a site with that local key?
Instead of just not having a site_local_key for
Hey,
Having interwikis that support
url re-writing based on the value does sound cool, but I certainly
wouldn't want said code in a db blob
We do not have code in blobs in the db, that seems like a rather mad thing
to do! :)
The blobs we have are for holding data or config specific to some
On Fri, 10 Aug 2012 05:03:58 -0700, Denny Vrandečić
denny.vrande...@wikimedia.de wrote:
Hi Daniel,
thanks for your comments. Some of the suggestions you make would
extend the functionality beyond what we need right now. They look
certainly useful, and I don't think that we would make
Hey,
But I do expect that if we have a good idea what the optimal database
schema and usage of the feature is that you'd make a tiny effort to include
the fixes that Wikidata doesn't explicitly need.
This is entirely reasonable to ask. However this particular change is not
tiny, and it would
On Fri, Aug 10, 2012 at 9:02 AM, Daniel Friesen
li...@nadir-seen-fire.com wrote:
I don't think you're going far enough.
You're rewriting a core feature in core but key issues with the old system
that should be fixed in any rewrite of it are explicitly being repeated just
because you don't need
Hi all,
here is our update on last weeks blocker email. The list got
considerably shorter, but we have some long standing issues still
there. No new blockers came up.
== Ongoing ==
* Merging the Wikidata branch (ContentHandler) is still open, see
Hi Denny,
Thanks for the update. Comments inline:
On Thu, Aug 9, 2012 at 6:54 AM, Denny Vrandečić
denny.vrande...@wikimedia.de wrote:
* Merging the Wikidata branch (ContentHandler) is still open, see
https://bugzilla.wikimedia.org/show_bug.cgi?id=38622. There has been
no feedback in the last
Hey,
... is unclear why you're letting it block your work.
The current interwiki related code in core has many assumptions baked in
that prevent us from doing what we need to do in phase 1. For instance
language links can only be made to sites with an id that is a language
code. Since we're
On Thu, 09 Aug 2012 06:54:03 -0700, Denny Vrandečić
denny.vrande...@wikimedia.de wrote:
Hi all,
[...]
* Changeset https://gerrit.wikimedia.org/r/#/c/14295/, bug
https://bugzilla.wikimedia.org/show_bug.cgi?id=38705 about handling
sites. The idea is to migrate from the interwiki table to the
Hi Rob,
thanks for the answers.
2012/8/9 Rob Lanphier ro...@wikimedia.org:
It looks like this page needs an update as well:
http://www.mediawiki.org/wiki/Wikidata_deployment
Thanks, I updated the page.
One thing that was tacked on the wiki page without mention here or a
bug created was the
On 09.08.2012 16:49, Rob Lanphier wrote:
On Thu, Aug 9, 2012 at 6:54 AM, Denny Vrandečić
denny.vrande...@wikimedia.de wrote:
* Merging the Wikidata branch (ContentHandler) is still open, see
https://bugzilla.wikimedia.org/show_bug.cgi?id=38622. There has been
no feedback in the last few
Hey,
So if this is something hoping to replace the interwiki system I'd like
to look over what the plan and overall idea is with this to make sure we
don't repeat the same mistakes.
Please have a look at the patch on gerrit then. Feedback is much
appreciated :)
On Thu, 09 Aug 2012 09:12:16 -0700, Jeroen De Dauw
jeroended...@gmail.com wrote:
Hey,
So if this is something hoping to replace the interwiki system I'd like
to look over what the plan and overall idea is with this to make sure we
don't repeat the same mistakes.
Please have a look at the
Hey,
Daniel, thanks for your input.
TL;DR at the bottom :)
The issue I was trying to deal with was storage. Currently we 100% assume
that the interwiki list is a table and there will only ever be one of them.
Yes, we are not changing this. Having a more flexible system might or might
not be
Denny,
We are currently investigating using the Universal Language Selector
instead of Stick to that language, and on first glance it looks
good. If this remains like this, we will drop Stick to that
language. That is why I didn't list the corresponding open issues
there. We'd be happy to go
~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name]
On 12-08-09 12:00 PM, Jeroen De Dauw wrote:
Hey,
Daniel, thanks for your input.
TL;DR at the bottom :)
The issue I was trying to deal with was storage. Currently we 100%
assume that the interwiki list is a table and
Hey,
You bring up some good points.
I think we're going to need to have some of this and the synchronization
stuff in core.
Right now the code has nothing but the one sites table. No repo code so
presumably the only implementation of that for awhile will be wikidata. And
if parts of this
On 12-08-09 3:55 PM, Jeroen De Dauw wrote:
Hey,
You bring up some good points.
I think we're going to need to have some of this and the
synchronization stuff in core.
Right now the code has nothing but the one sites table. No repo
code so presumably the only implementation
20 matches
Mail list logo
