Re: [Wikitech-l] Wikidata status

2012-09-10 Thread Daniel Kinzler
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@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l


Re: [Wikitech-l] Wikidata status

2012-09-07 Thread Daniel Kinzler
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@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l


Re: [Wikitech-l] Wikidata status

2012-09-07 Thread Denny Vrandečić
Just an idea, but wouldn't Lua source code make a perfect alternative
content type?



2012/9/7 Daniel Kinzler dan...@brightbyte.de:
 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@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Wikidata status

2012-09-07 Thread Daniel Kinzler
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@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Wikidata status

2012-09-07 Thread Daniel Friesen

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.vrande...@wikimedia.de wrote:



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



2012/9/7 Daniel Kinzler dan...@brightbyte.de:

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@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Wikidata status

2012-09-02 Thread Tim Starling
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@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l


[Wikitech-l] Wikidata status

2012-08-31 Thread Daniel Kinzler
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@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l


[Wikitech-l] Wikidata status

2012-08-24 Thread Daniel Kinzler
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@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l