[03:00:44] Personally I'm not working on anything with floating point answers until we get the type. It's too much of a hassle to convert the function once the type is available. [05:11:43] Hm. Do you know the estimated time frame on that type being available? [05:11:43] Is it in the current sprint? (re @Toby: Personally I'm not working on anything with floating point answers until we get the type. It's too much of a hassle to convert t...) [05:18:28] Hm. Given "as per ISO/IEC directives, all ISO standards should use the comma as the decimal marker." I suggest we use comma for now and ask the team to implement both in the float type input and full stop in the output. [05:18:28] I have never used a programming language that used comma for float operations so this might be a case where we choose to deviate from ISO and follow the crowd of programming language designers who seemingly already use full stop as a de facto standard. (re @Nicolas: both works, what does the standards and customs says? [05:18:29] https://en.wikipedia.org/wiki/Decimal_separator#Current_standards is not v...) [05:32:29] You can comment or support the current proposal here: https://www.wikifunctions.org/wiki/Wikifunctions:Type_proposals/float64 (re @dpriskorn: Hm. Do you know the estimated time frame on that type being available? [05:32:30] Is it in the current sprint?) [05:36:28] I think that is because programming languages are "constructed" in English. Since wikifunctions is meant to be language neutral perhaps it _should_ deviate from _de facto_ to make a statement? (re @dpriskorn: Hm. Given "as per ISO/IEC directives, all ISO standards should use the comma as the decimal marker." I suggest we use full stop ...) [05:41:00] Also because there are plenty of gaps for functions we need that do use the existing types. So I get more reward by working on them. (re @Toby: Personally I'm not working on anything with floating point answers until we get the type. It's too much of a hassle to convert t...) [05:58:15] Wikimedia and this community can probably be said to have an anglophone bias. E.g. just the fact that 99% of the messages are in English without us even talking about that fact. 🤷‍♂ī¸ [05:58:16] I would welcome a deviation if the community dares support it. (re @Jan_ainali: I think that is because programming languages are "constructed" in English. Since wikifunctions is meant to be language neutral ...) [06:02:38] I'm pretty sure down the road such a decision is going to cause a lot of raised eyebrows with developers who get commas back and it breaks their stuff downstream 🤷‍♂ī¸ [06:08:09] Just like I often need to do a search and replace when trying to open anglophone data in LibreOffice with Swedish locale (expecting the comma) 😅 (re @dpriskorn: I'm pretty sure down the road such a decision is going to cause a lot of raised eyebrows with developers who get commas back and...) [08:12:07] What messages are you talking about? I'm using Wikifunctions in Polish and it's of quality comparable with Wikidata (where the English terms are usually just object labels that weren't translated by the community yet) (re @dpriskorn: Wikimedia and this community can probably be said to have an anglophone bias. E.g. just the fact that 99% of the messages are in...) [09:29:19] Me too 😅 (re @Jan_ainali: Just like I often need to do a search and replace when trying to open anglophone data in LibreOffice with Swedish locale (expect...) [10:13:05] Thanks for asking. I updated the original post. The wiki itself is admirably translatable 🤩. (re @Msz2001: What messages are you talking about? I'm using Wikifunctions in Polish and it's of quality comparable with Wikidata (where the E...) [13:05:16] It will be possible to create Parsers and Renderers for floating-point types. This will let people use any numeric format they like in the display layer. For example, here are the Renderers (or "display function"s) for `Z13518/Natural number`: https://www.wikifunctions.org/view/en/Z14302. To separate triples, English varieties use commas; Italian, Norwegian, and Spanish use periods, etc. Something similar could be done [13:05:16] for floating-point. The only thing I'm sad about is that we don't have Renderers for numbers in other scripts yet! (re @dpriskorn: Hm. Given "as per ISO/IEC directives, all ISO standards should use the comma as the decimal marker." I suggest we use comma for now and ask the team to implement both in the float type input and full stop in the output.) [13:05:38] But supporting these things inside of, say, Python or JS would be a different story ☚ī¸ [14:06:14] (Like, the only thing I'm sad about with respect to numerical formatting, not the only thing in life :grim The only thing I'm sad about is that we don't have Renderers for numbers in other scripts yet! (re @dpriskorn: Hm. Given "as per ISO/IEC directives, all ISO standards should use the comma as the decimal marker." I suggest we use comma for now and ask the team to implement both in the float type input and full stop in [14:06:14] the output.) [14:06:37] (Like, the only thing I'm sad about with respect to numerical formatting, not the only thing in life đŸ˜Ŧ (re @pine: The only thing I'm sad about is that we don't have Renderers for numbers in other scripts yet!) [15:16:15] This is fantastic! (re @wmtelegram_bot: It will be possible to create Parsers and Renderers for floating-point types. This will let people use any numeric forma...)