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
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
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
"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.
"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
> 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
http://wikidata-test-client.wikimedia.de/wiki/Special:RecentChanges
It might be best to limit editing, or try to rope stewards into
running their anti-spambots there ...
--
Erik Möller
VP of Engineering and Product Development, Wikimedia Foundation
Support Free Knowledge: https://wikimediafound
Can´t we just install the SpamBlacklist extension and add links to the
blacklist - MediaWiki:Spam-blacklist
http://is.wikipedia.org/wiki/Melding:Spam-blacklist ?
I think the best way to combat spam is to identify the unwanted behaviour and
then block it. No need to limit editing on the whole w
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
On Thu, Jun 14, 2012 at 7:57 PM, Erik Moeller wrote:
> http://wikidata-test-client.wikimedia.de/wiki/Special:RecentChanges
>
> It might be best to limit editing, or try to rope stewards into
> running their anti-spambots there ...
Uff of course it could only be so long until spammers find the dem
John McClure wrote:
"Of course, thanks for the pointer. Yes, I'd agree that 19788's ontology be
closely reviewed for inclusion. 19788:2 standardizes the Dublin Core
properties, the same I recommend for [[wikidata]] provenance data, the same
slated for the [[wikidata]] ontology. But more to you
Hey,
> One possibility would of course be to just reset the wiki every night to
a pre-defined state.
Would be nice to have it be installed from scratch and populated via a
script every day or so. (Just restoring to a previous state might get
annoying when we make a schema change or something.) Wi
Hello Nadja,
Topic maps do not populate a class model for whatever
the wiki page represents
--- good luck getting agreement on a class
model for anything in WP, will not happen, imho
TM itself has a small
ontology as seen at [[meta:wikitopics]]
--- topic map, topic, type,
name, (name-) varia
13 matches
Mail list logo
