Hi,
The line:
| status = EN
is copied out of the source of the English article "tiger" with the
other lines of wikicode as well. That's the reason why the identifiers
are left latin.
All what I wanted to show is, that it is still possible to use the
actual infoboxes and fill them with data
Hoi,
I do not understand why it should be necessary to specify that a specific
language is to be used. When a template is used on the English Wikipedia,
the choice for English is a function of the Wiki and its text being in
English. Another reason why it is not necessary to specify the language is
Hi,
are we really speaking about the same?
- Pure data serving should be possible there is no disagree here as I
think.
- Should infoboxes be provided?
I was not speaking about the possibility for Wikipedia then. At least I
did not meant it. I more likely wanted to point out that we should
Hoi,
I absolutely agree that Wikidata should be able to serve data in an
unformatted way. I absolutely disagree that there is no need for serving
data formatted in info boxes. Consider this use case:
Someone translated the texts associated with all the popes in Xhosa. There
are no articles on pope
Hallo,
On 2012-06-14 12:33, Gerard Meijssen wrote:
Hoi,
Technically there is nothing stopping Wikidata from hosting multiple
infoboxes on the same subject. The big thing about such infoboxes is
that their layout is the same for all subjects in the same category.
This does not mean that every one
OK -- i view wiki page transclusion same as xml text entity
inclusion is all it is to me.
On 15.06.2012 00:12, Nikola Smolenski
wrote:
> On 14/06/12 17:49, jmcclure@hypergrove.comwrote:
>
>>
"Wikidata publishing infoboxes and Wikipedias using them is again the
client-server model." Not sure
On 14/06/12 17:49, jmccl...@hypergrove.com wrote:
"Wikidata publishing infoboxes and Wikipedias using them is again the
client-server model."
Not sure where this chestnut is coming from. Transclusion is as close to
client-server as my cooking is to being gourmet!
There's NO API. so I don't unde
Gregor says>
Or are you proposing to simply use the existing
template programming
with the only the difference that wikidata is the
only mediawiki where
the properties can be accessed within templates?
Much of my argument
assumes that you are looking for a non-template
based infobox
renderer, I
> Gregor, I'm a bit confused -- are you talking about the transclusion design
> approach in this statement?
Yes, in the sense that it demands to be the only access to wiki data
content in a Wikipedia.
> because, if so, I'd think there'd be a number of
> infobox "styles" that can be selected by an
"I strongly disagree with the demand to make this the only choice."
-
Gregor, I'm a bit confused -- are you talking about the transclusion
design approach in this statement? because, if so, I'd think there'd be
a number of infobox "styles" that can be selected by an author on the
wikidata plat
"Wikidata publishing infoboxes and Wikipedias using them is again
the client-server model."
Not sure where this chestnut is coming from.
Transclusion is as close to client-server as my cooking is to being
gourmet!
There's NO API. so I don't understand your commenst at all,
sorry.
On 13.06.
On 14 June 2012 12:33, Gerard Meijssen wrote:
> Finally, when Wikidata provides data and info boxes, it does not mean that
> any project is compelled to use it. As Wikidata matures, it will become
> increasingly clear that it is not the best practice.
that may be, but Wikidata needs a path to get
Hoi,
Technically there is nothing stopping Wikidata from hosting multiple
infoboxes on the same subject. The big thing about such infoboxes is that
their layout is the same for all subjects in the same category. This does
not mean that every one looks the same but it does mean they follow a
consist
While I agree that it is desirable to support simple, preformatted
Infoboxes that can, with minimal effort be re-used in a large number
of language versions of Wikipedia, I strongly disagree with the demand
to make this the only choice.
I think the present Wikidata approach to allow local Wikipedi
On 14/06/12 00:39, jmccl...@hypergrove.com wrote:
Transclusion is surely fundamental to wiki application design. The
[[wikidata]] proposal by contrast is a client-server API, such things an
artifact of the 20th century. What is the point of it here?
Ultimately the problem you're grappling with i
Hi Bináris,
I never said Wikipedias will always agree; in fact, I
pointed to science articles, not social or religious articles, as a
dominant use-case. In any event, whatever [[wikidata]] pages are
transcluded is entirely under the whim and control of a wikipedia. If a
wikipedia wants its own (
On 14/06/12 07:20, Bináris wrote:
Are you sure that Wikipedias will always agree in population and
religion charts?
They can always override it locally.
smime.p7s
Description: S/MIME Cryptographic Signature
___
Wikidata-l mailing list
Wikidata-l@li
Are you sure that Wikipedias will always agree in population and religion
charts?
--
Bináris
___
Wikidata-l mailing list
Wikidata-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-l
On Thu, Jun 14, 2012 at 1:13 AM, wrote:
> I don't understand why it's so unlikely, Lydia. ANY educational article
> (science, math, engineering) can have graphics whose underlying data is not
> language-sensitve. How about timelines on a bio article -- that's anothr
> example. Or a map within a p
I don't understand why it's so unlikely, Lydia. ANY educational
article (science, math, engineering) can have graphics whose underlying
data is not language-sensitve. How about timelines on a bio article --
that's anothr example. Or a map within a place article? Or financial
data within a busine
Hi John,
On Thu, Jun 14, 2012 at 12:39 AM, wrote:
> I base my belief that [[wikitopics]] is operationally faster on a basic
> difference between the two designs, as I think the wikipedias will operate
> faster if they merely transclude infoboxes of their choice, at their own
> speed, from the wi
I base my belief that [[wikitopics]] is operationally faster on a
basic difference between the two designs, as I think the wikipedias will
operate faster if they merely transclude infoboxes of their choice, at
their own speed, from the wikidata central repository.
Transclusion is
surely fundam
22 matches
Mail list logo
