Wikidata:Contact the development team/Archive/2014/08

This page is an archive. Please do not modify it. Use the current page, even to continue an old discussion.

Invalid time value

Bot managed to store invalid time value: [1]. --JulesWinnfield-hu (talk) 10:54, 29 July 2014 (UTC)

Thanks! Taking a look. --Lydia Pintscher (WMDE) (talk) 15:18, 30 July 2014 (UTC)

There are two bugs as I see:

1. Magnus Manske`s bot set too high precession (11, day) for value 1993-01-00. It must be 10 (month) or less.
2. Wikibase`s value validator pass these values while saving.

— Ivan A. Krestinin (talk) 09:15, 7 August 2014 (UTC)

Language selection for "In other languages" section (wb-terms)

At every page I get the second section titled "In other languages"(

<h2 id="wb-terms" class="wb-terms-heading">In other languages</h2>

). And the languages always listed are: "русский, татарча, башҡортса" (russian, tatarcha, bashkortsa), list is same even for cleared cookies. How the list is determined? How can I change this list to some set of languages I know? Or can I hide this element, because I don't speak most of listed languages. There is also historical memory of the crimes of some nations, who speaks in these languages, and this delivers negative feelings to some users.... `A5b (talk) 22:17, 1 August 2014 (UTC)

@A5b: I’m just another ordinary user but I get a different list when I’m not logged in, so I suspect the list is determined by IP. But I know how to change the list: Just create your user page with the line: {{#babel:code for language you speak|second language you speak|third language you speak or want to edit etc.}}. On Wikidata Babel declarations are used for configuration; only declared languages appear in your list (when things work correctly), even if you declare you don’t speak the language (e.g., ru-0).—Al12si (talk) 16:27, 2 August 2014 (UTC)

Wrong AppleTouchIcon

On my ipad, the bookmark icon is the Wikipedia "W" while it should be the Wikidata icon (cf. Manual:$wgAppleTouchIcon). Thanks. — Ayack (talk) 18:58, 30 July 2014 (UTC)

The same on my Android tablet's Opera, which, as far as I know, doesn't use the Apple touch icons but some other files that look very much the same in the end. --YMS (talk) 19:39, 30 July 2014 (UTC)

Does anyone know which icons those are? The Favicon here seems fine so I assume it is not that. --Lydia Pintscher (WMDE) (talk) 10:37, 4 August 2014 (UTC)

I still don't know which file Opera uses (did not find anything in the page source code - is it actually the AppleTouchIcon?), but the Apple one is this file. --YMS (talk) 10:53, 4 August 2014 (UTC)

Ok thanks. Will investigate some more. --Lydia Pintscher (WMDE) (talk) 13:30, 11 August 2014 (UTC)

Yoruba translation

I was just looking at the Yoruba version of the main page and it looks like it's pulling in text in Greek mixed along with the untranslated content in English. Should probably be only English as is the case with other partially untranslated languages. Bug? -- Phoebe (talk) 16:20, 9 August 2014 (UTC)

The Main Page does not use the Translate extension (yet?). Instead, this looks like an incomplete translation (from Greek to Yoruba) by Demmy. Just edit the page! --Ricordisamoa 11:03, 11 August 2014 (UTC)

Is Commons:Commons:Wikidata for media info still current, or should it be marked 'historic' ?

It would be good to know if this page from 12 months ago is still indicative of current thinking re Commons and Structured Data, or whether it has been superseded, and should now be marked 'historic'. Jheald (talk) 10:37, 14 August 2014 (UTC)

It is still correct but will likely not be updated in the future so I think it is ok to mark it as historic. Future planning will go to Multimedia/Structured Data. --Lydia Pintscher (WMDE) (talk) 12:46, 14 August 2014 (UTC)

Namespace awareness

Furher to the immediately above conversation, could a bugzilla request please be filed for a functionality enhancement to allow Namespace awareness ?

By this I mean the ability for different namespaces on a particular sister project to be allowed to be treated as essentially different sister projects in their own right, so that for example, a Q-number could have a first-class peer relationship with each out of a Commons category, a Commons article ("gallery"), and a Commons creator entry.

Presumably this could be achieved by creating new alias sister projects -- eg commonscat and commonscreator, that alias to these namespaces. The MediaWiki software might also need to be adjusted, so that it could distinguish and signal from which from namespace on Commons a request to WikiData is coming from. Jheald (talk) 10:58, 14 August 2014 (UTC)

@Multichill:: Can you link to the plans you have wrt linking between galleries and categories and so on and explain that a bit, please? --Lydia Pintscher (WMDE) (talk) 12:48, 14 August 2014 (UTC)

I think that was actually the outcome of the RfC - that ideally we should link a Q-item to BOTH Commons gallery and Commond category, but as far as this is not technically feasible only the gallery link is allowed, and Commons categories are not per se notable.--Ymblanter (talk) 16:38, 14 August 2014 (UTC)

Phase 2 on Commons

Why hasn't it been deployed so far? --Ricordisamoa 11:19, 11 August 2014 (UTC)

Because it is not very useful without access to data from arbitrary items and I fear people would start storing data about files. --Lydia Pintscher (WMDE) (talk) 13:31, 11 August 2014 (UTC)

@Lydia Pintscher (WMDE): Would it be possible to enable data access at least for the Creator namespace? All those templates can be connected with Wikidata and there is no danger of confusion. (example: commons:Creator:Joaquín Sorolla).--Micru (talk) 14:33, 11 August 2014 (UTC)

I think it'd be pretty confusing to be honest. People already don't understand the distinction between language links and data :/ --Lydia Pintscher (WMDE) (talk) 14:41, 11 August 2014 (UTC)

As you wish, but if you don't give them something to chew on they will never learn ;)--Micru (talk) 13:24, 13 August 2014 (UTC)

Can I check to see whether I understand the problem correctly? Something like Q5582 needs to point to Commons:Category:Vincent van Gogh or Commons:Vincent van Gogh (currently it points to the latter); so, given that one Q-number on WD can't currently be linked to multiple targets in different namespaces of sister projects, as I understand it, Q5582 can't also point to Commons:Creator:Vincent van Gogh, which means that Commons:Creator:Vincent van Gogh can't draw data from its Q-number.

Can somebody tell me whether that understanding of mine is correct?

I still don't understand the technical reasons why this is supposed to be so hard to fix. I'd be very grateful if somebody could point me to an accessible discussion explaining the underlying technical difficulty.

It's also a Blocker for sorting out the current Commons category/gallery muddle, with sometimes a Q-number pointing to a category, and sometimes a gallery. It's a real shambles. The most popular proposal in the Rfc that was held here on Wikidata, was that a Q-number ought to be linked to both. Real effort should be put in to make that happen.

As for Lydia's point that people would start trying to create Q-numbers for files, that's easily avoided. Simply don't make it possible for a Q-number to point to the Commons:File: namespace. Then the problem doesn't arise.

Micru is right: over at Commons we need to be given something we can start to chew on, so we can start to learn. It will make the whole Structured Data design process much more likely to succeed, if you have an educated community there, that understand WikiData, that can then be your partners in the design process. Jheald (talk) 18:36, 13 August 2014 (UTC)

@Jheald: The main questions that you have to figure out are: which concepts are represented by the gallery, the category, and the creator pages? And does it make sense to have a separation between the gallery and the creator? If you take a look to wikisource Author pages, they are both autor page and autor work list in one and that makes it much more simpler. Example: s:fr:Auteur:Dante_Alighieri--Micru (talk) 19:28, 13 August 2014 (UTC)

@Micru: The commons {{Commons:Template:creator}}, which draws from the Creator namespace, is intended to be used at the top of categories and on file pages (click on the artist entry and expand). Its use on the latter is particularly characteristic in bulk uploads from GLAMs, who are starting with good structured data, and using an automated upload process -- ie it's used on our best file description pages. The template may also be used on galleries, but this is rather more rare, because (i) typically galleries may have been created without knowledge of the creator template, or before it was available, or by users who just didn't really want to use it; also (ii) sometimes galleries may want to show the available pictures of the artist in a row, which jars with repeating one of those pictures in the template.

The basic problem here is that whether a page is a category or not is a property of the target namespace, not of the underlying thing the page is about. The original data modelling, separating cats and non-cats as being about different things, was wrong; and needs to be fixed; because, as well as simply being not right, it is now causing a number of difficulties. (For example, the ludicrous parallelism between 'items' and 'quasi-items', which makes the WikiData structure a lot harder to understand than it needs to be). The time to fix this is now, because the problems it is creating are now, and as things go into the future things are only going to get worse, with workaround piled on workaround. Also, because Commons really needs to start understanding Wikidata as soon as possible, because structured data is going to be a huge shift, and the commons community is mission-critical: it does the primary heavy lifting for all our copyright assessment.

You suggest putting the Creator information in the gallery page. But then it wouldn't be accessible on the Category page, and it wouldn't be accessible on the file page. Most artists don't even have a gallery page, because such pages are a handmade vanity, rather than something automatically maintained. But some artists have two, or more, because they were so prolific. Plus, on top of all of that, most of the interwiki links are between Categories and wiki-articles, not galleries and wiki-articles: so sometimes the template would work (if the Q-number was owned by the gallery), and sometimes it wouldn't (if the Q-number was owned by the category). It would be a complete shambles.

What is needed is namespace awareness, and it is needed now. Jheald (talk) 20:23, 13 August 2014 (UTC)

@Jheald:You suggest putting the Creator information in the gallery page. Actually the other way round, copy&paste the gallery after the creator template in the creator page, wrapped in <noinclude> if needed, so only the template is transcluded on file pages. And remove the template documentation from the Creator page, because that Template documentation belongs to the Template:Creator page, not to the Creator namespace. The merging "gallery->creator page" can be bot-automated, if there is no gallery then it is skipped, and if a picture appears twice that is not such a big deal. What do you think of that suggestion?

I think for now it would be better to forget about other things for a while and focus on what we can do now.--Micru (talk) 07:03, 14 August 2014 (UTC)

Yes, it is good to find things that can be done now; and the more that the Commons community can start using, as so really get to understand, Wikidata as soon as possible the better.

But this proposal would be a really ugly messy hack, screwing up the one area of Commons that has a relatively clean structured data design. I think messing this up would be received very badly.

To start with, let's look at the numbers: there are currently 18,182 Creator templates, with 17,320 Creator identified home categories (information from here). On the other hand, there are 112,000 galleries (according to this update. Most galleries don't relate to a creator -- they relate to some arbitrary thing, that may or may not have a Q-number. (eg: images from a particular edition of a book). And, as noted here, sometimes a single Q-number "can be illustrated with more than a single gallery, perhaps focusing on different aspects of the topic, or just split for ease of navigation (e.g. London Underground stations A-L & M-Z)."

It's also worth noting that, as User:Jarekt put it on 21:10, 10 August 2013 in this discussion on Commons,

"Currently we mostly have interwiki links between commons categories and wikipedia articles and commoncat templates linking wikipedia articles with commons categories. There are some gallery <-> article links but in most cases galleries are really out of date and only useful as a way to find a category (there are exceptions)." [Emphasis added].

That's a pretty standard view on Commons -- galleries are not well maintained (and not easy to maintain). Someone created one, perhaps eight years ago before there was a very extended category system. Since then it hasn't been updated, and may bear no relation to what are now the best images on the subject. In contrast, categories auto-update and look after themselves. So that is why overwhelmingly it is commons Categories that have been interwiki'd to wiki articles, not commons Galleries.

Summary: At the moment galleries live in a clear namespace. This is a good thing. Moving some galleries (but not others) to the Creator namespace would break this, and it would also break the current straightforward clean-ness of the current Creator pages. Both of these would be bad things, and would be received badly. Jheald (talk) 10:25, 14 August 2014 (UTC)

@Jheald: To be honest I don't understand how merging the gallery of an author and a metadata about an author breaks things. You could even merge the galleries, the categories, and the creator template all in one... For the other cases that you comment:

• When you have split galleries in Commons that is fine, you can relate both to a central one using the property "part of"
• even galleries that don't have now a Q number, might have one if they refer to a well defined concept. That book edition would qualify
• that galleries are out of date now, doesn't mean that cannot be automated in the future when wikibase is deployed on Commons and the query feature is ready.

I suggested to start with Creators and not with Galleries because Creators are almost ready to take Wikidata info and they are not that many (20k is a manageable size), but of course the next step could be Galleries (the ones that are just any concept).--Micru (talk) 13:25, 14 August 2014 (UTC)

┌────────────────────────────────────────────────────────────────────────────────────────────────────┘

@Micru: I would love to see the Creator template draw from WikiData. It's the single step that could most help Commons editors start to understand and interact with WikiData. The sooner more Commons people start really experiencing and using WikiData, right now, the easier will be the transition to make the later stages of Structured Data for commons possible; and the more meaningful, technically-informed and useful (and perhaps less time-consuming, irrelevant and annoying) will be the contributions from Commons people (ie me) trying to help the process.

So let's think what this would actually mean, to see if I am understanding you correctly. At the moment we have a template that is hard-coded with language translations and all sorts of other goodness. We want to be able to draw all that goodness from Wikidata instead. If we just want a template that can appear on a gallery page, and look up the data from the directly corresponding Q-number, that is easy, and can be coded in the Template: namespace. But we want a template we can use on category pages and file pages. So the template would need to be defined on the page linked to the right Q-number. Which is a gallery page, per policy.

So we need to design a wiki-code snippet that is completely ignored if the gallery page is being viewed normally; but if the page is being transcluded from a Creator template, then it should produce the filled-in template contents and suppress the gallery.

And then, when either Arbitrary Access or Namespace Awareness is implemented, at that time then the relevant code can be moved back to the Creator page.

It's hacky; but, actually, it does seem do-able.

I'm presuming that Transcluded/not-transluded can be switched with include and noinclude, just like we do with template documentation.

And there will still be a Creator template, so it will still appear in the category for Creator templates, and there will still be a Creator page talk page available for discussions.

And this will make it feasible to migrate the whole of the Creator and Institution hierarchies to draw on Wikidata, using present-day technology.

@Micru: you're a genius. If you can knock together a prototype, let's see if we can make this happen. Jheald (talk) 16:22, 14 August 2014 (UTC)

However ... will it actually work? It depends on being able to fool Wikidata that the request is coming from the gallery page we're routing through, not the category page where we want to ultimately display the information.

But is that what the MediaWiki software passes to WikiData? Does the identity of the invoking page (the identity that gets passed to WikiData) get reset when we route through an article page, because the page doesn't start with "Template:" ? Or is transclusion the relevant thing -- is it the identity of the original page at the start of a chain of transclusions that MediaWiki passes to WikiData (in which case the hack won't work) ? Jheald (talk) 16:53, 14 August 2014 (UTC)

@Jheald: Test: commons:Creator:Edward Curtis, at least without wikidata it works more or less :) --Micru (talk) 17:48, 14 August 2014 (UTC)

@Micru: Okay. Moved all the content to the article page. Still seems to be working, eg at File:Edward_S._Curtis_Collection_People_001.jpg.

So, now the $64,000 question. Can we get any Wikidata into there ? Jheald (talk) 18:10, 14 August 2014 (UTC)

@Micru: Small problem. Seems to be showing the spurious word "File" after the Creator name, in the artist credit on that file page above. Jheald (talk) 18:15, 14 August 2014 (UTC)

Consistent, anyway. Looking at:

• Commons:Edward Sheriff Curtis
• commons:Creator:Edward Curtis
• File:Edward_S._Curtis_Collection_People_001.jpg
• Commons:File:Edward_S._Curtis_Collection_People_001.jpg
• commons:Category:Edward Sheriff Curtis

Jheald (talk) 18:19, 14 August 2014 (UTC)

Fixed. It was an old bug in the template. So, now to see whether it can draw from Wikidata. Which you will need to code. :-) Jheald (talk) 18:33, 14 August 2014 (UTC)

Excellent! Actually I would show the template on the gallery too. And I am thinking if we really need the "Creator" namespace, you can just use {{:Edward Sheriff Curtis|creator}} on files instead of {{Creator:Edward Curtis}}.

I think it would be better to discuss these changes in Commons to see if they are well seen over there. And then ask Lydia again about enabling data access :P--Micru (talk) 18:51, 14 August 2014 (UTC)

First let's confirm that we can get the template to draw from Wikidata, because I am still not sure that that is going to work.

Initially I would not show on the gallery, so we can show that we can pull this off with zero user visible change to that page.

As for the creator namespace, maybe eventually yes it will go away, but at the moment the system has been around too long, and there are too many tools -- eg GWToolkit -- that target it, to do anything too quickly. Dismantling the whole named Creator template system is a decision for much further down the track.

Of course we're going to show it to Commons, but first let's confirm we can get a fully operating prototype, that is ready for mass roll-out / migration. Jheald (talk) 19:14, 14 August 2014 (UTC)

On second thoughts, I can see that including an instance of the template call somewhere on the actual gallery page would be really useful for you fast prototyping. We should remove it before we show the finished result to Commons though. (Or offer them the diff, so they can see it works both with and without).

In the migration period, it may actually be really useful to have both {{:Edward Sheriff Curtis|creator}} and {{Creator:Edward Sheriff Curtis}}, because then you can see and confirm side-by-side that the new matches the old, before you replace the old with an instance of the new. Jheald (talk) 19:36, 14 August 2014 (UTC)

The reason I think this isn't going to work (even if Phase 2 was turned on) is that the gallery page has a PAGEID of 18776, which is what gets matched to the Wikidata Q-number. However, in a transclusion, PAGEID returns the id of the transcluding page, ie 689484, which was the id of the category page. It is 689494 that MediaWiki will pass to WikiData when the Creator template is transcluded from the Category page, not 18776, so it will get matched to the Category's Q-number, not the gallery's. If there was a hack to get around that then we would be almost home, but I don't know that there is one. Jheald (talk) 00:36, 15 August 2014 (UTC)

Probably not, I tried here and it doesn't work (birth date should appear). Perhaps better to wait till arbitrary access is available.--Micru (talk) 07:48, 15 August 2014 (UTC)

A suggested Roadmap for fixing Phase One on Commons, and beyond

Per the above conversations, Phase One roll-out on Commons is currently a mess -- primarily because both Commons categories and Commons galleries want to be first-class peers of wiki-article Q-numbers.

In the spirit of @User:Micru's recommendation that we think of what can be done now with existing software, can I suggest the following steps on a roadmap

Stage A - Clear policy, so people know what should link to what.

Getting Phase 1 right is a pre-requisite before switching Phase 2 on, because Phase 2 template writers need to know that they can rely on a consistent set of Phase 1 relationships.

For the moment, I would suggest the following policy:

1. Where there is a choice, Commons categories and galleries should target Q-numbers on WikiData representing items (ie wiki articles) wherever possible, rather than Q-numbers representing quasi-items (ie wiki-categories). A quasi-item can be indicated for an item using property P910. Quasi-items should only be targeted if there is no existing item, and none is likely to be created. Items can be discovered for quasi-items using property P301
2. Where there is a choice, Q-numbers should normally target Categories on Commons, rather than Galleries. Galleries should only be targeted when they are of particularly high quality.

Comment: These links will soon be being featured on the "in other projects" part of the sidebar, so it is likely people will be feel very motivated to make the sidebar point to (what they consider to be) the best landing page on Commons. It is essential that there is clear guidance, so they know what is preferred and what is not.

Stage B - Namespace awareness is implemented.

1. Q-numbers that target commons Galleries should now also target commons Categories. The sidebar should now show two links, to a commons category and to a commons gallery when these both exist. Q-numbers for commons Categories should gain an additional target to a Commons gallery, wherever such commons Categories have a principal gallery.
2. Q-numbers should also gain new targets where possible in the Commons creator and Commons institution namespaces. Information from these namespaces should be migrated to WikiData, initially by drawing from WikiData through templates. (ie switch on Phase 2 for these namespaces).

Stage C - Arbitrary access is implemented.

1. Arbitrary access is not implemented on Commons until Stage B has been completed.

Comment: Arbitrary access (ie opening the flood gates to people writing far more sophisticated templates, that can draw from WikiData in far more sophisticated ways) requires a consistent data model to be in place, and consistently populated, first. Otherwise it is a recipe for chaos if template writers start trying to write templates against data that simply isn't coherent.

Stage D - Subject tagging

1. Commons top-level file description templates have a "subjects" line added. The "subjects" line will be populated with a template in which can be stored a number of WikiData Q-numbers. An edit gadget will make it easy for people to add new ones.
2. Such subject tagging will make possible a new search engine, to allow people to search Commons by tag-intersection.

Comment: In reality, the per-image subject data will not be stored on the filepage, it will be stored in a queryable database. But it can be made to look as if it is stored on the filepage, so that when somebody hits the [edit] button, it presents

  {{ Subjects | Q1234 Q5678 Q91011 }}

as part of what appears to be the wikicode for the page. If the contents of that template were changed when the page was edited, the software would pick it up and appropriately update the queryable database. (Presumably having run the edit through a sanity filter, just to make sure it made sense).

Of course, most users (and especially end-readers) would be encourages to 'tag' the picture directly, in special apps talking directly to the queryable database. But there's an advantage to having edit-page interfacing as well, as this allows all sorts of bot and semi-bot activity, using the community's existing tools (eg AWB), and changes to the queryable database be made in the context of an edit to the file description page.

Summary

Commons needs a roadmap as to how the march towards Structured Data can be made as evolutionary as possible, so that (for those that want it to) the environment can remain as familiar as possible, and existing tools can be given new uses as easily as possible.

Commons Stage 3 (ie Structured Data for Commons) has been identified as a key existential priority for the Foundation. But fixing Commons Stage 1 is a pre-requisite which we really need to think about now, because at the moment Stage 1 on Commons is the most horrible mess, and it is a *blocker*, impeding the way to anything more advanced.

Thanks for your time, Jheald (talk) 12:42, 14 August 2014 (UTC)

We have a policy for this as created by the community regarding commons link. In the current state; categories go to categories and galleries go to articles. When the technical ability to multi-link for special wikis comes in; there is consensus both galleries and categories should be linked to both articles and categories. John F. Lewis (talk) 12:49, 14 August 2014 (UTC)

Actually, I asked Lydia, in a session at Wikimania, whether restriction was still the current policy, and she told me that it was not. There is extreme lack of clarity on the subject.

What is undeniable is that the pattern you present has not been the pattern of existing interwiki links. It is not the pattern the Commons community wants or even thinks makes sense. And any such pattern would be likely to be washed away like a tsunami once the high profile "in other projects" link goes live on sidebars.

We should face that the reality is approaching the policy outlined in Stage A that I have set out above. We should be writing tools in the expectation of Stage B, which is the data model that actually makes sense, being aware that where we're at at the moment is not at Stage B yet, but in the hope of getting to Stage B as soon as possible. Jheald (talk) 13:08, 14 August 2014 (UTC)

There is no lack of clarity; just lack of a users understanding. What I have said is the policy of Wikidata and should be followed. Whether users do or do not is their choice but policy is policy and must be followed. Please correct all category-articles links as you see them as it is against the wishes of the Wikidata community and our policy. What the Commons community want is irrelevant within our community really in the context that they can not dictate our policy. As everything they can comment but ultimately the decision of what happens here is up to this community not commons. John F. Lewis (talk) 13:14, 14 August 2014 (UTC)

I'm sorry. We must have misunderstood each other there. What I meant is that technically we don't impose a restriction if you link to gallery or category. From the community side there is a policy and plan in place which multichill can explain best as he made the proposal for it. --Lydia Pintscher (WMDE) (talk) 13:16, 14 August 2014 (UTC)

@Jheald: About the topic interwiki linking, once we have arbitrary access there is no need to have two links to Commons in the same item. If both items are linked with topic's main category (P910) / category's main topic (P301), then from either you can read the interwiki links from the other.--Micru (talk) 13:40, 14 August 2014 (UTC)

Okay, I'll hold off further until I've seen what @Multichill: has to say. But @John F. Lewis:, even in this community, Consensus can change. It's not a bad idea to at least listen to what your customers understand about the logic of their data.

@Micru: The problem with what you suggest is that having to use topic's main category (P910) / category's main topic (P301) means that then for every wiki-article --> --> Commons category mapping (the most common mapping one wants to be able to capture), you have to create a Q-number for an artificial "home gallery" associated with that Category, which may not exist. You need to put in extra logic, to effect what is now a two-stage mapping. And you need to police the integrity of the cat<->cat and gallery<->article correspondence, otherwise that new logic will fail. On the other hand, with namespace awareness, all this is effectively achieved and maintained automatically by the software, and P910 and P301 can be replaced simply with the identity function. Are the typical P-numbers for categories and the P-numbers for articles really so different, that it really makes sense to partition these properties into separate sets on separate Q-numbers ?

One thing I would be genuinely interested in is how good the current correspondence integrity is at the moment. I posted a question to this effect on Project Chat a couple of days ago, but haven't received any answers. I don't know if that is a sign that my query is so simple that I ought to learn how to write it myself; or so tricky that writing it is more than trivial. If correpondence integrity is a difficult thing to monitor, then perhaps that needs to be looked into. Jheald (talk) 14:51, 14 August 2014 (UTC)

@Jheald: For the users it should be irrelevant which data structure we use here in Wikidata as long as they are able to interact with it in an easy way. Of course there are no interfaces because there is not the option to use that kind of connection yet. I agree that ideally it should be possible to link articles and categories from the same item, but that is not possible at the moment, and I have no idea for when or if it is planned.

I have not replied to your message in the project chat because from your message I could not figure out what you want to get... The tool that you can use to make queries is called Autolists. For instance to get a list of all wikidata items with a sitelink to commons, you can write "link[commonswiki]" on the WDQ field (without quotation marks). You can also filter by what the label contains or doesn't contain, category, and so on.--Micru (talk) 15:41, 14 August 2014 (UTC)

Just for the record reffered "policy" is based on this Rfc that include lot of different opinions and was closed bit controversially (even changed two times after closing).

Also note Commons "guideline" that encourage people to link Commons categories to both Wikipedia categories and articles, with no preference for cat-cat solution. As result (disregarding P737) commons categories are linked to wikidata "article items" on daily basis and i think that represent cosiderable part of the links (maybe majority). It will be nice to have exact figures for that (as Jheald mentioned above). --Jklamo (talk) 15:24, 14 August 2014 (UTC)

I am afraid it just means users are not aware of the community decision, not that they do not want to follow. It might be indeed that we dd not make the decision clear enough in terms of the policies, and did not advertize it enough across the projects, but as soon as the technical side remains the same I am afraid we would need a new RfC to change things.--Ymblanter (talk) 16:48, 14 August 2014 (UTC)

Different approach

Arbitrary break to put a proposal what to do in the meantime while we don't have arbitrary acces. Copy from what I posted on the Village Pump: At the moment it's only possible to access statements on the connected item. So take for example Commons:Category:Haarlem, we can access the statements on Category:Haarlem (Q7427769), but not on Haarlem (Q9920). Of course we want to have access to those statements. First we need tracking of Wikidata item usage, because if an item changes, we need to know what pages to purge. Once we track the usage, purging needs to be implemented. This is like templates on steroids, updating an item here can potentially impact 100s of pages on 10s of connected wiki's. I talked with Lydia about that the other day and one of the things we discussed was delayed purging depending on the usage of an item (used on < 10 pages, purge now. Used on < 100 pages, purge after an hour. Used on < 1000 pages, purge after 4 hours, etc) and another edit to the same item would reset the timer. This would be a good way to limit the impact of vandalism. If we have the tracking and the purging, arbitrary access can be enabled. So you can access Haarlem (Q9920) Commons:Category:Haarlem. On Commons we would just make a lua template that looks for category's main topic (P301) (or category combines topics (P971)), grabs the data from the connected item and displays that in a pretty way. On other places we need to update templates to not use Property:P373 any more, but either the connect Commons category (if it's used on a category) or the connected article (category's main topic (P301) again). I don't know the time path for this development, but I'm pretty sure the Wikidata development team is at least going to start with it in the next couple of months. It's a pretty tough nut to crack, so I'm not sure how long it will take.

Picture how items connect

Let's take a radical different approach, that also connects well with the future arbitrary access:

1. Create an item for every Commons category if it doesn't exist yet
2. Mark these items as Wikimedia category (Q4167836)
3. Link each category to the relevant topic item using category's main topic (P301) and/or category combines topics (P971)
4. For category's main topic (P301), also do the inverse topic's main category (P910)
5. Deploy javascript on Commons for the category namespace that fetches the relevant data from the Wikidata api
6. By the time we get arbitrary access, we can just switch the javascript (client side) to lua (server side)

The first 4 items is just a lot of work with existing tools. For the javascript part we would need someone to write it as a gadget I guess so we can enable that by default at some point. Multichill (talk) 17:02, 14 August 2014 (UTC)

@Multichill, Jheald: Check this out :) Help_talk:Sources#Mock-up_of_a_Wikidata_.7B.7BCite.7D.7D.--Micru (talk) 12:56, 15 August 2014 (UTC)

Wikidata sitelinks on Wikidata

I've added a sitelink, but it is not shown in the GUI. --Ricordisamoa 19:47, 19 August 2014 (UTC)

Works here. I see it in the UI. John F. Lewis (talk) 19:50, 19 August 2014 (UTC)

I can see it in the 'diff view', but not in the 'view view'. --Ricordisamoa 19:59, 19 August 2014 (UTC)

The same here. --Stryn (talk) 20:10, 19 August 2014 (UTC)

Also Special:Diff/151777491. --Ricordisamoa 20:02, 19 August 2014 (UTC)

Both look fine to me in both views. John F. Lewis (talk) 20:03, 19 August 2014 (UTC)

A null-edit fixed it for me. --JulesWinnfield-hu (talk) 20:41, 19 August 2014 (UTC)

Badges diff

Diff for badge changes gives invalid link like here Special:Diff/151782007. --JulesWinnfield-hu (talk) 20:47, 19 August 2014 (UTC)

Yeah I also just noticed that -.- Bug to track it is at bugzilla:69758. --Lydia Pintscher (WMDE) (talk) 20:54, 19 August 2014 (UTC)

Redirect

Maybe autodescription of redirect have some problem? Reindirizzamento a $4: Q3760925, Q1510227 (Example) --ValterVB (talk) 07:40, 20 August 2014 (UTC)

Jut for info {{Q}} return Script error if Item is a redirect (ex. Gerardo Amato (Q3760925)) --ValterVB (talk) 07:56, 20 August 2014 (UTC)

is redirect operational yet, or is it just in test ? how do you use it ? is it automatic with merge.js ? --Hsarrazin (talk) 13:49, 20 August 2014 (UTC)

It's operational, available only with API (need a BOT) made with api.php?action=wbcreateredirect&... --ValterVB (talk) 13:53, 20 August 2014 (UTC)

the merge gadget does not use API ? or is it just a matter of time for this gadget to be adapted ? :) --Hsarrazin (talk) 21:50, 20 August 2014 (UTC)

Need only some time. --ValterVB (talk) 21:57, 20 August 2014 (UTC)

Delete a badge

How is possible delete a badge? --ValterVB (talk) 09:46, 21 August 2014 (UTC)

Deselect it and save via the special page. Deselecting can be done with "CTRL + left mouse click". --Lydia Pintscher (WMDE) (talk) 10:09, 21 August 2014 (UTC)

Two new budges

I have created 2 new budges featured list badge (Q17506997) and Did you know article (Q17507019), how to support them? Maybe we can add arbitrary budges in the future.--GZWDer (talk) 10:13, 21 August 2014 (UTC)

I'd like some kind of community ok for them to be created. And then we can just add them to the config. --Lydia Pintscher (WMDE) (talk) 10:18, 21 August 2014 (UTC)

Having a badge for featured lists should basically not be critical, as it's just another kind of featured articles. Many Wikipedias do have three of those (featured articles, good articles and featured lists), and display this status in the interwiki links list, so we should have it in Wikidata instead of keeping this one interwiki information locally in the articles. I'm not sure whether there are some conflicts with different kinds of featured lists (compare Category:Featured lists (Q5873672) and Category:Wikipedia featured lists (Q8101833)), though.

For "Did you know", I don't see a benefit of such a badge. Is there any Wikimedia project that displays this information in its interwiki links? Is there any benefit for readers, authors or tools to know that a certain article language once was linked in a certain section of the main page? --YMS (talk) 13:48, 21 August 2014 (UTC)

Portuguese Wikipedia is considering the removal of the "Anexo" namespace: pt:Wikipédia:Esplanada/propostas/Eliminação do domínio Anexo (26abr2014).Helder 17:26, 21 August 2014 (UTC)

I created recommended article (Q17559452) which is used in fi-wiki, da-wiki, se-wiki and sv-wiki. At least in fi-wiki it's the third highest quality of acrticles after featured and good articles. --Stryn (talk) 16:03, 21 August 2014 (UTC)

So what about w:Wikipedia:WikiProject Council/Assessment FAQ? Most of articles on enwiki assessed based on its quality (not sure about other wikis), showing that seems to me a lot mre interesting than DIY usage. --Jklamo (talk) 17:04, 21 August 2014 (UTC)

Two little annoyances

First, the gadget MediaWiki:Gadget-AuthorityControl.js is again not working normally using firefox 31, it works only on debug mode. Browser console output looks like this:

Click [expand] to view the content

"JQMIGRATE: Logging is active" load.php:150
"Dependencies ready, intializing AC gadget directly." load.php:278

And the second one is regarding the suggester, when I try to middle-click on one of the suggestions, it doesn't open in a new tab. This feature seems to work only in the search box, but not on the input value box. Not tragic, but it would be nice to have it working there too :)--Micru (talk) 12:54, 21 August 2014 (UTC)

Hey :) We're looking into the issues with teh gadget right now. For the suggester: Can you open a bug report please on bugs.wikimedia.org? Thanks! --Lydia Pintscher (WMDE) (talk) 13:55, 21 August 2014 (UTC)

Done! Bugzilla: 69908.--Micru (talk) 16:14, 22 August 2014 (UTC)

Allow setting different WikiProject for budges

In Wikidata:Project chat#Using badges for article quality and importance, it's requested to store related WikiProject for article quality and importance.--GZWDer (talk) 05:25, 25 August 2014 (UTC)

If there is consensus to create them I am happy to do that. --Lydia Pintscher (WMDE) (talk) 06:43, 25 August 2014 (UTC)

Why so big size of diff?

[2] --Infovarius (talk) 13:48, 27 August 2014 (UTC)

That's due to the new internal serialization. It is a bit more verbose. It's fine :) --Lydia Pintscher (WMDE) (talk) 15:36, 27 August 2014 (UTC)

No Label

This page is full of template errors. Each links says: "no label": Wikidata:WikiProject Medicine/Properties - Tobias1984 (talk) 16:09, 27 August 2014 (UTC)

Likely because the Lua module creating it is relying on the internal serialization. This changed as announced. The module needs to be adapted. --Lydia Pintscher (WMDE) (talk) 16:41, 27 August 2014 (UTC)

ISO-format date: Precision parameter

Moved from WD:Project chat#ISO-format date: Precision parameter

An edit, changing precision value to 7 (century), makes the date 1815-08-15 look as 18. century instead of 19.century. How to fix it? Sealle (talk) 06:35, 18 August 2014 (UTC)

• This is bug in wikidata editor as I think. Another side: User talk:Ivan A. Krestinin#Constraint violations P570. — Ivan A. Krestinin (talk) 08:18, 18 August 2014 (UTC)
• Why not use "18 hundreds" instead of "18 century" (which is easy to read as 18th century)?
• If it is an error, shoud it go to the attention of the development team?--Ymblanter (talk) 05:25, 19 August 2014 (UTC)

there really is a problem with dates, as a date for "20. century" shows as 2000-01-01 - it should be 1900-01-01 (or 19.. as used in most databases, including commons dates). The very strange result is that a person can be married in 1985 and born in 2000-01-01 !! - even if "precision" should make it read as 20.century, there still is a problem... :D --Hsarrazin (talk) 13:43, 20 August 2014 (UTC)

• Just a little amendment: the beginning of the 20th century is 1901-01-01, not 1900-01-01. Sealle (talk) 14:20, 20 August 2014 (UTC)

Sealle, I agree - 1901 is the REAL first year of the century :) , but it does not make it right to use the last year of the century to store the century value… if it could be stored with 19.. or 1901, or better, the approximate value and precision having it displayed as century, but without loosing the approximate value : sometimes we know the decade… but only have year or century as precision argument :S

I think it's VIAF that uses the following coding : 1800-1999, to signify "19-20th century" - i.e. from begining to 19th to end of 20th - or 1800-1899 when birth AND death are within the 19th century, without precision... - maybe it is not the "real" first year of the century, but, at least, it's clear, and birth is always < other events, and death > other life events… which is the main point ;)

what I mean is… perhaps we should use the smaller value for "begining dates" and the bigger for "ending dates"… this way, dates could be compared logically… --Hsarrazin (talk) 21:49, 20 August 2014 (UTC)

I wonder, is anybody going to fix an obvious error?! Sealle (talk) 21:16, 22 August 2014 (UTC)

Yes sorry. I've been super busy. Will look into it over the next days. --Lydia Pintscher (WMDE) (talk) 09:31, 29 August 2014 (UTC)

MonolingualTextValue

Could somebody explain, why labels and descriptions serialize as {language, value}, while monolingualtext snak values serialize as {text, language}? How can they serialize differently? --JulesWinnfield-hu (talk) 19:26, 21 August 2014 (UTC)

Can we get an explanation? Is this how it will be forever? --JulesWinnfield-hu (talk) 10:20, 27 August 2014 (UTC)

Indeed a strange idea at first sight. But in a way, I can see some sense in it regarding monolingualtext. The actual (data) value is the combination of the text (string) and the language. So, to have (data)value: {value, language} would be confusing. It would probably make sense to use the same key (text), for labels, descriptions and aliases. But, maybe, there are plans that, as soon as multilingualtext is implemented, labels, descriptions and aliases will return multilingualtext values? That would probably resolve the situation. Random knowledge donator (talk) 11:17, 27 August 2014 (UTC)

These two things – labels, descriptions and aliases (also referred to as "fingerprint") on one side, mono- and multilingual text values on the other side – do not have anything in common and do not share any code. There are no plans to replace one with the other. I can see that the two concepts can be confused. But it's really important to look at them independently and create independent implementations for them. The difference in the serialization is partly unintentional and intentional. It just does not matter if they are the same or not because they do not and should not have anything in common. The different serialization makes this clear. --Lydia Pintscher (WMDE) (talk) 15:38, 27 August 2014 (UTC)

Why would the values for label, description and aliases not be a multilingual values? Label, description and aliases are basically implicit properties. Why making it an obstacle that, for example, accessing both, a label and some other multilingual value, in a particular language requires two completely different implementations? Random knowledge donator (talk) 05:31, 28 August 2014 (UTC)

he:Mediawiki:FeaturedInterwiki.js bug

this script was edited by User:Bene*, with summary asking us to report issues linking to this page, so i'm reporting:

there was a small bug, basically an extra semicolon in the middle of boolean expression (specifically, !$(this).hasClass('badge-featuredlist'); && !$(this).hasClass('badge-featuredarticle' ) . maybe you want to check for similar issues with other languages. see he:Special:Diff/15888375. note that hebrew is RTL, so the old is on the right and the new on the left. looking carefully you might be able to locate the extra semicolon.

peace - קיפודנחש (talk) 15:36, 28 August 2014 (UTC)

Thank you! :) @Bene*: Please see above. --Lydia Pintscher (WMDE) (talk) 09:38, 29 August 2014 (UTC)

Thanks for the report. I fixed the script and made it a bit more readable. -- Bene* ^t_a^l_k 13:07, 29 August 2014 (UTC)

Script error?

I am seeing a lot of script errors ("The time allocated for running scripts has expired.") at Wikidata:List of properties/Generic and other subpages of Wikidata:List of properties. I also noticed that all of the properties have "(no label)" as the title". I don't understand what is happening enough to debug it further! Slaporte (talk) 00:38, 29 August 2014 (UTC)

The first part is a Lua limitation. There are too many calls on that page. The second one is probably an issue with the template that broke after we switched the internal serialization. Needs someone to investigate and adapt the template. --Lydia Pintscher (WMDE) (talk) 09:40, 29 August 2014 (UTC)

In case it helps, it seems like the script errors are only showing when my language is set to English NavinoEvans (talk) 13:23, 29 August 2014 (UTC)

New badges system

Hello! I read your edit to Italian Wikipedia Commons.js (and also to English version), but I can not understand: the new code checks the class "badge-featuredarticle", but actually the class "badge-Q17437796" is added! I suppose it is a temporary mistake. Second question: css definition for new classes will be added automatically, or do we have to add them to MediaWiki:Common.css? Last question: can we use badges system also for other projects links (not only for interlanguage links)? For the moment I create my global.css and it works fine! Thank you very much for your great work! --FRacco (talk) 03:19, 28 August 2014 (UTC)

I'd like to see a clarification of this, too. Currently the software automatically adds a class name "badge-Q17437796" to the HTML for featured articles. What class names will be in the HTML when the whole process is finished:

1. class="badge-Q17437796"?
2. class="badge-featuredarticle"?
3. class="FA"?
4. All of them?

Thanks, --Entlinkt (talk) 17:05, 28 August 2014 (UTC)

@Bene*:: Can you have a look please? --Lydia Pintscher (WMDE) (talk) 09:35, 29 August 2014 (UTC)

It will be 'badge-featuredarticle' once we deploy a configuration change for that and think badge-Q17437796 will also remain. Aude (talk) 10:33, 29 August 2014 (UTC)

What Aude said. -- Bene* ^t_a^l_k 13:08, 29 August 2014 (UTC)

Ok, thanks. But another question: Will the software automatically add icons to these links? If yes, which ones? --Entlinkt (talk) 22:05, 29 August 2014 (UTC)

Just forget the above question, I've missed that the new implementation is already live. Is it now safe to remove the old one from Common.js/.css? --Entlinkt (talk) 22:37, 29 August 2014 (UTC)

It should be, yes. --Lydia Pintscher (WMDE) (talk) 09:11, 30 August 2014 (UTC)

"no language" for monolingual-text type

Tracked in Bugzilla
Bug 70205

We should probably replace P438 (P438) with a monolingual-text property but we would need to be able to say "no linguistic content" (ISO 639-2 : "zxx") and "undetermined" (ISO 639-2: "und"). Is that possible ? --Zolo (talk) 08:05, 30 August 2014 (UTC)

Currently not. I'll have to figure out if we can make that happen. Would you mind opening a bug for it? --Lydia Pintscher (WMDE) (talk) 09:12, 30 August 2014 (UTC)

 Done--Zolo (talk) 09:41, 30 August 2014 (UTC)

Links

Ať the bottom of every page there are four links: Privacy policy, About Wikidata, Disclaimers and Developers. The second one should point to "//www.wikidata.org/wiki/Special:MyLanguage/Wikidata:Introduction" and the third to "//www.wikidata.org/wiki/Special:MyLanguage/Wikidata:General_disclaimer". The first one is bit more complicated because it points to wmf-wiki which doesn't support MyLanguage-links. Thanks for looking into it! Matěj Suchánek (talk) 16:21, 31 August 2014 (UTC)

@Matěj Suchánek: That is something you can solve on your own, as an admin. The second (about) link target (a.k.a. the link target for the About label) is at MediaWiki:Aboutpage, and the third link target (a.k.a the link target for the Disclaimer label) is at MediaWiki:Disclaimerpage.--Snaevar (talk) 17:04, 31 August 2014 (UTC)

Eh... I was searching for some MW pages here and on translatewiki but didn't find anything. So I asked developers. Thank you, will solve myself. Matěj Suchánek (talk) 17:16, 31 August 2014 (UTC)