Page MenuHomePhabricator

Unify and make easy the editing of labels list
Closed, ResolvedPublic

Description

Editing of labels list is needlesly disunited to 3 places and the edit tools are needlesly different and uncomfortable. Some ideas for improvement:

  • Add "aliases" fields to the "In other languages" section
  • Enable to expand "In other languages" section to all languages (as a drop-down table - clickable + or arrow), or by the user preferences).
  • The "labels list" bookmark will be redundant (this edit tool looks a bit semi-finished anyway).

Version: unspecified
Severity: enhancement
Whiteboard: aklapper-moreinfo

Details

Reference
bz59152

Event Timeline

bzimport raised the priority of this task from to Needs Triage.Nov 22 2014, 2:38 AM
bzimport set Reference to bz59152.
bzimport added a subscriber: Unknown Object (MLST).

Hi, which problem would you like to solve? Please describe specific problems in bug reports. So far this ticket seems invalid to me as it does not clearly describe a problem, but offers some potential solutions.
Plus "make easy" is nothing that can be checked as the term is subjective.

The problems are described above. The administration of labels list is unsystematic, needlessly disunited, illogical and clumsy.

  • The edit form at the item page is incomplete (doesn't display aliases, doesn't display all languages, is not available defaultly for all users).
  • The edit form at the "labels list" bookmark is an unfinished provisional makeshift and is not capable for real effective workflow, its editing is escessively complicated and bothering still (the edited language have to be filled in the additive window instead selected in the table, every change is edited in a special window instead in the table, thus a mass improving or correcting of all labels or alliases is approximately 3-times or 4-times more arduous than it may be - which really and objectively causes that users are forced to give a damn about maintain labels.

Using subjective buzzwords like "needlessly", "real effective workflow" or "escessively complicated" don't help at all if you want to make a valid case. See https://www.mediawiki.org/wiki/How_to_report_a_bug
Personally I consider this report invalid as it still does not describe a problem but only potential solutions. Anyway, I'll leave it to Wikidata developers to decide whether this is a valid request.

Effectiveness, complicatedness and uselessness are relatively objective characteristics, especially when the problems are described (in detail and even twice). The fact that any step (as well as set of such steps) requiered manytimes more clicks than would be necessary is not very subjective. IMHO also the fact that at the item page, aliases cannot be edited at the same place where labels and descriptions can, is objective, etc. Even when you would have opposite needs, preferrences or oppinions, you should be able and ready to understand objective problems of the software.

However, when the developers tend to ignore all problems and to negate and refute all feedback instead to search, detect, reflect and solve them, the outputs correspond to such attitude. To label such bugs as "invalid" is a bit unambitious and unconstructive, at least.

I am going to mark this as a dupe for the UI redesign. We will keep it in mind for that. The current situation is indeed not ideal.

  • This bug has been marked as a duplicate of bug 52136 ***