On Wed, 29 Jul 2020 at 11:11, Luca Martinelli &lt;martinelliluca(a)gmail.com&gt; wrote: Not quite. The current design calls for there to be three different forms of human-readable text, with different availability depending on the type of ZObject: All ZObjects will have a "*label*", which will be a set of short textual identifiers, up to one per supported language, shown as the "title" of the page and used in most places aimed at humans using them. On https://meta.wikimedia.org/wiki/File:Wikilambda_early_mockup_multiply_funct… this is "multiply" or "multiplizieren" or whatever depending on your view language, as shown at the top of the content, ahead of the ZID (Z2303 in the example). In combination with the 'type' of the ZObject, this is enforced to be unique in a given language (so you can have a 'multiply' function defined that works on two integers and responds with an integer, and another that works on hypercomplex numbers (or matrices or Game of Life implementations or…), but you can't have two that work on the exact same input/output types. (Note: The current design doesn't have alias support, which Wikidata does.) ZObjects which are function definitions (ZFunctions), and so may need a lot of documentation and information sharing for people to know how to use it, to expand it, to add new tests, or to add new implementations, will have a fully-featured *wikitext description* blob/set of blobs, for detailed documentation. These will be the main human starting points and work co-ordination places, so need a lot of the things our communities have come to expect – links, templates, categories, *etc.*. On https://meta.wikimedia.org/wiki/File:Wikilambda_early_mockup_multiply_funct… this is "en:Multiplication is a mathematical…", as shown below the calculated type. ZObjects which don't have wikitext description instead have a short, non-wikitext *description* field, again at a maximum of one per supported language, like how Wikidata works. On https://meta.wikimedia.org/wiki/File:Wikilambda_early_mockup_multiply_recur… this is "Calculates the sum of multiplicand …", as shown below the calculated type. I don't know. Maybe everything could just be done through talk pages? J. -- *James D. Forrester* (he/him <http://pronoun.is/he> or they/themself <http://pronoun.is/they/.../themself>) Wikimedia Foundation <https://wikimediafoundation.org/>

‫בתאריך יום ד׳, 29 ביולי 2020 ב-13:11 מאת ‪Luca Martinelli‬‏ <‪ martinelliluca@gmail.com‬‏>:‬ "Description" in Wikidata is a misnomer. It should have never been called "description". It should have been called a "disambiguator", which is its real purpose. The name "description" caused developers of several apps and extensions to actually use them as summaries in search results, which in turn caused the Wikidata-suspicious English Wikipedia community to ask for the weird {{short description}} feature to override the Wikidata "description" (and to top things off, some people are now thinking of undeploying the {{short description}} feature). It also caused some Wikidatans to start thinking of some very technical syntax for writing descriptions. I don't remember particular examples, but I do remember debates about writing very technical, tight descriptions for biological species. Which is supposed to be very pointless, because, um, Wikidata has properties for structured data. Denny can correct me, but my memory tells me that Wikidata descriptions were made just for disambiguation, like the parentheses part in "Georgia (U.S. state)" and "Georgia (country)" in the English Wikipedia. They were made for items that have a label that is identical to the label of another item. They have always been supposed to be super-simple, optional and not even necessary in most items. Documentation for code is completely different. It is needed more or less always, it can be long, and it often needs rich formatting. So it should probably allow real wikitext, as Denny suggests. If I understand correctly, Wikilambda function are kind of similar to templates and modules. Simpler templates have their documentation in the templates page itself, and the more complicated ones have it in a /doc supbage. Templates can also have a bit of documentation in the TemplateData description, but this is not supposed to be comprehensive (and if I understand correctly, functions probably don't need something like TemplateData because according to the current plan, Z Objects will provide similar functionality in a more structured way). Scribunto Modules are not wikitext, and they always have their documentation in a /doc subpage. If functions do something similar on a /doc subpage, it will be totally fine, at least as a start. Occasionally there are suggestions to move TemplateData and template and module documentation to MCR slots, and this is probably fine, but optional.

Amir, “some people are now thinking of undeploying the {{short description}} feature” Who? Where is this being discussed? I am not sure what you mean by “undeploying the feature” Agree that it was a badly handled problem and massive time-sink, but would prefer that the baby is not thrown out with the bathwater. Cheers, Peter From: Abstract-Wikipedia [mailto:abstract-wikipedia-bounces@lists.wikimedia.org] On Behalf Of Amir E. Aharoni Sent: 29 July 2020 12:54 To: General public mailing list for the discussion of Abstract Wikipedia (aka Wikilambda) Subject: Re: [Abstract-wikipedia] How to store wikitext along the structured content? ‫בתאריך יום ד׳, 29 ביולי 2020 ב-13:11 מאת ‪Luca Martinelli‏ <‪martinelliluca@gmail.com‏>: On Tue, 28 Jul 2020, 23:27 Denny Vrandečić, &lt;dvrandecic(a)wikimedia.org&gt; wrote: Hello all, one early question we are currently debating is how to store Wikitext documentation alongside with the structured data? So, the label of the page and aliases and the actual content object are stored as JSON, but then we would like to have the documentation be more or less normal wikitext. (...) The text "en:Multiplication is a mathematical operation that...", that's just wikitext. And it is different per language. (...) So, if I get it right, that wikitext is basically the equivalent of a Wikidata item description. Allow me to play dumb ("play"... heh), and ask: do we really need that description to be wikitext or do we want it to be similar to a Wikidata item description (i.e. similar to a caption)? "Description" in Wikidata is a misnomer. It should have never been called "description". It should have been called a "disambiguator", which is its real purpose. The name "description" caused developers of several apps and extensions to actually use them as summaries in search results, which in turn caused the Wikidata-suspicious English Wikipedia community to ask for the weird {{short description}} feature to override the Wikidata "description" (and to top things off, some people are now thinking of undeploying the {{short description}} feature). It also caused some Wikidatans to start thinking of some very technical syntax for writing descriptions. I don't remember particular examples, but I do remember debates about writing very technical, tight descriptions for biological species. Which is supposed to be very pointless, because, um, Wikidata has properties for structured data. Denny can correct me, but my memory tells me that Wikidata descriptions were made just for disambiguation, like the parentheses part in "Georgia (U.S. state)" and "Georgia (country)" in the English Wikipedia. They were made for items that have a label that is identical to the label of another item. They have always been supposed to be super-simple, optional and not even necessary in most items. Documentation for code is completely different. It is needed more or less always, it can be long, and it often needs rich formatting. So it should probably allow real wikitext, as Denny suggests. If I understand correctly, Wikilambda function are kind of similar to templates and modules. Simpler templates have their documentation in the templates page itself, and the more complicated ones have it in a /doc supbage. Templates can also have a bit of documentation in the TemplateData description, but this is not supposed to be comprehensive (and if I understand correctly, functions probably don't need something like TemplateData because according to the current plan, Z Objects will provide similar functionality in a more structured way). Scribunto Modules are not wikitext, and they always have their documentation in a /doc subpage. If functions do something similar on a /doc subpage, it will be totally fine, at least as a start. Occasionally there are suggestions to move TemplateData and template and module documentation to MCR slots, and this is probably fine, but optional. L. _______________________________________________ Abstract-Wikipedia mailing list Abstract-Wikipedia(a)lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/abstract-wikipedia <http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient> Virus-free. <http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient> www.avg.com

Clearly, if there is a definite demand for scraps of human-readable text attached to things, some people will spend time arguing that the consumer is always wrong in these situations. Just as, if you point out that it provides another way to search, they will argue that people don't, can't or shouldn't search in such ways. I feel there are fallacies lurking here, or anti-patterns, and would be happy to have names for them. Charles

Since my considered response to the over-aggressive rationalisation inherent in tech planning involves an appeal to the principles of Marie Kondo sorting, I fear I may be misunderstood. It would not be the first time. Charles