On 23/05/12 13:53, Daniel Kinzler wrote:
On 23.05.2012 13:14, Nikola Smolenski wrote:{{#data:color|item=Blah}} - this uses item linked to "Blah" in the local language. {{#data:color|item=en:Blah}} - this uses item linked to "Blah" in English language. {{#data:color|id=q123}} - this uses item with ID q123. {{#data:Blah->color}} - we can do this since -> can't appear in a page name - this is my favorite of course :)3) no explicit reference/use of the item at all. Just use parser function to access properties, and specify the item if need be (otherwise, the page's "own" item is used).
That is what I am suggesting, yes.
The parser function should be able to override itself by template parameters - I believe it is possible to do this.That makes the hair in my neck stand up :)From the user point of view or the implementation point of view? :)Both. And as Gabriel pointed out, something like this would be really bad for things like the visual editor, snippet caching, etc.
How is it different from overwriting value of a data item in the initial suggestion?
If there will be no pre-loading, disregard this.Don't know what you mean by "pre"... the item will be loaded into memory once, whenever the page is rendered. It would typically be loaded from a local cache (e.g. in the database), an http request to the repo while rendering would be annoyingly slow.
This is what I mean. An alternative would be to load every assertion from the DB at the time it is requested.
There is also a hybrid possibility: load what we expect to be used (this would probably be entire item in the default language), then load every remaining assertion when it is requested.
A quick calculation: infobox at http://en.wikipedia.org/wiki/Berlin has some 2K of parameters, and the article exists in 200 languages, so that would amount to 400K of data. Of course, not all data will be translatable or translated, but still 100K does not seem unreasonable.
Except that it's not wrapped in any HTML. Perhaps there should be an option to {{#data-value}} to turn that off completely, using form=plain or some such.Now shorten #data-value to #data, use form=plain as the default and that's it :)Yes, we can drop the "simple" parameter-like syntax an use parser functions for everything. The remaining question is... how do i specify the item i want to get the property from (if it's not the default)? Will be be assigning local names to
Well, this is what we we talked about above, at the start of this e-mail, right?
items, using #load-data or some such? Or will we just use the item id directly -
which would probably be a parameter, so we'd end up with something like this:
{{#property:population|item={{{item-id|*}}}}}
...with * representing the default (the page's "own") item. Not very pretty,
The default would be used if item is not specified. I'm not sure I understand why are you introducing this.
I would try not to introduce new syntax if it is not necessary. How about this: [[wikidata:Berlin]] - links to en.wikidata.org/wiki/Berlin [[wikidataid:q1234]] - links to en.wikidata.org/id/q1234 {{canonicalurl:wikidata:Berlin|action=edit}} - links to edit page All of this syntax already exists, is widely used and could be introduced without additional coding :)You'd have to do [[wikidata:id/{{#property:id}}|the data item]].
Again, I don't see why.
But this doesn't work for edit links. Especially not if the edit link is supposed to invoke the on-site ajax editing interface.... How to you generate a link/button for doing that?
Yes, for that you have to have a new parser function, similar to canonicalurl above.
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ Wikidata-l mailing list Wikidata-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-l
