[03:30:05] I updated the qqq to the best of my understanding: https://translatewiki.net/w/i.php?title=Special:Translate&showMessage=wikilambda-special-functionsbytests-summary&group=ext-wikilambda-user&language=nl&filter=&optional=1&action=translate&uselang=nl (re @vrandecic: @amire80 is there a way to mark messages as draft messages, to spare volunteers from working on [03:30:05] messages that are still being fi...) [03:32:51] I'm linking to Dutch for a specific reason: The WikiLambda extension is 100% translated into it, so you can see how translators see it when everything is translated. In case you aren't familiar with how qqq is shown to translators, just put your mouse cursor at the "Introductory summary for the..." area on the right-hand side. [03:33:19] It's longer than qqq usually is, but that's a long message that refers to a lot of other messages 🤷🏻‍♂️ [03:33:55] Also note that the translator just copied all the text in the tags as is, without translating :( [03:34:37] (Possibly because he thought that text within tags shouldn't be translated, which is often right, but most likely wrong in this case.) [03:46:08] So anyway, I updated the qqq, but: [03:46:09] 0. Someone should verify that I did it correctly. [03:46:11] 1. There are several messages that are not the same as their quotation in the long message, so perhaps someone should make them consistent. [03:46:12] 2. Perhaps should be replaced. [03:49:34] Bonus: If you want to make everything extra-comfortable for the amazing volunteer translators, move the long message in en.json a few lines down, so that it would appear after all the messages that it mentions. This way, the translators who translate all the messages in sequence, which is what happens most of the time, will see the documentation with translated [03:49:34] messages. (I'd do [03:49:35] it myself, but I prefer not to touch the code myself now, given that it's likely to change.) [03:49:55] In the link above? (re @amire80: So anyway, I updated the qqq, but: [03:49:56] 0. Someone should verify that I did it correctly. [03:49:57] 1. There are several messages that are not ...) [04:05:41] Yes. The English message and the Dutch translation are on the left. I didn't touch them. The message documentation ("qqq") is on the left. I set the user interface language to Dutch to demonstrate how the message documentation looks like when everything is translated. (re @cvictorovich: In the link above?) [04:07:20] (When other messages are quoted in the documentation, they are shown in the user interface language, if someone already translated them. Perhaps it would make more sense to show them in the language into which the user is currently translating, but I don't think that there's a good way to do it.) [04:38:08] I'd like to make sure everything is discussed and agreed upon on [[WP:TP/DoRY]]. I've put 5 questions and 18 options (though I'm open to more) on there to start a discussion, from what I thought would be the most controversial points that we'd want to discuss out based off of the post-launch reaction for Rational Number and Gregorian Year. Please do comment on [04:38:08] there. Thanks! [04:38:38] [[WF:TP/DoRY]], sorry! (re @wikilinksbot: [[WP:TP/DoRY]]) [11:57:48] Also, I made type converters for Day of Roman Year, Z20236, Z20336, Z20337, Z20338. [13:27:39] And, @vrandecic, I'd like to recommend Z20181, Z20290, or Z20302 for Function of the Week, if you don't already have one picked. [13:28:43] The first one is a simple but common and necessary question for the Gregorian year type, the bottom two are unique, and also chain together 2 calendar related types [14:11:18] Maybe add suggestions to [[Wikifunctions:Function_of_the_Week#Suggest_your_own_Function_of_the_Week]]? Z10996 is already a suggestion, so we might look at that with Z20181 in the same week. (re @Feeglgeef: And, @vrandecic, I'd like to recommend Z20181, Z20290, or Z20302 for Function of the Week, if you don't already have one picked.) [14:15:03] That page hasn't been edited in 1.5 months, so I don't think it's being updated (re @Al: Maybe add suggestions to [[Wikifunctions:Function_of_the_Week#Suggest_your_own_Function_of_the_Week]]? Z10996 is already a sugge...) [14:15:42] yeah, my bad, I should really be updating it and I keep forgetting to do so, when we publish the status update [14:15:53] will do so as soon as I can [14:16:57] Please comment here Al GrounderUK. (re @Feeglgeef: I'd like to make sure everything is discussed and agreed upon on [[WP:TP/DoRY]]. I've put 5 questions and 18 options (though I'm...) [14:18:10] I'd imagine we feature the Gregorian year type one primarily (re @Al: Maybe add suggestions to [[Wikifunctions:Function_of_the_Week#Suggest_your_own_Function_of_the_Week]]? Z10996 is already a sugge...) [14:19:31] I’ll get to it eventually 👍 (re @Feeglgeef: Please comment here Al GrounderUK.) [14:43:24] This is a good idea, but I worry it's infeasible. The code executors (by necessity) have limited information about ZObjects. They know how to type-convert certain built-ins, and they know how to type-convert the things that they are explicitly told about (i.e., types with custom converters, which pass that information from the orchestrator to the evaluator). For the general case, we can't always know what a well-formed [14:43:24] canonical Wikifunctions object is--at least, not in the executors. The current solution is to use a specific type called `ZObject` for the general case, and to treat map-like objects (which unfortunately double as JSON representations) as Typed Maps. We could reverse this situation, of course. Or we could do some type-hint annotation kind of thing. In any case, it seems cleaner for function implementers to control the [14:43:24] return type explicitly, rather than depending on some complex and brittle magic built into the executors. BUT! I am willing to be corrected on this. (@Al: We should probably return only objects with identifiable types. A typed map seems like a good choice if the object is not a well-formed Wikifunctions object. We might consider supporting the return of a Wikifunctions object in canonical form, but that might be a [14:43:24] specific custom type.) [15:40:21] No, I think we agree. When I said “with identifiable types”, I meant that we should not have to handle arbitrary JSON objects unless that is the function’s return type. But in the case of Z1, returning a typed map is probably a better option than raw JSON. But… if we do decide to support an explicit JSON object type, we should probably distinguish between Wikifunctions JS [15:40:21] [15:40:21] ON objects and arbitrary JSON (as different specific types, presumably). My inclination would be for Wikifunctions objects to be returned either quoted or reified. Having “live” objects popping out of function calls makes me nervous. (re @wmtelegram_bot: return type explicitly, rather than depending on some complex and brittle magic built into the executors. BUT! [15:40:21] I a [15:40:23] m will...) [15:42:24] Okay, makes sense! As I said, the default type conversion very much leaves room for improvement, so feedback is welcome. [21:06:31] Z20342 has been created as a new type [21:08:36] Apologies, I didn't wait for this conversation to gather consensus. Most of the questions can be fixed post-launch of the type. The only thing that's pretty hard to change would be to change the natural number for the day to an integer, but I am really queasy about -3 of January. I understand it would have benefits for certain implementations, but the amount of [21:08:36] magic happening in [21:08:36] the converters is getting scary. (re @Feeglgeef: I'd like to make sure everything is discussed and agreed upon on [[WP:TP/DoRY]]. I've put 5 questions and 18 options (though I'm...) [21:36:57] Is the type/week thing expected to continue or is it only for these few cases? (re @vrandecic: Z20342 has been created as a new type) [22:41:23] For what it’s worth, I would not support negative or zero days “in” or “of” a month. (re @vrandecic: Apologies, I didn't wait for this conversation to gather consensus. Most of the questions can be fixed post-launch of the type. ...) [22:42:24] Negative for sure I disagree with. I think 0 should be included though, I think it can serve useful purposes, despite not really existing. [22:45:03] 🤷‍♂️ I can’t think of one. (re @Feeglgeef: Negative for sure I disagree with. I think 0 should be included though, I think it can serve useful purposes, despite not really...) [22:46:43] It can represent the bridge between 2 months in a few contexts [22:50:13] I don’t see more of a “bridge” between two months than between two days in the middle of a month. [22:51:26] Sure, but it can mean that, so I don't think we should restrict it just because we can. [22:52:08] one type doesn’t have to mean everything you can possibly think of [22:52:52] The reason for restricting it would be that it has no meaning. (re @Feeglgeef: Sure, but it can mean that, so I don't think we should restrict it just because we can.) [22:53:29] It can mean something in some contexts, so we should still support it. (re @Al: The reason for restricting it would be that it has no meaning.) [22:55:45] I’m not sure it can, but if it can, I still don’t see a reason to support it. (re @Feeglgeef: It can mean something in some contexts, so we should still support it.) [23:02:30] I've made a function that should be really useful for this, Z20367. Functions for trivial cases should be created, like next day and day before, as well as functions that accept natural numbers to go forward or backward (re @vrandecic: Z20342 has been created as a new type) [23:22:07] Please add a description. That label is non-obvious to me. (re @Feeglgeef: I've made a function that should be really useful for this, Z20367. Functions for trivial cases should be created, like next day...) [23:22:42] I don't know how to describe it (re @Toby: Please add a description. That label is non-obvious to me.) [23:22:47] other than "moves N dates" [23:23:32] I suppose "Adds integer to Day of Roman Year" [23:24:06] I'll have a go then. I've tested it and understand the aim now. (re @Feeglgeef: I don't know how to describe it) [23:24:18] Ok. Thanks! [23:32:01] Z20372 is failing because of weird stuff with 0 [23:32:50] What's the intent if we try to add 1000 days or something? Or even 100 days going *into* a leap year. It's unclear what should happen since we don't specify which of the following years will be leap years. (re @Toby: I'll have a go then. I've tested it and understand the aim now.) [23:33:39] I suppose it guesses that all of them are? [23:33:48] Personally, I don't think I'll use a function like this until it has an actual year attached. [23:33:59] It's moduloing 366 [23:34:07] all of them are leap years??? Oh dear... (re @Feeglgeef: I suppose it guesses that all of them are?) [23:35:13] Jan 1st, True, 732 gives Jan 1st (re @Toby: all of them are leap years??? Oh dear...) [23:36:07] I suppose we could just take a year as an input and compute what would be leap years from that? But that would be something for a date type to do. [23:36:51] Actually, I'd imagine these count as year-independent, so that kinda makes sense? (re @Toby: all of them are leap years??? Oh dear...) [23:37:10] Yes, this function would work better with a date type including the year. (re @Feeglgeef: I suppose we could just take a year as an input and compute what would be leap years from that? But that would be something for ...) [23:37:19] I don't understand. (re @Feeglgeef: Actually, I'd imagine these count as year-independent, so that kinda makes sense?) [23:38:10] They don't have a year attached, so could be thought of as existing all in the same year, thus if it were a leap year once it would be a leap year again. (re @Toby: I don't understand.) [23:39:32] I've fixed this in a dependency function, it should pass if a dummy edit is made. (re @Feeglgeef: Z20372 is failing because of weird stuff with 0) [23:40:48] ✅ (re @Feeglgeef: I've fixed this in a dependency function, it should pass if a dummy edit is made.) [23:42:08] Perhaps we add that to the description for the type? That all days are though to exist in the same year, but that can be any year or none at all?