Currently, no dedicated orientation existst regarding wording and phrasing in the Wikibase software. Strange enough that qqq messages refer to the Wikidata glossary while Wikidata, of course, is a project running Wikibase. The Wikidata glossary is maintained by the Wikidata community and does not necessarily reflect meanings expressed within the actual Wikibase software. A Wikibase glossary may also give hints to the maintainers of the Wikidata glossary about original intention of expressions and phrases.
Description
Description
Details
Details
- Reference
- bz70763
Related Objects
Related Objects
Event Timeline
Comment Actions
Not sure, I understand the question. I rather wonder why there has not yet been a Wikibase glossary. Some terms tend to be really specific (and, sadly, sometimes a bit off their native meaning, e.g. "Rank", "Qualifier"). No one knows the developers intention to use a specific term better than the developers. Why create confusion by having people maintaining the Wikidata glossary guess about developer intentions?
Not in any way arguing against a project specific Wikidata glossary, but a basic technical glossary should be maintained by the developers only, and be part of the actual software documentation. That glossary, off any project specifics, should be used to give hint to translators.
Even more, for users interested in using the Wikibase software, an "external" glossary is just not as reliable because it most likely contains project specifics.
Another use-case is standardizing wording and phrasing between developers in respect to the actual code and its interfaces.
In addition, there are terms that are not visible in the UI but via APIs etc. - e.g.: "Fingerprint".
Finally, maintaining a Wikibase glossary would, at least a tiny little bit, ease the process of changing a term/expression since the glossary may be used to reference back to deprecated terms and promote new terms.
Comment Actions
There is a glossary at https://www.wikidata.org/wiki/Wikidata:Glossary
It has existed from almost the beginning of the localization effort. It has although becoming a bit sloppy in some of the descriptions, it could need a cleanup.
A real problem with glossaries like this is that there is not one but several mental models, and they does not match up very well. You have the mental model of the developer which has his own idea which is often a very technical one. The you have the localization teams that tries to interpret the technical ideas in the local language, often with only the internationalized message as a clue to what the developer is trying to express. Then you have the actual user trying to interpret the localized messages, and often introducing his own (or her) own misinterpretations. To make the interpretations match up, and produce the same mental model, is a non-trivial task.
Add to this that Wikibase uses its own lingo that doesn't follow the usual semantic/linked data lingo, and you are in for some real problems.
Fix up the glossary, and use it while writing the messages and the descriptions. The descriptions are very important as they conceptualize the developers idea and lets the localization teams recreate their mental models. That reduce the chance for translation errors, thereby they will better communicate the correct mental model to the user.
Sorry, to long, just cleanup the glossary.
Comment Actions
There was a glossary at meta, and later on when the glossary at Wikidata was made I described some of the problems that would arise when when tha community built one glossary on their understanding and the developers had another. Typically the English messages will be written by the devs, and also a first version of the qqq-messages, but later on the community will start to change the qqq-messages to make them fit with their glossary, and the translators will also use the glossary while localizing the messages. That will make the English messages and the localized messages diverge somewhat.
I think the correct solution is to identify where this is a problem and try to align the models used by the devs and the community. If the models they use diverge it creates a lot of problems.
Comment Actions
We should not maintain our own but instead help get the community maintained one in better shape.
Comment Actions
@Lydia_Pintscher: Are you the Product Manager of Wikibase or Wikidata, of both or none of them?
Excuse me, but the decision to decline the ticket is a slap into the face of every third-party user of Wikibase and makes me challenge competence as there are fundamental reasons why there should be a dedicated Wikibase glossary.
When talking about "helping the community" -- a dedicated Wikibase glossary maintained by the developers is the best help that can be provided!
I have compiled a basic glossary here: https://www.mediawiki.org/wiki/User:Henning_(WMDE)/Wikibase/Glossary
Feel free to review or just bash me upfront.
Comment Actions
@Lydia_Pintscher Please elaborate on why this got closed as declined. @Snaterlicious' glossary seems like a good initial effort to this task. So why not build on top of this and commit to cleaning up the mess we've gotten into by not drawing a clear line between Wikidata and the Wikibase software it is based on?
Several Wikibase developers have repeatedly insisted on keeping a clear separation and made efforts towards it but management seems to still successfully ignore these voices and the fact that Wikibase has other potential use-cases than just Wikidata.