Lydia_Pintscher added a comment. In https://phabricator.wikimedia.org/T97566#1262380, @Deskana wrote:
> In https://phabricator.wikimedia.org/T97566#1259794, @Lydia_Pintscher wrote: > > > It is not just about the time of my team. It is about the effort we're > > putting on the community as well to maintain this information on all items > > when it is only needed on a very small number of them. > > > I'm not sure I understand this. If an item doesn't need this information, > then it can simply not be added. No extra maintenance needed. If an item does > need this information, then it's already been added to the description, so > there is also no extra maintenance needed. An additional empty field on nearly every items means: - more mental attention required to figure out what it is and does - more clutter on item pages drawing away attention from the things we want people to care about - more pieces that need patrolling for vandalism and spam > > If we're adapting Wikidata's api to also provide a sanitized description or > > leave it to the client either way we need to have a discussion in the > > community to agree that "anything in brackets can be stripped" is ok and > > can be agreed upon as an editing standard. I'm happy to do that. > > > Right. This is why I suggested the API providing both descriptions, then the > consumer can choose which they like. For example, the PageTerms module > already provides some support for this. For example, > > https://en.wikipedia.org/w/api.php?action=query&titles=Jellyfish&prop=pageterms&wbptterms=description > > This query provides //only// the description, unsanitised. It could continue > to do so, for backwards compatibility. You could add support for, say, > wbptterms=sanitisedescription, which provides a sanitised description. > > > Which of those two to chose for me depends on if we believe most clients > > will need the stripped version or if they don't care. I don't know to be > > honest. The biggest usecase of descriptions for 3rd parties is tagging and > > there you'd want the full descriptions. > > > Right. I don't think any of us know that right now. The advantage of the > above solution is that it's totally backwards compatible. I've just talked this through with Daniel and he made a good point. Wikibase as a software shouldn't know about this convention because other wikis using the software are free to use completely different conventions. So it should go into the client that needs it from our side. TASK DETAIL https://phabricator.wikimedia.org/T97566 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Lydia_Pintscher Cc: Jdforrester-WMF, Pigsonthewing, Tfinc, Deskana, Mhurd, Lydia_Pintscher, Aklapper, kaldari, Wikidata-bugs, aude _______________________________________________ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
