[00:23:25] why wouldn't there be differences? you could argue that AD is latin, but BC is english (and so are CE and BCE), not all languages use the latin alphabet, not all languages use 0-9 for digits, not all regions use the gregorian calendar by default, and not all languages allow bare numbers for years [00:24:17] (also wikidata can answer that question, by looking at the labels on items like https://www.wikidata.org/wiki/Q27633) [00:24:35] This is the Gregorian calendar type? (re @Nikki: why wouldn't there be differences? you could argue that AD is latin, but BC is english (and so are CE and BCE), not all language...) [00:24:57] I can't see messages if you quote part of it, by the way [00:34:30] Yes. But you don't need to write a function for every language. You can wrap yours in a multilingual chooser like Z14280, and set it as both English and default. Then anyone who wants their language displayed properly, can write one and add it to the configuration (like at Z14302). It's a little bit of an overhead cost to set up, but very powerful and flexible once it's [00:34:30] in place. [00:34:30] (re @Feeglgeef: Is there any difference between what is used in different languages?) [00:36:21] Ok, will do that [00:41:35] Done [00:41:38] That's a nice way of seeing a quick survey. We've got a long way to go to render all these!! (re @Nikki: (also wikidata can answer that question, by looking at the labels on items like https://www.wikidata.org/wiki/Q27633)) [00:42:35] The parser should already be multilingual though. [00:48:11] Cool thing: All the Gregorian year stuff has ZIDs that have the first 4 digits of a Gregorian year in the last decade [00:50:59] and that's only got 72 labels! cldr for example has 180 unique translations of "BC" alone - https://www.unicode.org/cldr/charts/46/by_type/date_&_time.gregorian.html#324cdfd07b386d43 (re @Toby: That's a nice way of seeing a quick survey. We've got a long way to go to render all these!!) [00:55:04] I made a minor fix to the composition - I think it works now. (re @Feeglgeef: Done) [00:55:31] Z20241 [01:03:38] Hmmm… I wouldn’t set it as the default display function. (I’d rather the default was to leave it unrendered, but I don’t think that’s an option.) Maybe we should use + and - like ISO 8601? (re @Toby: Yes. But you don't need to write a function for every language. You can wrap yours in a multilingual chooser like Z14280, and se...) [01:03:39] I applaud mixing up the time as much as you can. But I'll send my apologies in advance on this one as I will be travelling. (re @vrandecic: We were asked about a different time slot during the day for the volunteers' corner for a one-off. Our proposal is December 9, 1...) [01:05:50] I think we have to set a default, and while this is the only one, it is by default the default. But I agree with you that -1000 would make sense as a better default once it's written. As is apparently the Esperanto label! (re @Al: Hmmm… I wouldn’t set it as the default display function. (I’d rather the default was to leave it unrendered, but I don’t think t...) [01:07:53] Z20194 [01:08:33] It took a lot of fiddling around with the validator but it worked [01:12:32] What is it? And similarly what is the point of attaching Z10121 to Z20000? (re @Feeglgeef: Z20194) [01:12:53] I’m all in favour of proper minus signs but I’m more in favour of ISO 8601 compatibility and I don’t know what that stipulates. (re @Toby: I think we have to set a default, and while this is the only one, it is by default the default. But I agree with you that -1000 ...) [01:12:54] I was testing [01:13:03] 🗿 (re @Toby: What is it? And similarly what is the point of attaching Z10121 to Z20000?) [01:22:00] Oh... hmm... actually ISO 8601 would show -999 for 1000 BC. That may confuse some users with languages using the default. https://en.wikipedia.org/wiki/ISO_8601#Years (re @Toby: I think we have to set a default, and while this is the only one, it is by default the default. But I agree with you that -1000 ...) [01:22:46] Currently the parser just guesses that you mean 999 BC by -999, so maybe do that for consistency? (re @Toby: Oh... hmm... actually ISO 8601 would show -999 for 1000 BC. That may confuse some users with languages using the default. https:...) [01:23:36] Although I guess that there isn't really a good reason for this but because it would be slightly easier to implement (re @Feeglgeef: Currently the parser just guesses that you mean 999 BC by -999, so maybe do that for consistency?) [01:27:33] Yeah, that’s why I’d prefer to leave it unrendered by default 🤷‍♂️ (or even universally) (re @Toby: Oh... hmm... actually ISO 8601 would show -999 for 1000 BC. That may confuse some users with languages using the default. https:...) [01:27:51] According to the list of WD labels that Nikki pointed us to, many natural languages have also chosen that convention. To me the clash between intuition and ISO suggests that we should not set users up to fail by using either as a default render. If they see an English label, they will either have to (safely) convert, or set up a renderer for their language. (re@Feeglgeef [01:27:51] : Althou [01:27:51] gh I guess that there isn't really a good reason for this but because it would be slightly easier to implement) [01:28:37] IMO intuition is more important than ISO (re @Toby: According to the list of WD labels that Nikki pointed us to, many natural languages have also chosen that convention. To me the ...) [01:29:29] Yes, I now see the issue. But as far as I understand the system, we do not have a way to "default" to non-rendering. (re @Al: Yeah, that’s why I’d prefer to leave it unrendered by default 🤷‍♂️ (or even universally)) [01:30:08] Just going to say that if it's unrendered the Era is rendered as AD/BC anyway (re @Al: Yeah, that’s why I’d prefer to leave it unrendered by default 🤷‍♂️ (or even universally)) [01:31:05] I think we should get the object label of Era in the language and append the number to it [01:31:49] No. But we do have the default of not rendering at all. The Era will then depend on its Wikifunctions label. Stringify that, if you must 😏 (re @Toby: Yes, I now see the issue. But as far as I understand the system, we do not have a way to "default" to non-rendering.) [01:41:41] Only when there’s no label in the current interface language (just for the record) (re @Feeglgeef: Just going to say that if it's unrendered the Era is rendered as AD/BC anyway) [01:47:28] How does lexeme form tools utilize Wikifunctions (re @vrandecic: Newsletter 181: [01:47:29] * New Special page: missing labels [01:47:30] * New types: Gregorian year and Wikidata statement rank [01:47:32] * Lexeme form tools n...) [02:19:33] This could be another way of writing a default stringifying renderer. But accessing object labels from within a function was extremely hard last time we investigated it. (re @Feeglgeef: I think we should get the object label of Era in the language and append the number to it) [02:24:39] I can't even tell what you're trying to test, but it may be better done on test.wikifunctions (re @Feeglgeef: I was testing) [02:27:46] I was testing (re @Toby: I can't even tell what you're trying to test, but it may be better done on test.wikifunctions) [03:34:42] https://www.wikifunctions.org/view/Z20/Z20000 [03:36:14] That's a bug (re @Feeglgeef: https://www.wikifunctions.org/view/Z20/Z20000) [03:36:31] Though I don't think you would be able to experience it unless you were looking for it. [03:37:47] It happens any time you try to set your language to a ZID (even a valid one) but if it's not a ZID and still invalid it will default to English [03:41:09] T380559 [11:11:51] If set up, you get (an) extra button(s) above the form, click on it, and uses the functions tied to each form to generate the regular form : https://tools-static.wmflabs.org/bridgebot/661f3574/file_66717.jpg [11:11:52] https://tools-static.wmflabs.org/bridgebot/24be445f/file_66718.jpg [11:11:53] https://tools-static.wmflabs.org/bridgebot/e7ec4bfb/file_66719.jpg [11:14:56] oh no, no I need to write glosses for that Lexeme 😛 [11:32:34] Did you invert it? [11:32:45] ? [11:33:06] Wikifunctions should query from Wikidata... [11:33:23] As many many verb conjugations aren't regular [11:33:33] It's a happy family that helps each other [11:33:48] Somebody not knowing that would misuse those functions [11:34:14] from each according to their ability, to each according to their needs [11:34:14] I was thinking of circular references... [11:34:32] many many more verb conjugations are regular than irregular [11:34:35] (Did I make myself clear? (re @cvictorovich: I was thinking of circular references...) [11:34:45] there is no circular reference happening [11:35:21] lexeme forms uses functions to generate regular forms to suggest. before saving them to wikidata, the contributor still should look through them and check. [11:35:41] once they are saved on wikidata, wikifunctions doesn't do anything there, currently [11:36:12] I'm still thinking of functions querying conjugations directly from Wikidata [11:36:31] Rather than conjugating based on some patterns [11:36:40] yes, that's a different use case [11:37:01] This isn't always a reliable model (re @cvictorovich: Rather than conjugating based on some patterns) [11:37:35] Wait, let me be more elaborate: [11:37:36] absolutely correct. that's why the contributor should check the results before saving. [11:37:56] Sure. But forms on lexemes are also useful outside of Wikifunctions. (re @cvictorovich: I'm still thinking of functions querying conjugations directly from Wikidata) [11:41:06] Say, I built some functions that query lexemes forms directly from Wikidata, and didn't leave any implementations based on inflection rules; now that if we use it in lexeme form tool, the function doesn't know about other forms (as it only queries from Wikidata, while Wikidata has no data on that word at all!), can the function output anything to lexeme tool? [11:42:02] The tool is for creating new lexemes (re @cvictorovich: Say, I built some functions that query lexemes forms directly from Wikidata, and didn't leave any implementations based on infle...) [11:42:10] There will be no way to call it [11:42:12] Whereas in many many cases, implementations based on "inflection rules" aren't realistic [11:42:28] You can't call a function with a Lexeme that does not exist [11:42:35] It's not a string input [11:44:20] Or when I edit on an existing but incomplete lexeme (I've been doing this for long), I called the function, but the function cannot return yet-to-create forms! [11:44:46] That's why I'm creating those forms! [11:45:26] Yes. You should not be calling Lexeme functions in the tool (re @cvictorovich: Or when I edit on an existing but incomplete lexeme (I've been doing this for long), I called the function, but the function can...) [11:45:56] that's correct. It shouldn't be using the functions that are Lexeme based, but it should be string-based, and should only create the regular forms. If they are right often enough, it is helpful. [11:46:16] I'd be surprised if you didn't get an expected Lexeme, got String (re @vrandecic: that's correct. It shouldn't be using the functions that are Lexeme based, but it should be string-based, and should only create...) [11:46:39] ? [11:46:49] Sure it only applies to common scenario (re @vrandecic: that's correct. It shouldn't be using the functions that are Lexeme based, but it should be string-based, and should only create...) [11:47:10] Would't be working for the messy and trashy English language! [11:47:31] often enough it does [11:47:54] While I'm fluent in English, I dislike English much [11:48:12] English orthography is completely a pile of shift! [11:48:26] I would prefer us to avoid such language [11:48:39] (Pardon my French) [11:48:51] English conjugation is only irregular for common verbs, and we should already have all of those (re @cvictorovich: Would't be working for the messy and trashy English language!) [11:49:22] Another good example is for French verbs [11:50:00] Normally verbs ending in -er are group 1, -ir are group 2, all others are group 3 [11:50:02] I'm not a fan of English, but once you get to <1/1000000, everything is fine (re @Feeglgeef: English conjugation is only irregular for common verbs, and we should already have all of those) [11:50:04] @cvictorovich that's your cue to tell us which time would work! (re @vrandecic: We were asked about a different time slot during the day for the volunteers' corner for a one-off. Our proposal is December 9, 1...) [11:50:19] I remember that (re @Sannita: @cvictorovich that's your cue to tell us which time would work!) [11:50:27] Many many thanks! [11:51:10] However there are countless exceptions in group 2 that actually belongs to group 3! (re @cvictorovich: Normally verbs ending in -er are group 1, -ir are group 2, all others are group 3) [11:51:40] And you have to input those manually (re @cvictorovich: However there are countless exceptions in group 2 that actually belongs to group 3!) [11:51:48] That's the point [11:52:20] If everything was regular, we'd be generating them with a bot [11:52:30] That's exactly also why I didn't complete some of my functions until yesterday (re @cvictorovich: However there are countless exceptions in group 2 that actually belongs to group 3!) [11:52:53] Don't judge them based on patterns [11:53:10] It's why there are still we humans (re @Feeglgeef: If everything was regular, we'd be generating them with a bot) [11:53:31] Only we homo sapiens can handle all kinds of exceptions [11:53:44] Actually, paradigm completion from a limited number of forms is an interesting sub-problem. Most irregular verbs also follow regular patterns to a great extent. (re @Feeglgeef: And you have to input those manually) [11:56:17] yes, usually, if you have two or three forms to start with, the rest is almost always regular [11:56:26] they are still exceptions, but they are super rare [11:57:15] Even more obscure and hidden issues are "defective verbs" (re @cvictorovich: Normally verbs ending in -er are group 1, -ir are group 2, all others are group 3) [11:57:43] Nicolas has his say on it: I'm not versed in these cases [11:59:08] He's busy now, maybe inappropriate to disturb him here now [12:01:54] @Sannita @vrandecic this time slot is better for me! [12:08:38] Luckily, I never had to learn this stuff formally, but I think it is the case that an English verb whose 3rd-person singular does not end in s has no infinitive (“it would” but not *”to would”), for example. (re @cvictorovich: Even more obscure and hidden issues are "defective verbs") [12:11:31] isn't the infinitive of would will? [12:13:01] Isn't that the 3rd person singular? (re @vrandecic: isn't the infinitive of would will?) [12:13:49] he will/she will/they will [12:15:05] No, but you’re right… the _present tense_ 3rd person singular would be “it will” and “to will” is the missing infinitive (for that lexeme) (re @vrandecic: isn't the infinitive of would will?) [12:20:12] (But we also have “it wills” and then the infinitive is “to will”. I told you I never learnt this stuff 🙄) (re @vrandecic: isn't the infinitive of would will?) [12:27:23] To fail is human; to can is to put things in tins 😏 [12:34:37] To err is human, to arr is pirate. (re @Al: To fail is human; to can is to put things in tins 😏) [12:37:46] https://music.youtube.com/watch?v=Xj0SYLV-PqE&si=_gzhI7CxA9uaiChy [13:44:24] Imo HTML should be a type: HTML tag, to make it easy to use and manipulate [13:44:47] With a function to parse or stringify [15:21:28] Have there been such functions available? I may have some examples, and I would build such things for French verbs (re @vrandecic: that's correct. It shouldn't be using the functions that are Lexeme based, but it should be string-based, and should only create...) [21:32:17] Which one are you referring to? (re @cvictorovich: Have there been such functions available? I may have some examples, and I would build such things for French verbs) [21:33:51] If you mean Lexeme functions, yes. If you mean String conjugations, I'm not sure. [21:37:16] Yes, many, but not for all languages. You may need to write them yourself, but there are lots of helper functions to make the compositions easy. (re @cvictorovich: Have there been such functions available? I may have some examples, and I would build such things for French verbs) [23:42:26] @vrandecic I think we should have the moment in time type soon. SI Unit would be cool but definitely not a priority.