Amire80 added a comment.
Not sure where is the good place to put my feedback of this kind... I'll put it here as a comment, but if there's a better place let me know. TLDR: 1. The need to view edit a //whole// item every time is a practical problem. It is often useful, but not always. It is this paradigm that has to be addressed before discussing the web development frameworks used to implement it. 2. Wikidata is too generic as a data entry and storage mechanism, and it leaves all customization and tailored processing to external tools, which are too diverse and unstable in practice. In more detail: A general problem with both Wikidata and its Lexeme feature is that it provides a rather feature-rich data entry mechanism, but it's too generic and not targeted at particular types of data. It's also oriented more at data entry than at data display. Wikidata developers' response to this usually goes along the lines that in their vision, Wikidata is a generic data storage, whereas tailored solutions for adding and displaying particular types of data should come through other tools. It's a sensible response, but it doesn't really solve the problem. The current world of Wikidata tools has a lot of engineering brilliance, but it's also a bit too "wild wild west" — the tools have strange names, I always find it difficult to find the tool I need, their UI design and usage styles are too diverse, their localization is not done according to Wikimedia's standards, they are unstable and often get neglected and broken, and so on. Of course, they do have many dedicated users, but evidently, this doesn't scale as much as it could. If Wikidata developers don't want to make Wikidata too complex by filling it with too many features for particular narrow use cases, they could address this problem by developing a richer library for tool developers, which would promote stability and uniformity. Another consequence of the "generic data storage and entry" paradigm is that Wikidata doesn't have its own mechanism for convenient adding of multiple pieces of data. Just to enter a small piece of data, the user has to open a whole editing form for an item or a lexeme, and to enter it for several similar items, the user has to open multiple browser tabs, sometimes dozens. The most obvious example of this problem is translation of multiple labels (T64695 <https://phabricator.wikimedia.org/T64695>). Translation of multiple lexemes is another. It's also a huge missed opportunity for mobile contributions: translating short labels or lexemes with a convenient UI could drive literally millions of quick contributions, especially from very diverse countries and languages where desktop usage is low. For translating the software UI, we've had translatewiki since 2006, which became even better designed for translating multiple strings in 2012. It's well integrated with MediaWiki and successfully used by thousands of people, and a similar paradigm could also be used for Wikidata (although I'll readily admit that it's not nearly as good on mobile devices as it could be). People recommend that I use Tabernacle or some other tool for doing multiple translations, but I never had any success with it—I found it confusing, unstable, and not integrated with the MediaWiki UI. A frequent, but wrong piece of criticism of Wikidata design is that it has tight forms replacing the ultra-loose format of wiki pages. Some Wikipedians criticize it as being too tight and too different from wiki pages, to the point of "not being a wiki at all". This is wrong: a wiki is not necessarily a website with a huge blank textarea that has to be filled by free-form markup, but a website that anyone can edit, and Wikidata is very much a wiki in this sense. It's the need to edit a whole item every time that is the problem. TASK DETAIL https://phabricator.wikimedia.org/T272203 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Amire80 Cc: Amire80, So9q, Akuckartz, Nandana, Lahi, Gq86, GoranSMilovanovic, Mahir256, QZanden, LawExplorer, _jensen, rosalieper, Bodhisattwa, Scott_WUaS, Wikidata-bugs, aude, Mbch331
_______________________________________________ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
