[01:43:05] What's the problem with one input argument? (re @Al: I fixed it (I think) but this is odd. There is only one input argument.) [01:44:57] That was the main issue, but I've just modified the composition to first convert to SI units (because some WD length values may be in miles or other length units), then to divide by 1000 because the test looks like it is expecting that the answer should always be in km. Is that correct, or would you prefer m? (re @Al: You need to pass the item, not just a reference to [01:44:57] it. This me [01:44:58] ans changing the function specification to expect a Z6001 rather t...) [02:16:38] I have no objection to any change until it's working well. (re @Al: I propose to change make pair (Z17534) to allow for either object to be a Quote (Z99). The new implementation is Z28472. I can f...) [04:50:07] that's intentional. it extracts the highest rank length property value [04:50:07] maybe it should be generic instead and accept the property reference as a second input? (re @Al: I fixed it (I think) but this is odd. There is only one input argument.) [04:51:31] I prefer SI units everywhere except display functions 😊 (re @u99of9: That was the main issue, but I've just modified the composition to first convert to SI units (because some WD length values may ...) [04:53:16] I found that tests consistently fail after changing the input type. [04:53:16] Is that a known bug? [04:53:18] It leads to me creating new tests and old ones should be deleted= more work for admins [05:15:47] So you want the output of your test Z28480 to be 340000? I'd welcome everything being changed to SI, but was just following your lead. (re @Npriskorn: I prefer SI units everywhere except display functions 😊) [05:17:10] If the function signature changes, then the test need to change. But you can change them without making new ones and deleting the old ones. (re @Npriskorn: I found that tests consistently fail after changing the input type. [05:17:10] Is that a known bug? [05:17:12] It leads to me creating new tests and o...) [06:23:35] It’s not a problem. I was confused by the input label being the same as the type 🙄 (re @u99of9: What's the problem with one input argument?) [06:47:24] The function can now be used for types with converters to code, if the object is quoted (pair with quoted object unquoted `Z28487, `for example). (re @u99of9: I have no objection to any change until it's working well.) [06:57:04] I think it was fine, I was just confused. 😵‍💫 (re @Npriskorn: that was intentional. it extracts the highest rank length property value. [06:57:06] maybe it should be generic instead and accept the pro...) [08:38:33] Oh, I realised that maybe you consider km to be SI enough. That may suit your other function well. Eventually we may make another parallel function returning m. (re @u99of9: So you want the output of your test Z28480 to be 340000? I'd welcome everything being changed to SI, but was just following you...) [08:48:44] Maybe the interface function should retain the Wikidata units and a function expecting a particular unit/denomination could orchestrate the conversion? (Read – convert – calculate) (re @u99of9: Oh, I realised that maybe you consider km to be SI enough. That may suit your other function well. Eventually we may make anothe...) [08:51:24] Yes I am planning a general convert function. That sounds like a good structure once it's available. (re @Al: Maybe the interface function should retain the Wikidata units and a function expecting a particular unit/denomination could orch...) [09:00:30] Are we blocked by the Type proposals, or can we just do, say, length for starters? (And please may we call them “metres” for “en”, reserving “meters” for en-us?) (re @u99of9: Yes I am planning a general convert function. That sounds like a good structure once it's available.) [09:25:07] There's no block to my plan that I'm aware of, but I also don't think that length is any easier than all units in general. I'm not sure what you mean by the label. It will be something like convert(quantity, new_unit_qid) (re @Al: Are we blocked by the Type proposals, or can we just do, say, length for starters? (And please may we call them “metres” for “en...) [09:26:51] It will need to grab the SI conversions from both the existing and new units, then do some fancy precision stuff. But I imagine we can reuse a lot of the helper functions from Z25999 [09:29:53] Wonderful! I’ll gladly leave the “fancy precision stuff” to you, but I’m happy to help in other ways. (re @u99of9: It will need to grab the SI conversions from both the existing and new units, then do some fancy precision stuff. But I imagine ...) [09:43:16] I meant generally. Z28392 is using “meters” and “kilometers”. Maybe unit symbols are generally preferable, but the full term, where used, should follow en:Wikipedia (main article) usage? (re @u99of9: There's no block to my plan that I'm aware of, but I also don't think that length is any easier than all units in general. I'm n...) [10:30:12] I'm thinking we are going to need a display function or helper function for wikivoyage use at dome point and that can be tailored to their needs. e.g to output km in the right language in a blob of html (re @u99of9: Oh, I realised that maybe you consider km to be SI enough. That may suit your other function well. Eventually we may make anothe...) [10:31:29] nope, doesn't work AFAICT (re @u99of9: If the function signature changes, then the test need to change. But you can change them without making new ones and deleting th...) [10:34:55] It should do. Generally has. Do you have an example that fails? (re @Npriskorn: nope, doesn't work AFAICT (I can edit but none of them have passed)) [10:38:19] ok, I'll stop creating redundant tests and write here instead if it happens again (re @Al: It should do. Generally has. Do you have an example that fails?)