Mailing List Archive: Wikipedia: Wikitech

Wikidata status

Index | Next | Previous | View Threaded

daniel at brightbyte

Aug 24, 2012, 9:56 AM

Post #1 of 8 (238 views)
Permalink

Wikidata status

Hi all

Here's a quick update on what has been happening with Wikidata.

After I was off duty last week, I have picked up work on the Wikidata branch
again (aka the ContentHandler stuff). Discussion is happening mostly on Bugzilla:

https://bugzilla.wikimedia.org/show_bug.cgi?id=38622

I have tried to address several of Tim's concerns, and will hopefully wrap up
the lose ends early next week. Here's the Gerrit log:

https://gerrit.wikimedia.org/r/#/q/project:mediawiki/core+branch:Wikidata,n,z

While I'm still working on this, I'm very much welcoming any comments, reviews,
criticism, whatever. Please look at the code and let me know what you think!

Other than that, there's the ungoing discussion about a new system for managing
interwiki/linterlanguage link targets. The RFC is here:

https://www.mediawiki.org/wiki/Requests_for_comment/New_sites_system

Here, too, we are working on it, but more comments are still encouraged.

Thanks
Daniel

_______________________________________________
Wikitech-l mailing list
Wikitech-l [at] lists
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

daniel at brightbyte

Aug 31, 2012, 1:08 PM

Post #2 of 8 (215 views)
Permalink

Wikidata status [In reply to]

Hello

We have had a pretty productive week with the Wikidata team. The most pressing
issues concerning the Foundation team are however still the same:

The Sites table is pending finalization. It coming along nicely, and I think we
will have a new version early next week. Development is happening on a separate
development branch called "sites", any feedback is appreciated.

The Wikidata branch with the ContentHandler and related changes has seen some
improvements over the week, and I have once more merged the latest master into
the branch. However, I'm wondering how to best proceed now.

Until a few weeks ago, I let development on that branch rest, awaiting feedback
so I could be sure to be moving into the right direction. This didn't work out,
since the code was still too incomplete for a full review. I have now tied down
most loose ends, but I'm still getting no feedback. Would it be best to halt
development again? It's never going to be *finished*, there's always *something*
to improve...

Cheers
Daniel

_______________________________________________
Wikitech-l mailing list
Wikitech-l [at] lists
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

tstarling at wikimedia

Sep 2, 2012, 6:30 PM

Post #3 of 8 (214 views)
Permalink

Re: Wikidata status [In reply to]

On 01/09/12 06:08, Daniel Kinzler wrote:
> Until a few weeks ago, I let development on that branch rest, awaiting feedback
> so I could be sure to be moving into the right direction. This didn't work out,
> since the code was still too incomplete for a full review. I have now tied down
> most loose ends, but I'm still getting no feedback. Would it be best to halt
> development again? It's never going to be *finished*, there's always *something*
> to improve...

I've been busy, but I can do another review of the ContentHandler
branch this week. I'm not expecting to find major architectural issues
with it. Architecturally, it's pretty simple: replace text with
Content objects, and have a ContentHandler hierarchy representing
their types. That basic scheme is not disputed.

There's the question of what level of quality we should aim for. We'll
probably find things that will break when a non-text content type is
used. I'd like to see such issues solved, or at least make sure the
ContentHandler API will support a solution without major changes, but
my reasons are mostly aesthetic. In principle, such development work
can be done after the merge. But it seems to me that there's no point
in merging it if it only supports text content, since MediaWiki
already supports pure text content well enough. If we can achieve
robust support for non-text data types, then the motivation for
merging it will be stronger.

-- Tim Starling

_______________________________________________
Wikitech-l mailing list
Wikitech-l [at] lists
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

daniel at brightbyte

Sep 7, 2012, 3:20 AM

Post #4 of 8 (205 views)
Permalink

Re: Wikidata status [In reply to]

Hi Tim!

For some reason, your mail went under my radar until now. Sorry about that.

On 03.09.2012 03:30, Tim Starling wrote:
> I've been busy, but I can do another review of the ContentHandler
> branch this week.

That would be great, thanks!

> There's the question of what level of quality we should aim for. We'll
> probably find things that will break when a non-text content type is
> used. I'd like to see such issues solved, or at least make sure the
> ContentHandler API will support a solution without major changes, but
> my reasons are mostly aesthetic. In principle, such development work
> can be done after the merge. But it seems to me that there's no point
> in merging it if it only supports text content, since MediaWiki
> already supports pure text content well enough. If we can achieve
> robust support for non-text data types, then the motivation for
> merging it will be stronger.

I agree. We are using the mechanism extensively for Wikidata, which of course
uses non-text content. That should serve as a pretty good test. I'm trying to
fix any issues I find on the road, but of course we are not exploring every
possible corner of MediaWiki.

I think we should make sure that the main functionality of MediaWiki works with
the ContentHandler without a hitch, and try to have sane failure modes for stuff
that is not yet (dis)covered. There's no way to be 100% sure, of course.

This week, I have only done a little maintenance on the Wikidata branch (like
merging master again). I'll be looking for loose ends some more over the next
couple of days, but any changes should be confined to small corners of
mediawiki. I'm using gerrit for all changes now, so you should be able track
what i'm doing (well, last week I had to resort to a direct push when gerrit got
very confused about a merge).

Thanks again
Daniel

_______________________________________________
Wikitech-l mailing list
Wikitech-l [at] lists
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

denny.vrandecic at wikimedia

Sep 7, 2012, 3:22 AM

Post #5 of 8 (202 views)
Permalink

Re: Wikidata status [In reply to]

Just an idea, but wouldn't Lua source code make a perfect alternative
content type?

2012/9/7 Daniel Kinzler <daniel [at] brightbyte>:
> Hi Tim!
>
> For some reason, your mail went under my radar until now. Sorry about that.
>
> On 03.09.2012 03:30, Tim Starling wrote:
>> I've been busy, but I can do another review of the ContentHandler
>> branch this week.
>
> That would be great, thanks!
>
>> There's the question of what level of quality we should aim for. We'll
>> probably find things that will break when a non-text content type is
>> used. I'd like to see such issues solved, or at least make sure the
>> ContentHandler API will support a solution without major changes, but
>> my reasons are mostly aesthetic. In principle, such development work
>> can be done after the merge. But it seems to me that there's no point
>> in merging it if it only supports text content, since MediaWiki
>> already supports pure text content well enough. If we can achieve
>> robust support for non-text data types, then the motivation for
>> merging it will be stronger.
>
> I agree. We are using the mechanism extensively for Wikidata, which of course
> uses non-text content. That should serve as a pretty good test. I'm trying to
> fix any issues I find on the road, but of course we are not exploring every
> possible corner of MediaWiki.
>
> I think we should make sure that the main functionality of MediaWiki works with
> the ContentHandler without a hitch, and try to have sane failure modes for stuff
> that is not yet (dis)covered. There's no way to be 100% sure, of course.
>
> This week, I have only done a little maintenance on the Wikidata branch (like
> merging master again). I'll be looking for loose ends some more over the next
> couple of days, but any changes should be confined to small corners of
> mediawiki. I'm using gerrit for all changes now, so you should be able track
> what i'm doing (well, last week I had to resort to a direct push when gerrit got
> very confused about a merge).
>
> Thanks again
> Daniel
>

--
Project director Wikidata
Wikimedia Deutschland e.V. | Obentrautstr. 72 | 10963 Berlin
Tel. +49-30-219 158 26-0 | http://wikimedia.de

Wikimedia Deutschland - Gesellschaft zur Förderung Freien Wissens e.V.
Eingetragen im Vereinsregister des Amtsgerichts Berlin-Charlottenburg
unter der Nummer 23855 B. Als gemeinnützig anerkannt durch das
Finanzamt für Körperschaften I Berlin, Steuernummer 27/681/51985.

_______________________________________________
Wikitech-l mailing list
Wikitech-l [at] lists
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

daniel at nadir-seen-fire

Sep 7, 2012, 3:29 AM

Post #6 of 8 (202 views)
Permalink

Re: Wikidata status [In reply to]

Not really much different from the CSS/JS cases we already have.

The trickier stuff will be non-text stuff. Or especially the 'multipart'
stuff as the [[ContentHandler]] page calls them.

It would be nice to have a test case where WikiText is part of a multipart
type that also store things like a high-level list of categories (even
though it will be an empty list). Just to make sure that basic
functionality is not depending too heavily on pages being non-multipart.

--
~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name]

On Fri, 07 Sep 2012 03:22:50 -0700, Denny Vrandečić
<denny.vrandecic [at] wikimedia> wrote:

> Just an idea, but wouldn't Lua source code make a perfect alternative
> content type?
>
>
>
> 2012/9/7 Daniel Kinzler <daniel [at] brightbyte>:
>> Hi Tim!
>>
>> For some reason, your mail went under my radar until now. Sorry about
>> that.
>>
>> On 03.09.2012 03:30, Tim Starling wrote:
>>> I've been busy, but I can do another review of the ContentHandler
>>> branch this week.
>>
>> That would be great, thanks!
>>
>>> There's the question of what level of quality we should aim for. We'll
>>> probably find things that will break when a non-text content type is
>>> used. I'd like to see such issues solved, or at least make sure the
>>> ContentHandler API will support a solution without major changes, but
>>> my reasons are mostly aesthetic. In principle, such development work
>>> can be done after the merge. But it seems to me that there's no point
>>> in merging it if it only supports text content, since MediaWiki
>>> already supports pure text content well enough. If we can achieve
>>> robust support for non-text data types, then the motivation for
>>> merging it will be stronger.
>>
>> I agree. We are using the mechanism extensively for Wikidata, which of
>> course
>> uses non-text content. That should serve as a pretty good test. I'm
>> trying to
>> fix any issues I find on the road, but of course we are not exploring
>> every
>> possible corner of MediaWiki.
>>
>> I think we should make sure that the main functionality of MediaWiki
>> works with
>> the ContentHandler without a hitch, and try to have sane failure modes
>> for stuff
>> that is not yet (dis)covered. There's no way to be 100% sure, of course.
>>
>> This week, I have only done a little maintenance on the Wikidata branch
>> (like
>> merging master again). I'll be looking for loose ends some more over
>> the next
>> couple of days, but any changes should be confined to small corners of
>> mediawiki. I'm using gerrit for all changes now, so you should be able
>> track
>> what i'm doing (well, last week I had to resort to a direct push when
>> gerrit got
>> very confused about a merge).
>>
>> Thanks again
>> Daniel

_______________________________________________
Wikitech-l mailing list
Wikitech-l [at] lists
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

daniel at brightbyte

Sep 7, 2012, 3:29 AM

Post #7 of 8 (201 views)
Permalink

Re: Wikidata status [In reply to]

On 07.09.2012 12:22, Denny Vrandečić wrote:> Just an idea, but wouldn't Lua
source code make a perfect alternative
> content type?

Yes, it would, but it's also a textual content type. These are rather
unproblematic. One thing that is not yet implemented is a highlighter interface
for different kinds of code as content model.

Non-text content that mediawiki already uses:
* gadget definitions
* sidebar definition
* license list for uploads
* book sources
* list of templates that indicate a disambiguation
* etc...

Would be nice to convert some of them to actual non-text content models, just
for testing. I don't want to commit to that at the moment though, I doubt I'll
find the time.

-- daniel

_______________________________________________
Wikitech-l mailing list
Wikitech-l [at] lists
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

daniel at brightbyte

Sep 10, 2012, 1:38 AM

Post #8 of 8 (193 views)
Permalink

Re: Wikidata status [In reply to]

On 07.09.2012 12:29, Daniel Friesen wrote:
> Not really much different from the CSS/JS cases we already have.

Except that the current handling of CSS/JS is an inconsistent mess of special
cases in various places of the codebase :)

> The trickier stuff will be non-text stuff. Or especially the 'multipart' stuff
> as the [[ContentHandler]] page calls them.

We havn't implemented multipart content, and don't plan to. Multipart stuff is
an interesting use case, but not on the Wikidata road map.

> It would be nice to have a test case where WikiText is part of a multipart type
> that also store things like a high-level list of categories (even though it will
> be an empty list). Just to make sure that basic functionality is not depending
> too heavily on pages being non-multipart.

Well, the use case we currently test with Wikibase is all pages in the data
namespace being non-text. That should cover this, no?

-- daniel

_______________________________________________
Wikitech-l mailing list
Wikitech-l [at] lists
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Index | Next | Previous | View Threaded

Interested in having your list archived? Contact Gossamer Threads