[00:03:33] (Please feel free to edit this copy.) [00:40:24] 😎 Works in the iPhone app too 👍 [01:02:45] They don't seem to run? I just see the template text. Unlike Amir's dag-wiki userpage which shows as I would expect. : https://tools-static.wmflabs.org/bridgebot/5cba97c7/file_69945.jpg [01:03:18] You need to manually enable parsoid (re @u99of9: They don't seem to run? I just see the template text. Unlike Amir's dag-wiki userpage which shows as I would expect.) [01:03:44] Dagwiki has it by default [01:04:21] Special:Preferences at the bottom of the editing tab (re @Feeglgeef: You need to manually enable parsoid) [01:05:09] Ah yes, thanks, I got it to work. (re @Feeglgeef: You need to manually enable parsoid) [01:09:55] This error is the only problem I see but don't understand. : https://tools-static.wmflabs.org/bridgebot/cfbf0936/file_69946.jpg [01:11:05] Does it tell you more in the visual editor? (re @u99of9: This error is the only problem I see but don't understand.) [01:11:15] How long does it take to call? I've waited more than a minute with refresh. Do I need to purge? https://test.wikipedia.org/wiki/User:99of9/sandbox : https://tools-static.wmflabs.org/bridgebot/e46e4672/file_69947.jpg [01:12:30] I'm not editing, just viewing. The link points to [[Help:Using_Wikifunctions#Failed_evaluation]] (re @Feeglgeef: Does it tell you more in the visual editor?) [01:14:34] Yes, purging works. (re @u99of9: How long does it take to call? I've waited more than a minute with refresh. Do I need to purge? https://test.wikipedia.org/wiki/...) [01:39:19] I tried that. Switching to a different day was successful, but when I came back to Monday it failed again. I've also tried purging this page. So I think there is a persistent cache error on Wikifunctions. (re @Feeglgeef: Does it tell you more in the visual editor?) [05:08:31] Yes. This format is good (re @Al: Thank you. Is that format good, or just a compromise? I mostly see years preceded by “yuuni” in articles.) [06:28:59] I've also disconnected Z20813 and Z20814 because I believe the offsets for the year are in the wrong direction. -0004 means 5 BC in ISO 8601. I'm happy to make the changes directly, but wanted to comment first since the parser is already connected. (re @u99of9: Usually the reader/parser gets connected at the same time as the display, so we're looking at Z20808. I've [06:28:59] just added a couple o...) [08:11:08] I have some unpublished changes to the logic, forcing year-first for lengths over two and values less than 1. There should probably also be a test for an explicit “+” but I think that omission affects only years AD 1 to 9 (and I only just thought of it). (re @u99of9: I've also disconnected Z20813 and Z20814 because I believe the offsets for the year are in the wrong [08:11:08] direction [08:11:09] . -0004 means 5 BC...) [08:50:47] Looks to me like that adjustment to the years should just be commented out. Seems to work… (re @u99of9: I've also disconnected Z20813 and Z20814 because I believe the offsets for the year are in the wrong direction. -0004 means 5 BC...) [09:15:36] Z20809 amended, as above. This should now be correct for ISO 8601 dates. If we want to read “sensible” BC(E) years (like “54 BC”), we’ll need specific year-adjustment (to -53), but 0 (however represented) will always go to 1 BC (or equivalent). (Note that values less than 1 are currently permitted in final position, which results in a negative day if the year-first cond [09:15:36] [09:15:36] ition is also met.) [09:36:15] Is there a function to which `-inf` is a good placeholder input? [09:39:13] Context: I was testing inserting functions using VE, and at some point I saw "E.g. -inf" as an input placeholder. [09:39:29] When I tried inserting that function again, it said "E.g. 1.0". [09:40:18] I’m not sure what you mean, but this is where negative infinity is used https://www.wikifunctions.org/wiki/Special:WhatLinksHere?limit=50&namespace=0&target=Z20833 (re @amire80: Is there a function to which -inf is a good placeholder input?) [09:40:29] It's probably a caching issue or something. [09:40:31] Now, for that specific function, "E.g. 1.0" is a better placeholder. But I can imagine that ""E.g. -inf" can be a good placeholder for, um, some functions, but I'm not sure which ones. [09:43:19] And I'd love to have a function where this is the specific and predictable input placeholder because currently, when "-inf" is displayed and the user interface language is Hebrew, it's displayed incorrectly. [09:43:37] I'd love to give the test engineers predictable reproduction instructions. [09:44:20] The hint always comes from the first test in Z21956, but that can change. (re @amire80: Now, for that specific function, "E.g. 1.0" is a better placeholder. But I can imagine that ""E.g. -inf" can be a good placehold...) [09:44:59] All of these are Test cases or Implementations. The only relevant object for my needs here is probably Function. (re @Al: I’m not sure what you mean, but this is where negative infinity is used https://www.wikifunctions.org/wiki/Special:WhatLinksHere...) [09:45:40] No, the type hint depends on the type, not the specific function. (re @amire80: All of these are Test cases or Implementations. The only relevant object for my needs here is probably Function.) [09:48:01] (…or it’s Z21956, depending on whether it is just the type hint that is incorrect) (re @amire80: All of these are Test cases or Implementations. The only relevant object for my needs here is probably Function.) [09:49:21] (I suppose it’s a “value hint” really, but there is only one current for the type.) (re @amire80: All of these are Test cases or Implementations. The only relevant object for my needs here is probably Function.) [09:53:34] Z20833 does not have a Hebrew label, so it will currently default to “-inf” in all cases. (re @amire80: All of these are Test cases or Implementations. The only relevant object for my needs here is probably Function.) [09:57:34] OK, but I want to report a bug about VE frontend, and for that, I need a function (re @Al: No, the type hint depends on the type, not the specific function.) [09:59:01] Um... but it does have a label in English, and when it is shown as a placeholder and the user interface language is English, will it show that label or "-inf"? (re @Al: Z20833 does not have a Hebrew label, so it will currently default to “-inf” in all cases.) [10:00:12] Common sense tells that when you send that as an explicit value, it's supposed to be the same in all the languages. [10:07:36] No, it depends on the read function, Z21925. That defines how a string is interpreted into a Wikifunctions object. And the display function determines how such an object is displayed. (re @amire80: Common sense tells me that when you send that as an explicit value, it's supposed to be the same in all the languages.) [10:09:55] Currently Hebrew is not configured, so it defaults to English (in Z21999) (re @amire80: Common sense tells me that when you send that as an explicit value, it's supposed to be the same in all the languages.) [10:10:22] I think this is a red herring. The labels on Z20833 don't determine how/why it appears in the float64 promoter. (re @Al: Z20833 does not have a Hebrew label, so it will currently default to “-inf” in all cases.) [10:11:48] Yes, I think you’re right. Sorry… I think I corrected myself without even noticing! (re @u99of9: I think this is a red herring. The labels on Z20833 don't determine how/why it appears in the float64 prompter) [10:15:04] Yes the other stuff you are saying seems right. But I wonder if we can be more explicit about what the problem and solution is. Amir, are you saying that you want to change the prompt for those with Hebrew interface? (re @Al: Yes, I think you’re right. Sorry… I think I corrected myself without even noticing!) [10:16:07] I'm confused now. Does the interpretation of the input value ever depend on a label of an object in a particular language? [10:16:11] We may be able to fix it by improving our functions rather than changing the front end. (re @amire80: OK, but I want to report a bug about VE frontend, and for that, I need a function) [10:16:26] No (re @amire80: I'm confused now. Does the interpretation of the input value ever depend on a label of an object in a particular language?) [10:16:55] I agree with Toby, sorry. (re @amire80: I'm confused now. Does the interpretation of the input value ever depend on a label of an object in a particular language?) [10:16:56] OK, so let's go back to my original question: (re @u99of9: We may be able to fix it by improving our functions rather than changing the front end.) [10:16:59] Is there a function to which `-inf` is a good placeholder input? :) [10:17:44] Add(-inf, 1.0) = -inf [10:18:22] Does something like this exist at the moment? [10:18:26] But it's obviously not the best placeholder for any language, because it's mathematically extreme. [10:19:31] Yes, we have an add float64 function (re @amire80: Does something like this exist at the moment?) [10:19:37] Yes, it's extreme, which is why I am having a hard time finding an example. But it is kind of... conceivable? [10:19:55] Z20849 (re @amire80: Yes, it's extreme, which is why I am having a hard time finding an example. But it is kind of... conceivable?) [10:20:34] But your binary questions are not helping me understand the root of your issue. [10:20:39] Ouch, its input names (at least in English) could be better. (re @Al: Z20849) [10:21:26] Agreed. 🙄 (re @amire80: Ouch, its input names (at least in English) could be better.) [10:21:52] I agree a better exemplar would almost always be 1.0 (or the equivalent in one's local script) [10:22:49] The root of the issue is that "-inf" can sometimes be displayed as the placeholder in the VE dialog to insert a function, and when the UI language is Hebrew, it's displayed incorrectly as "inf-". (re @u99of9: But your binary questions are not helping me understand the root of your issue.) [10:24:15] I wonder if "-1.0" would have a similar problem. [10:24:24] Quite likely! (re @u99of9: I wonder if "-1.0" would have a similar problem.) [10:25:04] If you can help me find a function where that would be the predictable placeholder, I can probably use that, and the same solution will apply to "-inf". [10:27:48] When you talk of "predictable" placeholder, are you seeing some non-determinism? We think the placeholder for every float64 input is supposed to be the same, deterministic for each language. [10:29:37] I've tried to insert the same function several times, and in some cases, I saw "-inf", and in some others, I saw "1.0". It may be a caching issue, but the reason doesn't matter. (re @u99of9: When you talk of "predictable" placeholder, are you seeing some non-determinism? We think the placeholder for every float64 inpu...) [10:30:41] The really good solution is: [10:30:42] 0. Not to use HTML placeholders at all. Like, anywhere. I am telling all the designers that do stuff for Wikimedia not to use them, and I hope that some day it will become a global guideline. HTML placeholders are an unfixable nightmare because they never work well with RTL languages. I tried talking to w3c, Google, and Mozilla several times about this. They [10:30:42] understand the proble [10:30:43] m, but can't do much. [10:30:45] 1. To find a better way to display sample input that doesn't use HTML placeholders. [10:30:46] 2. To make a CSS class that ensures that sample input is displayed correctly, no matter what is the user interface language. [10:30:55] The placeholder/prompter/value hint does not depend on the function but on the argument type. If you report that you’re seeing “inf-“ as a hint in some function that has a float64 argument type, that should suffice. (re @amire80: If you can help me find a function where that would be the predictable placeholder, I can probably use that, and the same soluti...) [10:38:13] I still expect that we can get it to render a better string for an RTL language by spitting out better output from Z21956. Perhaps it should contain direction-forcing characters? (re @amire80: The really good solution is: [10:38:13] 0. Not to use HTML placeholders at all. Like, anywhere. I am telling all the designers that do stuf...) [10:39:22] Direction-forcing characters should be used only when there is no better solution. (re @u99of9: I still expect that we can get it to render a better string for an RTL language by spitting out better output from Z21956. Perha...) [10:40:37] Cool, but I want to give the test engineer who will look at the bug report good reproduction instructions. (re @Al: The placeholder/prompter/value hint does not depend on the function but on the argument type. If you report that you’re seeing “...) [10:42:28] I think this will catch a bigger problem: "Go to https://www.wikifunctions.org/view/he/Z21775, type "-1.0", see "1.0-", bad. This is more important than the placeholder? (re @amire80: Cool, but I want to give the test engineer who will look at the bug report good reproduction instructions.) [10:43:15] It's indeed a bug, but a separate one. (re @u99of9: I think this will catch a bigger problem: "Go to https://www.wikifunctions.org/view/he/Z21775, type "-1.0", see "1.0-", bad." Th...) [10:43:44] There’s something dodgy going on, because the hint should just be a simple string. There’s presumably some RTL inference applied, otherwise a string of digits would come out RTL rather than LTR. (re @u99of9: I still expect that we can get it to render a better string for an RTL language by spitting out better output from Z21956. Perha...) [10:45:16] I guess it is related. Both are just showing in the box either the default value with a prepended "e.g. " or the typed in value. (re @amire80: It's indeed a bug, but a separate one.) [10:46:12] Of course… but to be reproducible, the state of the system must be that “-inf” is the English placeholder. (re @amire80: Cool, but I want to give the test engineer who will look at the bug report good reproduction instructions.) [10:47:37] I guess clever, not dodgy, but not quite clever enough!! (re @Al: There’s something dodgy going on, because the hint should just be a simple string. There’s presumably some RTL inference applied...) [10:48:58] (I guess disconnecting all but one of the display function test cases will achieve this.) (re @amire80: Cool, but I want to give the test engineer who will look at the bug report good reproduction instructions.) [10:49:43] Let's not do this. I could agree if it was "–1.0", because infinity is the wrong example for every language! (re @Al: (I guess disconnecting all but one of the display function test cases will achieve this.)) [10:50:52] Not us, the investigating developer! (re @u99of9: Let's not do this. I could agree if it was "–1.0", but infinity is the wrong example for every language!) [10:55:10] Wow, something strange is going on in the world of determinism. When I reload this page https://www.wikifunctions.org/view/en/Z21775 the box is initially blank, then momentarily "E.g. -inf" then switches to "E.g. 1.0" [10:57:28] And I just saw something similar when reloading https://www.wikifunctions.org/view/he/Z21775 but the first value looked like pi, and then it settled on 1.0. (re @u99of9: Wow, something strange is going on in the world of determinism. When I reload this page https://www.wikifunctions.org/view/en/Z2...) [10:59:52] Luckily, I caught it beforehand : https://tools-static.wmflabs.org/bridgebot/f05bcf9b/file_69954.jpg [11:00:39] I guess the javascript is setting that placeholder value twice. Neither is necessarily using the algorithm we were told "first exemplar from the display function. [11:01:57] The first one when it looked, I’m guessing. (re @u99of9: I guess the javascript is setting that placeholder value twice. Neither is necessarily using the algorithm we were told "first e...) [11:08:58] Whizzing through those listed by my trusty search, it’s going to “e.g. 1.0” for all of them, including Z21956 (now). (re @u99of9: I guess the javascript is setting that placeholder value twice. Neither is necessarily using the algorithm we were told "first e...) [11:10:10] (depending on the browser cache?) (re @Al: Whizzing through those listed by my trusty search, it’s going to “e.g. 1.0” for all of them, including Z21956 (now).) [11:12:57] But the first test there is Z21959.... so after all the refreshing we've ended up with an old cached value?? (re @Al: The hint always comes from the first test in Z21956, but that can change.) [11:13:46] (I’m actually getting different examples depending on the browser I’m using 😏) (re @u99of9: I guess the javascript is setting that placeholder value twice. Neither is necessarily using the algorithm we were told "first e...) [11:15:14] Actually, that's the first test I see in the GUI, but when I manually edit the object, I do indeed see Z21958: : https://tools-static.wmflabs.org/bridgebot/fff48d5a/file_69956.jpg [11:16:17] Does anyone mind if I manually mess around with this order to see if we can easily get "-1.0" to the top? (re @u99of9: Actually, that's the first test I see in the GUI, but when I manually edit the object, I do indeed see Z21958:) [11:19:12] Fine by me! (re @u99of9: Does anyone mind if I manually mess around with this order to see if we can easily get "-1.0" to the placeholder?) [11:22:52] I've made the edit, and purged the page, but am yet to see any changes in placeholders. (re @Al: Fine by me!) [11:24:22] Yes, it has come through: : https://tools-static.wmflabs.org/bridgebot/63cfa27d/file_69959.jpg [11:26:58] …and the display in Hebrew is “1.0- …” (re @u99of9: Yes, it has come through:) [11:27:23] https://tools-static.wmflabs.org/bridgebot/27caff7c/file_69960.jpg [11:30:01] I think that is what we expected… but I guess @amire80 is busy in Phabricator. (re @u99of9: ) [11:33:24] That's exactly what I was experiencing. (re @u99of9: Wow, something strange is going on in the world of determinism. When I reload this page https://www.wikifunctions.org/view/en/Z2...) [11:33:46] I would expect the tests to appear in the order they are listed in the underlying object. (re @Al: I think that is what we expected… but I guess @amire80 is busy in Phabricator.) [11:34:27] I was busy on Duolingo, actually :) (re @Al: I think that is what we expected… but I guess @amire80 is busy in Phabricator.) [11:34:52] This is a probably a good example of the same problem. (re @u99of9: ) [11:35:20] My daughter would probably like to know how long your streak is. But I fear that your actual linguistic abilities would scare her. (re @amire80: I was busy on Duolingo, actually :)) [11:38:30] 2761. This week I'm doing pointless nonsense, mostly learning English from Russian, which is cheating. I'm trying to get a lot of points to get to the first place in the Diamond league finals. Usually I do something more interesting, like Vietnamese, Greek, or Swahili, but that's an actual challenge. Anyway, back to bug reporting... (re @u99of9: My daughter would [11:38:30] probably like to [11:38:31] know how long your streak is. But I fear that your actual linguistic abilities would scare he...) [11:39:51] Um, I'm not sure—how do I reproduce this? (re @u99of9: ) [11:39:52] Yes… I don’t know why the order changes. It looks as though they ordinarily get attend to the bottom and then (maybe?) get listed in ZID order. (re @u99of9: I would expect the tests to appear in the order they are listed in the underlying object.) [11:41:07] try going to https://www.wikifunctions.org/view/he/Z21775 (re @amire80: Um, I'm not sure—how do I reproduce this?) [11:41:38] Aha! Works. (re @u99of9: try going to https://www.wikifunctions.org/view/he/Z21775) [11:41:39] Thanks. [11:42:33] Is it expected to remain like that? [11:43:50] More or less, but tests can be modified, and that currently affects the placeholder. We can always get it back if necessary. (re @amire80: Is it expected to remain like that?) [11:51:19] I don’t think it changes unless you disconnect the (real) first test. Hypothesis (if consensus is against a particular hint): disconnect all test cases and reconnect the desired test case; then reconnect the other test cases. 🤷‍♂️ (re @u99of9: More or less, but tests can be modified, and that currently affects the placeholder. We can always get it back if necessary.) [11:54:17] I guess this requires particular revisions of Z21775 and... some other Z page(s)? (re @u99of9: try going to https://www.wikifunctions.org/view/he/Z21775) [11:54:29] (In case they change.) [11:58:35] I don’t think so. It’s dynamic, so long as the page is actually served (once the cached function call is replaced). (re @amire80: I guess this requires particular revisions of Z21775 and... some other Z page(s)?) [15:51:42] I just added the implementation Z23983 to Z20808, that uses a list of options for languages (since every language has its conventions about dates, and users may want to type the month literally). I already implemented a couple of options with a code that should be easy to adapt to other languages (by editing the declarations of the first variables) [16:50:30] Seems like there is something missing: [16:50:39] https://tools-static.wmflabs.org/bridgebot/98dd1eb6/file_69964.jpg [18:49:10] Does anything need to be left disconnected? (re @dvd_ccc27919: I just added the implementation Z23983 to Z20808, that uses a list of options for languages (since every language has its conven...) [19:02:45] I'm not native to English (so you can check if the English implementations work in a reasonable way), but apart that everything can be connected (re @Al: Does anything need to be left disconnected?) [19:25:48] Done ✅ I would expect an ISO 8601 string to parse correctly in English (and most/all languages) but “0002-04-16” is read as 2 April 16. (re @dvd_ccc27919: I'm not native to English (so you can check if the English implementations work in a reasonable way), but apart that everything ...) [19:29:46] Perhaps I am thinking that it could be better to intercept ISO 8901 (and other important standards) before calling the language-specific functions (re @Al: Done ✅ I would expect an ISO 8601 string to parse correctly in English (and most/all languages) but “0002-04-16” is read as 2 Ap...) [19:34:46] Are there other important standards we should respect? [19:34:49] Yes… I can see that working. Shall I just disconnect Z23983? (re @dvd_ccc27919: Perhaps I am thinking that it could be better to intercept ISO 8901 (and other important standards) before calling the language-...) [20:06:13] Perhaps we should also insert this logic in the language-dependent parsers (re @Al: I have some unpublished changes to the logic, forcing year-first for lengths over two and values less than 1. There should proba...) [21:11:08] I think I'm seeing a fun bug, but I need someone else to confirm: [21:11:09] 1. Make sure that your user interface language on https://test.wikipedia.org is English. [21:11:10] 2. Open https://test.wikipedia.org/w/index.php?title=User:Amire80/Z18784&veaction=edit . It's editing a page that calls a function. [21:11:12] 3. You are supposed to see some Russian text. That's the output of a function. Click it. [21:11:13] 4. You should see the label and the description of the function. In which language do you see them? [21:28:23] I see some English (presumably the label) and Hebrew (the description? I couldn’t say) [21:28:34] though the Hebrew is aligned left-to-right [21:30:15] ok, if I open the popup, the same hebrew is wrapped in a `

`, so I guess it is indeed the description [21:34:06] Perhaps… although I think split by “-“ leads to errors with a leading “-“ (re @dvd_ccc27919: Perhaps we should also insert this logic in the language-dependent parsers) [21:37:53] OK, it's the same thing that I see. (re @lucaswerkmeister: I see some English (presumably the label) and Hebrew (the description? I couldn’t say)) [21:38:56] I thought that perhaps it's Hebrew because it's my browser's language, but looks like it's yet another of those caching bugs on wikifunctions.org, because of which banners are shown in the wrong language, for example. It seems to propagate to the client sites, too. [21:48:55] I should have solved (re @Al: Yes… I can see that working. Shall I just disconnect Z23983?) [21:50:24] I think it’s just because there is no English description, just Hebrew and Russian. (re @amire80: I thought that perhaps it's Hebrew because it's my browser's language, but looks like it's yet another of those caching bugs on ...) [21:59:56] I think in ISO 8601 a 4-digit year can be signed or unsigned. If the year has more than four digits, it must also have a sign. (re @dvd_ccc27919: I should have solved) [22:01:42] I've managed to get age working with the {{#time:}} parser function. An example is on my WF user page. Could the team prefill this? [22:02:00] @Sannita [22:06:53] ⚓ T392165 Preset for "current day" on Wikifunctions integration wikis [22:06:54] https://phabricator.wikimedia.org/T392165 [22:17:47] Now I have solved (it accepts also years with more than 4 digits and without sign; I don't see a purpose to enforce this constraint) (re @Al: I think in ISO 8601 a 4-digit year can be signed or unsigned. If the year has more than four digits, it must also have a sign.) [22:20:04] No, I don’t remember hearing a reason for it 😎 (re @dvd_ccc27919: Now I have solved (it accepts also years with more than 4 digits and without sign; I don't see a purpose to enforce this constra...) [22:26:14] Al Actually Z24006 doesn't work correctly and should be disconnected [22:29:43] Mmmm... but I think that there is an English description. (re @Al: I think it’s just because there is no English description, just Hebrew and Russian.) [22:30:42] Mmm... does anyone why did User:Nyuhn remove an implementation? [22:37:33] Mmm… I think not. (re @amire80: Mmmm... but I think that there is an English description.) [22:40:17] https://tools-static.wmflabs.org/bridgebot/434795ae/file_69967.jpg [22:50:55] O drat, I confused the label and the description 🤦🏻‍♂️