[00:11:19] All languages (re @Channel_Bot: Global question. How to translate already interlingual string? [00:11:19] Will it be right that the name will remain only in English? [00:11:21] Or ...) [00:11:38] You have to click edit source to add one [00:12:23] 🤣 (re @wmtelegram_bot: It's fine; we're going to put `pyautogui` in the Python executor so you can turn this into a single function call 😛 (@Fe...) [01:00:20] Ok, I will use it. [01:00:21] Also I should note. [01:00:22] If this is the right approach, it destroys the SSOT principle. [01:00:24] Has anyone thought about this? 🤔 (re @Feeglgeef: All languages) [01:01:49] What do you mean (re @Channel_Bot: Ok, I will use it. [01:01:49] Also I should note. [01:01:51] If this is the right approach, it destroys the SSOT principle. [01:01:52] Has anyone thought about...) [03:54:53] It's probably a no, but it would be nice to have SciPy (python library) available to import on Wikifunctions. I think you just need to import it in the python executor and add it to the globals [03:55:08] Math.js is also something I'd like [03:56:11] Of course, if we do include 3rd-party libraries, we should use consensus instead of whatever I happen to be most familiar with. [04:03:28] I'd really really like SciPy, though (re @Feeglgeef: It's probably a no, but it would be nice to have SciPy (python library) available to import on Wikifunctions. I think you just n...) [04:25:02] No label is more true than anyone else. The first one does not have any kind of special status and may very well change later. Sometimes translating a label is when one discover that what is being translated is not ideal and could be improved. (re @Channel_Bot: Ok, I will use it. [04:25:03] Also I should note. [04:25:04] If this is the right approach, it destroys the SSOT principle. [04:25:06] Has anyone thought about...) [07:34:10] Hi Alex! That's a great question. We have not planned to add the translation memory to the label and description translations, but that it could be an interesting idea. If you want, you can capture it in a task, and yes, help on this will certainly make it happen faster (especially since we were not planning this). [07:34:12] Having said that, I was thinking of possibly using the same principles for translating as for Abstract Wikipedia, i.e. abstract labels and descriptions. We are getting to making this possible. So there is the fair question how useful adding manual translations is. [07:34:13] I would focus on translating functions and types, and maybe not worry so much about tests and implementations. (re @Channel_Bot: @vrandecic Please tell me when is it planned to integrate the translation extension (https://m.mediawiki.org/wiki/Extension:Tran...) [07:36:46] I'd love to see your abstractification of the Battle of Aleppo article. [07:36:46] About the more fine-grained names of keys, I am not so sure. Any such ontology turns out to be lacking and inflexible eventually. I prefer the flexibility of less meaningful structures and names. If you are really invested in the idea, I would suggest to write a bit more on-wiki, so it can be discussed, this short message did not yet convince me of the benefits of [07:36:47] your proposal. [07:36:48] (re @Feeglgeef: On a completely unrelated note, for abstract content, we should have a separate ID system for keys. This would make it easier to...) [11:20:57] > I would focus on translating functions and types, and maybe not worry so much about tests and implementations. [11:20:57] I agree with you about that. [11:20:58] I'll go through the function catalog and translate (at first only the labels) all the functions into Russian as far as I can. [11:21:00] Progress will be noted here [11:21:01] https://www.wikifunctions.org/wiki/User:Alexander-Mart-Earth#Russian_labels_of_functions [11:21:03] Если вы владеете русским — присоединяйтесь :) (re @vrandecic: Hi Alex! That's a great question. We have not planned to add the translation memory to the label and description translations, b...) [11:23:06] I have completed the translation of color functions into Russian as part of my personal Russian translation project: [11:23:07] https://www.wikifunctions.org/wiki/User:Alexander-Mart-Earth#Russian_labels_of_functions (re @Nicolas: Hi y'all, [11:23:09] As I mentionned before, I created a subpage of the catalog for colours: https://www.wikifunctions.org/wiki/Wikifunctio...) [13:08:14] What would be done is the *value* of the keys would be very flexible. Every key would be like a Z2K2, accepting basically anything that makes sense. (re @vrandecic: I'd love to see your abstractification of the Battle of Aleppo article. [13:08:15] About the more fine-grained names of keys, I am not so ...) [14:14:59] Sorry, can you reformulate? I don't understand [14:24:05] We should put the detail in the values. That's the general standard for things. The values should be specific and tell you exactly what the thing means and it's exact relation [14:24:50] Moving complexity to the keys and making them any Wikidata item will be much harder to process into natural language [14:25:37] Of course, we could use more keys than the few I proposed, but I think too much keys will be hard to write and process [14:28:49] For example, a constructor could accept a key like "invader" but instead get the key "Syrian opposition group" [14:29:33] It's much better if we have a subject key that has the Syrian opposition group inside of it [14:30:23] Which to accept here isn't something we could non-arbotrarily definine (re @Feeglgeef: For example, a constructor could accept a key like "invader" but instead get the key "Syrian opposition group") [18:28:15] I am interested in writing language-neutral Wikinews headlines for Wikidata items current events (e.g. X resigns from Y), maybe this would be possible as an even more constrained genre of writing. [18:38:39] Do you want to write that _on_ Wikidata items, or using Wikidata items? (re @pharosofalexandria: I am interested in writing language-neutral Wikinews headlines on Wikidata items for current events (e.g. X resigns from Y), may...) [18:39:25] Hallo [18:39:32] I am refreshing the FAQ a bit. There's this sentence there: "We hope to add at least one further programming language in 2024 (but have not yet decided which one)." [18:39:33] I suspect that it's not going to happen in 2024. Is there still a plan for such a thing in 2025? [18:56:17] Probably would mostly create new Wikidata items, maybe for 10 major news events a day. To give an idea of granularity, something like https://m.wikidata.org/wiki/Q131363194 . (re @Jan_ainali: Do you want to write that on Wikidata items, or using Wikidata items?) [19:02:42] I am thinking of the types of "headlines" on https://en.wikipedia.org/wiki/Portal:Current_events [19:09:40] I don't quite get it, are you planning to create a function for each of them? Or what did you mean with "writing" (re @pharosofalexandria: Probably would mostly create new Wikidata items, maybe for 10 major news events a day. To give an idea of granularity, something...) [19:23:41] I guess I am imagining some sort of function that takes a Wikidata item on a current event and outputs a "headline". Which is a bit like the ultimate goal of Abstract Wikipedia writing whole Wikipedia articles in a language-neutral way, but somewhat smaller in scale. (re @Jan_ainali: I don't quite get it, are you planning to create a function for each of [19:23:41] them? Or what did you mean with "writing") [19:27:49] Sure, but if your input is just one Wikidata item, and it must have a label anyway (and we would like to store in other languages too), you are not gaining much. However if you were to input two or more, you would be innovating. (re @pharosofalexandria: I guess I am imagining some sort of function that takes a Wikidata item on a current event and outputs a [19:27:49] "headline". Which is a ...) [19:30:17] Your function could be "X resigns from Y" and the function takes two Wikidata items and the language you want to generate as input. That would be pretty cool. (Even cooler if the verb also was an input) (re @Jan_ainali: Sure, but if your input is just one Wikidata item, and it must have a label anyway (and we would like to store in other language...) [19:38:33] There are currently no verb lexemes linked to Q796919 (using P9970) so we should address that first (re @Jan_ainali: Your function could be "X resigns from Y" and the function takes two Wikidata items and the language you want to generate as inp...) [19:41:00] Now there is one L48027-S2 (re @mahir256: There are currently no verb lexemes linked to Q796919 (using P9970) so we should address that first) [19:41:20] Yeah, at least functions for some typical cliche headlines, but ideally something that could take all sorts of verbs for simple sentences like this. (re @Jan_ainali: Your function could be "X resigns from Y" and the function takes two Wikidata items and the language you want to generate as inp...) [20:50:07] I think that's an interesting challenge. The newestet Newsletter should give you an idea how far away that is (spoiler: close, but not there just yet) [20:50:31] You are correct about 2024. I am hoping for 2025! (re @amire80: I am refreshing the FAQ a bit. There's this sentence there: "We hope to add at least one further programming language in 2024 (b...) [20:53:03] Newsletter 183 is out! It is again stuffed, and I particularly recommend it! [20:53:04] Contents: [20:53:06] * Sketch a path to Abstract Wikipedia [20:53:07] * Team offsite in Lisbon [20:53:10] * New tool for querying Wikifunctions [20:53:10] * Recent Changes in the software [20:53:12] * News in Types: Gregorian calendar date, Byte, Unicode code point [20:53:13] * Recording of December's Volunteers' Corner [20:53:15] * Recording of Denny's SWIB24 keynote [20:53:16] * Function of the Week: how many days between two days in the Roman year [20:53:18] https://www.wikifunctions.org/wiki/Wikifunctions:Status_updates/2024-12-12 [21:34:45] Isn't this effectively the action constructor but less broad for no real reason? (re @pharosofalexandria: Yeah, at least functions for some typical cliche headlines, but ideally something that could take all sorts of verbs for simple ...) [21:36:25] I guess we would need a separate constructor for actions of earth/nature or by humanity and such [21:37:14] "Mother nature just set the coldest recorded temperature" doesn't read well [22:46:25] Question: what version of English would Enwiki use? Wikidata allows values in both, and there is no reason to be inconsistent as all articles would be made abstractly. [22:59:34] I'm drafting something here: [[User:Feeglgeef/Abstract Wikipedia syntax proposal]]. It's a little more programming-language-like than @mahir256's proposal, but I think variables and abstract files being able to define multiple articles is important, as a lot of stuff it possibly shared. (re @vrandecic: I'd love to see your abstractification of the Battle of Aleppo [22:59:35] article. [22:59:35] About the more fine-grained names of keys, I am not so ...) [23:01:42] since the paper was published I've added a 'reference context' facility within which objects with arbitrary names can be defined [23:03:12] So, this effectively allows for variables? (re @mahir256: since the paper was published I've added a 'reference context' facility within which objects with arbitrary names can be defined) [23:18:41] yeah you might say so (link to example, select "Bokmål" in the dropdown and click 'Render!'), though there are some aspects of it that need to be ironed out : https://tools-static.wmflabs.org/bridgebot/4926a25a/file_67152.jpg