| Addshore added a comment. |
In T184000#3984789, @Tgr wrote:
- The parser function hook stores the argument of the parserfunction in the ParserOutput's page properties with a wikibase-description-override key.
So, this doesn't really have anything to do with wikibase, what we are adding here is a parser function to register an article description, that we want to be accessible via an API.
I agree with what @Alsee says that the description of the wikidata item and the description of the article can be and probably should be two distinct things.
- In PageTerms::execute go through the returned terms, and replace the descriptions with overrides when available. Rely on the PageProps class to do the caching.
- Maybe keep the Wikidata description and add it to the API result under a different name (wikibaseDescription? originalDescription?) so that old clients will automatically use the overrides while clients aware of what's going on can decide for themselves.
So, again overriding the current wikidata description here is a breaking change.
We should not do that.
If we want to add something new, such as an article description, lets add it under a new key called "article-description" instead of redefining something that already exists and has a clear definition.
- Modify the API help messages (only if overrides are enabled) to make clear what's happening. Not considered an API B/C break since clients still get a description, just from a slightly different source.
Again, changing what is under the description key is a break in compatibility in my eyes, the description key should remain the wikidata description for the item linked to the article. If we want to add other stuff, then sure.
In T184000#3986504, @daniel wrote:@Tgr Sounds like a decent plan. In an ideal world, the "short description" functionality would be factored out of wikidata, so it could be backed by *just* the magic word or *just* wikidata or both combined or something else. But that would of course break B/C. So I suppose modifying PageTerms is an OK solution. I agree that making TermSqlIndex aware of the override wouldn't be a good choice.
We could factor out the page terms stuff and not break B/C, just leaving the wikidata stuff where it is now and adding new keys for extra stuff. 'description' and 'article-description' could live side by side. One backed by wikidata and one backed by a magic word / parser function.
Instead of making the "original" description available in addition (which one is "original" anyway?) or indicating whether the description returned was overwritten, perhaps add a parameter for suppressing the override, forcing the use of the description from wikidata: disable-description-override or force-shared-description or something.
A param could be another route, something that would allow selecting of the source of the terms. options could be 'wikibase', or 'parser-overrides' or 'wikibase-fallback' etc with varying behaviours.
In T184000#3987276, @Tgr wrote:In T184000#3987260, @Alsee wrote:The Wikidata label is a description of the Wikidata item.
"Label" in Wikidata terminology is the article title (e.g. Q663375 has the English label "hatmaking" and English description "manufacture and design of hats and headwear"; there's a separate item for hatmaker).
This sentence is a bit misleading. "Label" in Wikidata terminology is nothing to do with 'article title'.
As written in the wikidata glossary "Label (also name) is the main name given to identify an entity".
So it is the term used to describe the concept of the item, but let's avoid the word article there to avoid any confusion.
In T184000#3985054, @TheDJ wrote:@Tgr I'm assuming no markup (like in wikidata). What about text length restrictions ? (I remember space in pageprops was limited??)
Markup should be removed, probably just by stripping HTML tags. page_props.pp_value is a blob (65K) but page terms are VARCHAR(255) so probably best limit it to that. (Not sure if there should be some kind of error message if it has to be truncated.)
The length of a wikidata description is actually currently 250 rather than 255 (as is in the db).
This can be found in Wikibase.default.php in Wikibase/repo/config
// Define constraints for multilingual terms (such as labels, descriptions and aliases). 'multilang-limits' => [ 'length' => 250, // length constraint ],
Cc: TheDJ, Fjalapeno, Mholloway, Tbayer, MZMcBride, Alsee, bearND, Mike_Peel, Tgr, JKatzWMF, daniel, Bmueller, Addshore, Lydia_Pintscher, Samwilson, Aklapper, DannyH, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, JJMC89, B20180, Nakon, MusikAnimal, Niharika, Fhocutt, Wikidata-bugs, aude, Ricordisamoa, -jem-, Mbch331, Krenair
_______________________________________________ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
