[01:16:23] I've done a test of this. I repeated a spacer 10 times in a row, then repeated a complex sentence 10 times in a row. After running both for an initial time, then after reload, both sections took approximately 20 seconds to render. So, I suppose the cache is working, but 2000ms seems extremely slow for each cache hit. Is there some major network travel involved? (re@u99 [01:16:23] of9: If so [01:16:25] , reloading a complex sentence would take a similar time to a sentence spacer!) [01:57:44] T427463 (re @u99of9: I've done a test of this. I repeated a spacer 10 times in a row, then repeated a complex sentence 10 times in a row. After runni...) [05:48:10] In preparation for displaying images, I'm looking at typical image captions on wiki, and many of the captions I've seen could be roughly covered by a form "X [at/in Loc] [on/in DMY]". But either of the latter arguments are sometimes not included. What's our best practice for functions receiving empty/optional arguments? Or do I need to write multiple functions for all [05:48:10] combination [05:48:11] s of parameters left out? [07:49:31] We will also need an answer to this for good referencing functions, because citations often come with various combinations of fields filled out. (re @u99of9: In preparation for displaying images, I'm looking at typical image captions on wiki, and many of the captions I've seen could be...) [08:29:15] I don’t know about “best” practice, but I’d be thinking about a typed list of typed pairs, which may or may not be a typed map. The keys could be an enumeration but the type for the corresponding value would not be set by its selection, so that’s a feature worth considering. But we could also have separate enumerations by type, so the user first chooses to add a list/ma [08:29:15] [08:29:16] p of date-attribute pairs, say, and then selects the attribute(s) from the enumeration. Captions are mentioned in *T423445* but I don’t see them in the design video. (re @u99of9: In preparation for displaying images, I'm looking at typical image captions on wiki, and many of the captions I've seen could be...) [08:42:40] In my quest to remain ignorant of typed pairs, would this be okay: ask for three arguments, each a list of the type I want, then consider an empty list to be not supplied, and a one element list to have the value I want? (Throw away subsequent elements, or consider multiple subjects/locations/dates.) (re @Al: I don’t know about “best” practice, but I’d be thinking [08:42:40] about a [08:42:41] typed list of typed pairs, which may or may not be a typed map. ...) [09:06:26] It’s “okay-ish” if the attributes are 0..1, but that’s not an assumption I would make any more than I would assume that there are three (or 0..3) arguments. 🤔 (re @u99of9: In my quest to remain ignorant of typed pairs, would this be okay: ask for three arguments, each a list of the types I want, the...) [09:10:16] If I understand the word 'attributes' then we normally require exactly 1. Yes, I'm trying to optionally leave it blank. But yes I see that yours permits almost unlimited structural options. [09:17:39] Actually my just doesn't really stop anyone sending or using more items. The main constraint is the number of arguments and their types. Which I think is exactly what I want to constrain for an caption(Q,L,D) (re @u99of9: If I understand the word 'attributes' then we normally require exactly 1. Yes, I'm trying to optionally leave it blank. But yes ...) [09:29:51] The subject may be a Wikidata item, or several, or a descriptive identification (a function call?). The location may be a Wikidata item, co-ordinates, descriptive. The date (of what?) might be a time or an approximation. What about the creator or publisher? And for an image of an image…? (re @u99of9: Actually my list doesn't really stop anyone sending or using more items. [09:29:51] The m [09:29:52] ain constraint is the number of arguments and thei...) [09:33:43] Yeah, maybe it’s just a list of functions calls 😮 (re @u99of9: Actually my list doesn't really stop anyone sending or using more items. The main constraint is the number of arguments and thei...) [09:45:51] True. My initial thought was not to try to cover every possible caption, just to make a simple function that gives a decent caption for the ~30% of captions that match that form. (re @Al: The subject may be a Wikidata item, or several, or a descriptive identification (a function call?). The location may be a Wikida...) [09:47:31] The more complex I make it, the more complex it will be for translators to map it into their language. [09:54:59] True. But if we handle each dimension/attribute separately, the only natural-language variation would be the sequencing and connection of the components. It’s just a micro-article, in other words: a subsection spanning several function calls. (re @u99of9: The more complex I make it, the more complex it will be for translators to map it into their language.)