[Wikidata-l] Clearly define {{#property: }} parser function

2013-11-08 Thread Liangent
Hello,

I submitted bug 56763[1] just now, then realized that this is a part of a
larger issue: what is {{#property: }} expected to output.

Theoretically, there could be two extreme answers: raw data as a string, or
whatever wikitext which could be rendered as what *readers* love best.

I guess the second answer is the goal, because of ValueFormatter,
SnakFormatter::FORMAT_WIKI and $wgContLang->listToText() on final output in
our code, but sadly this is never explicitly defined anywhere, including
MW.org documentations[2] and development notes[3].

With this goal, I imagine the output for each datatype should be:

* Item: WikiLink to the linked article, or maybe the WikibaseRepo item page
when there's not such an article, with label as link text
* Commons media: ImageLink to the specified media file (size and other
params TBD)
* String: Wikitext-escaped form of the string data
* Time / Globe coordinate: See bug 48937[4] and bug 49387[5]
* URL: ExternalLink to the specified URL, see bug 56763[1]

However due to lack of the specification and the current behaviors of
{{#property: }} which is a mix of raw data and fully-constructed wikitext,
template writers have already invented various usages:

* [[{{#property:item-property}}]]
* [[File:{{#property:commons-media-property}}|thumb]]
* [{{#property:url-property}}
{{url-protocol-stripper|{{#property:url-property]
* {{#ifeq:{{#property:commons-media-property}}|A.png|B|C}}

and obviously work towards the goal described above breaks them (of course
what they want is still doable with Lua), and less obviously, they're
already broken sometimes when multiple statements exist, which are imploded
using $wgContLang->listToText().

Is there any plan here, and what's the real goal of {{#property: }} ?

[1] https://bugzilla.wikimedia.org/show_bug.cgi?id=56763
[2] https://www.mediawiki.org/wiki/Wikibase_Client#Data_transclusion
[3]
https://meta.wikimedia.org/wiki/Wikidata/Notes/Inclusion_syntax#Accessing_Item_Data
[4] https://bugzilla.wikimedia.org/show_bug.cgi?id=48937
[5] https://bugzilla.wikimedia.org/show_bug.cgi?id=49387

-Liangent
___
Wikidata-l mailing list
Wikidata-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-l


Re: [Wikidata-l] Clearly define {{#property: }} parser function

2013-11-08 Thread Gerard Meijssen
Hoi
Remember that the stings need to be identifief for their language and by
implication script. They can be a mix and match from multiple languages..
Thanks,
  GerardM
 Op 8 nov. 2013 09:13 schreef "Liangent" :

> Hello,
>
> I submitted bug 56763[1] just now, then realized that this is a part of a
> larger issue: what is {{#property: }} expected to output.
>
> Theoretically, there could be two extreme answers: raw data as a string,
> or whatever wikitext which could be rendered as what *readers* love best.
>
> I guess the second answer is the goal, because of ValueFormatter,
> SnakFormatter::FORMAT_WIKI and $wgContLang->listToText() on final output in
> our code, but sadly this is never explicitly defined anywhere, including
> MW.org documentations[2] and development notes[3].
>
> With this goal, I imagine the output for each datatype should be:
>
> * Item: WikiLink to the linked article, or maybe the WikibaseRepo item
> page when there's not such an article, with label as link text
> * Commons media: ImageLink to the specified media file (size and other
> params TBD)
> * String: Wikitext-escaped form of the string data
> * Time / Globe coordinate: See bug 48937[4] and bug 49387[5]
> * URL: ExternalLink to the specified URL, see bug 56763[1]
>
> However due to lack of the specification and the current behaviors of
> {{#property: }} which is a mix of raw data and fully-constructed wikitext,
> template writers have already invented various usages:
>
> * [[{{#property:item-property}}]]
> * [[File:{{#property:commons-media-property}}|thumb]]
> * [{{#property:url-property}}
> {{url-protocol-stripper|{{#property:url-property]
> * {{#ifeq:{{#property:commons-media-property}}|A.png|B|C}}
>
> and obviously work towards the goal described above breaks them (of course
> what they want is still doable with Lua), and less obviously, they're
> already broken sometimes when multiple statements exist, which are imploded
> using $wgContLang->listToText().
>
> Is there any plan here, and what's the real goal of {{#property: }} ?
>
> [1] https://bugzilla.wikimedia.org/show_bug.cgi?id=56763
> [2] https://www.mediawiki.org/wiki/Wikibase_Client#Data_transclusion
> [3]
> https://meta.wikimedia.org/wiki/Wikidata/Notes/Inclusion_syntax#Accessing_Item_Data
> [4] https://bugzilla.wikimedia.org/show_bug.cgi?id=48937
> [5] https://bugzilla.wikimedia.org/show_bug.cgi?id=49387
>
> -Liangent
>
> ___
> Wikidata-l mailing list
> Wikidata-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikidata-l
>
>
___
Wikidata-l mailing list
Wikidata-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-l


[Wikidata-l] We need your input: Enhancements for Lua/Wikidata wanted!

2013-11-08 Thread Jens Ohlig
Hello,

we’d like to work on Lua bindings for Wikidata. I have set up a page to gather 
ideas and suggestions for what people want to see: 
https://www.wikidata.org/wiki/Wikidata:Lua_enhancements

Your contributions would make me very, very happy. 

Cheers,
Jens

-- 
Jens Ohlig
Software developer

Wikimedia Deutschland e.V. 
Obentrautstraße 72
10963 Berlin

Telefon 030 - 219 158 26-0
www.wikimedia.de

Stellen Sie sich eine Welt vor, in der jeder Mensch an der Menge allen Wissens 
frei teilhaben kann. Helfen Sie uns dabei!
http://spenden.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.



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
Wikidata-l mailing list
Wikidata-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-l


Re: [Wikidata-l] next sister project: Wikisource

2013-11-08 Thread Joe Filceolaire
Actually the problem isn't that you can only have one link from a
wikisource work from a wikidata item. We have separate wikidata items
for each edition of a work (because these have different metadata) so
multiple editions of the same work on a wikisource link to different
wikidata items.

This creates a different problem. Each language edition of a work is a
different edition so it links to a different wikidata item which has
sitelinks only to that translation of the work. This means you can't
use sitelinks to link to translations of a work on other wikisources.


Does this mean wikidata sitelinks are useless for wikisource?


filceolaire
___
Wikidata-l mailing list
Wikidata-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-l


Re: [Wikidata-l] next sister project: Wikisource

2013-11-08 Thread Sven Manguard
You bring up a good point. Is there anyway to have the interwiki links that
show up on the sidebar point to a page with a different q# ID then the
should? If we can do that we can have every version of a given book all
point to a disambiguation page that lists all of the versions. I can't
think of any other solution.

Sven
On Nov 8, 2013 12:49 PM, "Joe Filceolaire"  wrote:

> Actually the problem isn't that you can only have one link from a wikisource 
> work from a wikidata item. We have separate wikidata items for each edition 
> of a work (because these have different metadata) so multiple editions of the 
> same work on a wikisource link to different wikidata items.
>
> This creates a different problem. Each language edition of a work is a 
> different edition so it links to a different wikidata item which has 
> sitelinks only to that translation of the work. This means you can't use 
> sitelinks to link to translations of a work on other wikisources.
>
>
> Does this mean wikidata sitelinks are useless for wikisource?
>
>
> filceolaire
>
>
> ___
> Wikidata-l mailing list
> Wikidata-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikidata-l
>
>
___
Wikidata-l mailing list
Wikidata-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-l


Re: [Wikidata-l] next sister project: Wikisource

2013-11-08 Thread David Cuenca
The sitelinks are not used directly, they are aggregated by using the work
item as a central hub. Basically the algorithm is:
1.- query all edition-items that are connected to the same work-item using
"edition of"
2.- make a list of all the sitelinks used on each one of these
edition-items (1 sitelink per edition-item)
3.- for each wikisource page connected to an edition-item, display the list
generated on point 2

Micru


On Fri, Nov 8, 2013 at 6:49 PM, Joe Filceolaire wrote:

> Actually the problem isn't that you can only have one link from a wikisource 
> work from a wikidata item. We have separate wikidata items for each edition 
> of a work (because these have different metadata) so multiple editions of the 
> same work on a wikisource link to different wikidata items.
>
> This creates a different problem. Each language edition of a work is a 
> different edition so it links to a different wikidata item which has 
> sitelinks only to that translation of the work. This means you can't use 
> sitelinks to link to translations of a work on other wikisources.
>
>
> Does this mean wikidata sitelinks are useless for wikisource?
>
>
> filceolaire
>
>
> ___
> Wikidata-l mailing list
> Wikidata-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikidata-l
>
>


-- 
Etiamsi omnes, ego non
___
Wikidata-l mailing list
Wikidata-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-l