Wikidata:Paper cuts/Archive/2014

From Wikidata
Jump to navigation Jump to search

Wikidata notification system[edit]

Tracked in Bugzilla
Bug 49434

The email still doesn't show all the changes made since the last visit for items and properties (normal pages work fine). --Tobias1984 (talk) 17:45, 26 August 2013 (UTC)[reply]

Can you clarify please what is happening? --Lydia Pintscher (WMDE) (talk) 10:35, 28 August 2013 (UTC)[reply]
I added the link to bugzilla. I know it is already an old issue, but it is the thing that currently bothers me the most. --Tobias1984 (talk) 12:05, 8 September 2013 (UTC)[reply]
I think this is a problem
  1. --Tobias1984 (talk) 17:45, 26 August 2013 (UTC)[reply]

Labels and descriptions of other languages not even visible[edit]

Tracked in Bugzilla
Bug 49079

Without babel boxes and the labelLister tool (which requires an additional click to view, several to edit), labels, descriptions and aliasses of other languages than my selected one are not even visible (let alone editable). I see that it could in theory be a very long list of empty or useless entries, but at least having them as a collapsible section would be an advantage.

I think this is a problem
  1. --YMS (talk) 22:29, 23 August 2013 (UTC)[reply]
  2. A collapsible section, or a Special:Otherlanguages/QNNNNN page, or something. I should be able to edit any language I want without using a gadget. --Izno (talk) 23:00, 23 August 2013 (UTC)[reply]
  3. Show existing (filled) labels and at the bottom an empty one to add more. GerardM (talk) 06:18, 24 August 2013 (UTC)[reply]
  4. Ljubinka (discuter) 13:39, 24 August 2013 (UTC)[reply]
  5. --Jklamo (talk) 13:52, 24 August 2013 (UTC)[reply]
  6. HenkvD (talk) 17:32, 30 August 2013 (UTC), editing and/or displaying Wikidata information should be consistent.[reply]
  7. Pikolas (talk) 13:42, 31 October 2013 (UTC)[reply]
  8. --Micru (talk) 23:46, 25 November 2013 (UTC)[reply]
Comment

While I see your point this would make some pages awfully long while people are already now complaining about length and loading times. What's wrong with using the babel box? I agree that it needs to be made more obvious how to get it of course. --Lydia Pintscher (WMDE) (talk) 10:57, 26 August 2013 (UTC)[reply]

To show me all labels and descriptions, I would have to put babels for all languages on my user page. This is impractical. Without them and without using the labelLister, there (possibly) is information on the item that I can't see or edit. This is inconvenient at least. When having a lot of babels, I'll get a long list of empty labels and descriptions at the beginning of the page. This is inconvenient again. What about building it like the sitelinks lists (i.e. showing all labels/description pairs for all languages one of them is actually there, and providing an "Add" link to add one that's not yet there)? This list could be collapsed by default, and the babel languages are additionally on top (not collapsed, not hidden if not existing). --YMS (talk) 12:22, 26 August 2013 (UTC)[reply]

What is kind of odd is that if one creates an item with Special:ItemByTitle and uses a wikipedia language other than the interface language, the item is created with an empty label in the wikipedia language as there is no way to complete this on creation. (Import interwiki can complete it) --  Docu  at 06:02, 27 August 2013 (UTC)[reply]

I discovered Special:SetDescription, Special:SetLabel, Special:SetSiteLink, and Special:SetAliases today (oddly, setAliases is plural as opposed to the others?). I don't know if they came in response to the above request, but I think it misses the point to have one page for each little thing on which we need to remember the Q number (something I know that the devs would like not to have us do), the language we want, and the thing to set. At the minimum these should be exposed on a particular item or property page (which btw these don't make it clear that the actions can be performed on properties), but I think that there are much better options that can probably be sculpted. --Izno (talk) 23:35, 11 September 2013 (UTC)[reply]

Add existing item reference to "Add links" URL on client[edit]

As of now "Add links" doesn't refer to exiting item on client after client compete initialization. --EugeneZelenko (talk) 14:26, 17 October 2013 (UTC)[reply]

I think this is a problem
  1. EugeneZelenko (talk) 14:35, 31 October 2013 (UTC)[reply]
Comment

Can you please explain what is happening in a bit more detail? I can't make sense of this at the moment. --Lydia Pintscher (WMDE) (talk) 13:25, 24 October 2013 (UTC)[reply]

See w:ru:Балашовское высшее военное авиационное училище лётчиков as example. Link after complete page loading is https://ru.wikipedia.org/wiki/%D0%91%D0%B0%D0%BB%D0%B0%D1%88%D0%BE%D0%B2%D1%81%D0%BA%D0%BE%D0%B5_%D0%B2%D1%8B%D1%81%D1%88%D0%B5%D0%B5_%D0%B2%D0%BE%D0%B5%D0%BD%D0%BD%D0%BE%D0%B5_%D0%B0%D0%B2%D0%B8%D0%B0%D1%86%D0%B8%D0%BE%D0%BD%D0%BD%D0%BE%D0%B5_%D1%83%D1%87%D0%B8%D0%BB%D0%B8%D1%89%D0%B5_%D0%BB%D1%91%D1%82%D1%87%D0%B8%D0%BA%D0%BE%D0%B2#. It even doesn't refer to Wikidata, not talking about item reference. --EugeneZelenko (talk) 14:30, 25 October 2013 (UTC)[reply]
This works as intended. You get the dialog. If you would like to go to the Wikidata item associated with the page check the "Data item" link in the toolbox section of the sidebar of that article. --Lydia Pintscher (WMDE) (talk) 16:25, 17 February 2014 (UTC)[reply]

site id codes[edit]

1. since commons has a separate section on the properties page, why don't we just fill in the commons project code automatically, when adding a new item there? it's annoying for a new user trying to figure-out or FIND the correct code to enter.

2. even though the basic wikipedia-by-language codes are fairly easy, once you've seen a few examples, it's STILL not something that we should expect new users to just "know", so it would be good if we made it easier in some way; a list like "hotcat" would be ideal, but it would be nice to at least have a handy, EASILY VISIBLE, link, or a collapsible menu, or etc...

Lx 121 (talk) 17:42, 17 October 2013 (UTC)[reply]

I think this is a problem
  1. signature
Comments

We will use the Commons section also for other wikis like meta that only have one link in the future. We'll therefore not spend time on changing this now. We will improve the site-code selection with the upcoming redesign. --Lydia Pintscher (WMDE) (talk) 16:30, 17 February 2014 (UTC)[reply]

Wrong number of sources in GUI[edit]

When I am adding a second source, the text in the UI changes from 1 source to 1+1 source. When I have finished it writes 2 sources. When I remove the first source, it still tells me 2 sources, until I reload the page.

I think this is a problem
  1. Not the biggest problem with the GUI, but I think it should be noted. -- Lavallen (talk) 10:06, 25 October 2013 (UTC)[reply]
  2. --Ricordisamoa 23:08, 25 November 2013 (UTC)[reply]
  3. Sounds kind of like the "back button" bug. --Izno (talk) 22:54, 27 November 2013 (UTC)[reply]

Looks like this is ✓ resolved. -- Lavallen (talk) 10:59, 4 January 2014 (UTC)[reply]

Clickable diffs[edit]

Tracked in Bugzilla
Bug 53471
Tracked in Bugzilla
Bug 58010

Sitelinks shown in the diff should be actual links; claims, references and qualifiers (for Item and Commons media file) should link to their target.

I think this is a problem
  1. Especially for admins, to check removed sitelinks. --Ricordisamoa 04:17, 27 August 2013 (UTC)[reply]
  2. --YMS (talk) 11:04, 28 August 2013 (UTC)[reply]
  3. Yeah, that would help. Ouch. --Littledogboy (talk) 12:33, 28 August 2013 (UTC)[reply]
Comments

Tobias has worked on this and a patch is in review at the moment. --Lydia Pintscher (WMDE) (talk) 13:18, 24 October 2013 (UTC)[reply]

But it is not fully resolved yet: bugzilla:53471#c3. --Ricordisamoa 23:30, 25 November 2013 (UTC)[reply]

Babel languages missing alias input[edit]

Tracked in Bugzilla
Bug 53344

By putting babel boxes on my user page, I get edit fields for labels and descriptions for those languages. However, aliasses are missing.

I think this is a problem
  1. --YMS (talk) 22:29, 23 August 2013 (UTC)[reply]
  2. --Izno (talk) 23:00, 23 August 2013 (UTC)[reply]
  3. --Sixsi6ma (talk) 16:02, 24 August 2013 (UTC)[reply]
  4. --Rippitippi (talk) 02:23, 25 August 2013 (UTC)[reply]
  5. --Tobias1984 (talk) 17:43, 26 August 2013 (UTC)[reply]
  6. (must be easy to fix) --Littledogboy (talk) 09:52, 27 August 2013 (UTC)[reply]
  7. -- LaddΩ chat ;) 01:10, 28 August 2013 (UTC)[reply]
  8. --Vyom25 (talk) 12:16, 4 September 2013 (UTC)[reply]
  9. --AVRS (talk) 15:17, 30 September 2013 (UTC)[reply]
  10. --Micru (talk) 23:47, 25 November 2013 (UTC)[reply]
  11. --Ricordisamoa 00:01, 26 November 2013 (UTC)[reply]

New interface - save button inactive after an alert has been displayed[edit]

Screenshot of issue reproduced October 9 with Chrome. More details on file description on commons.

I was unscrambling Wikipedia links between Q1642648 and Q2976556, moving a number of links from the first item to the second. As the move gadget isn't available any more, for each wikilink I manually delete it from its former item and add a new line in the new item. At some point, I hit Enter while editing the new item, which correctly displays a conflict alert as I have not yet saved my edits (removals) on the old item, so far so good.

Problem is, after I dutifully save my removals from the old item, there is no way to save the new item. The save link is blue, but after clicking it the Wikipedia section remains grey and is never saved. Even more of a problem, when I tried to open the unsaved page in a new tab and add all links again from scratch, the unsaved links in the "frozen" tab are visible but cannot be selected and copy/pasted, which is problematic when they are in alphabets I can't type such as Hebrew or Chinese.

Do you see any way to fix that? (I am a Wikidata administrator and my display language is French, it this makes any difference.) Place Clichy (talk) 13:21, 2 October 2014 (UTC) (Copied from Project chat)[reply]

Update: this seems to be a cross-browser issue. I had first had the issue with Firefox 32.0 (forgot to mention it) and I reproduced it today on Q7992609 with Chrome 37 (screenshot right). Place Clichy (talk) 09:53, 9 October 2014 (UTC)[reply]
  1. Place Clichy
  2. Pere prlpz. Copying comment: I'm not administrator and my display language is Catalan, but I'm experiencing the same issue, so status and language don't seem to make any difference.
  3. Liuxinyu970226 (talk • contribs • logs) I'm also too difficult to save. --Liuxinyu970226 (talk) 00:30, 4 October 2014 (UTC)[reply]

✓ Done This issue seems to have been fixed. Place Clichy (talk) 09:39, 5 December 2014 (UTC)[reply]

Statements for properties[edit]

Tracked in Bugzilla
Bug 49554

There are many external sources. They are all properties. It would be good to have a statement indicating that they are external properties so that tools like the Reseanator do not need to be changed for the latest sources that are added. As we have one use case for statements for properties, there are bound to be more. Thanks, GerardM (talk) 12:34, 18 October 2013 (UTC)[reply]

I think this is a problem
  1. GerardM (talk) 12:34, 18 October 2013 (UTC)[reply]
  2. Magnus Manske (talk) 13:13, 18 October 2013 (UTC)[reply]
  3. Micru (talk) 23:50, 25 November 2013 (UTC)[reply]
  4. Ricordisamoa 03:17, 26 November 2013 (UTC)[reply]
Discussion

Magnus started to use this ... https://meta.wikimedia.org/wiki/Reasonator/stringprops <grin> It would be better to have this in Wikidata itself GerardM (talk) 12:37, 18 October 2013 (UTC)[reply]

Just copy it where you want it, tell me where, and I'll point Reasonator there. --Magnus Manske (talk) 13:13, 18 October 2013 (UTC)[reply]

Merge tool doesn't move links[edit]

Tracked in Bugzilla
Bug 38664

Yes, I know it's a gadget and not a core Wikidata functionality, but I think it's a very important tool, and I don't care who fixes this serious gap in its functionality: If I merge two articles with the "Merge" tool, it does not fix the links to the now obsolete item to link to the recipient item. Moving all links manually can be quite an effort, and if it's not done by the user who merged the articles, often the admin deleting the obsolete item doesn't get it, too, leading to links to deleted items.

I think this is a problem
  1. --YMS (talk) 09:17, 26 August 2013 (UTC)[reply]
  2. --Sixsi6ma (talk) 09:46, 26 August 2013 (UTC)[reply]
  3. --Filceolaire (talk) 12:39, 26 August 2013 (UTC)[reply]
  4. TomT0m (talk) 12:42, 26 August 2013 (UTC)[reply]
  5. — Ayack (talk) 12:57, 29 October 2013 (UTC)[reply]

Comment

The maintainer of the tool has expressed that he is uncomfortable implementing a mass-change in his script, by the way. --Izno (talk) 15:43, 26 August 2013 (UTC)[reply]

that tool is must important to be a tool in my opinion it must be on wikidata core Rippitippi (talk) 17:56, 26 August 2013 (UTC)[reply]

Retrieved from "https://www.wikidata.org/w/index.php?title=Wikidata:Paper_cuts/Archive/2014&oldid=186267902"