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.