- Abstract-Wikipedia - lists.wikimedia.org

Newsletter 163: Type proposals for accessing Lexemes
by Denny Vrandečić 11 Jul '24

11 Jul '24

The on-wiki version of this newsletter can be found here: https://www.wikifunctions.org/wiki/Wikifunctions:Status_updates/2024-07-10 -- Type proposals for accessing Lexemes What is the past tense of the English verb “write <https://www.wikidata.org/wiki/Lexeme:L539>”? Since that is an irregular word, Wikifunctions would get the answer wrong for now, using the regular Function <https://www.wikifunctions.org/view/en/Z13177>, answering “writed”. Wikidata knows that the correct irregular form is “wrote <https://www.wikidata.org/wiki/Lexeme:L539#F3>”, but Wikifunctions cannot access Wikidata yet. <https://www.wikifunctions.org/wiki/File:Latin_dictionary.jpg>A multi-volume Latin dictionary, the *Totius Latinitatis Lexicon* by Egidio Forcellini (first published in 1771, this is a revised 1858–87 edition), on a table in the main reading room of the University Library of Graz. One of the goals for this quarter, as presented last week <https://www.wikifunctions.org/wiki/Wikifunctions:Status_updates/2024-07-03>, is to be able for Wikifunctions Functions to access Forms of Lexemes from Wikidata. Once that is in place, we will be able to get the correct Form from Wikidata, whether irregular or regular, and use the regular Functions for the rest. We have written and published a draft of some example Functions <https://www.wikifunctions.org/wiki/Wikifunctions:Type_proposals/Wikidata_ba…> we are aiming to support, and these have guided as in the Types that are necessary <https://www.wikifunctions.org/wiki/Wikifunctions:Type_proposals/Wikidata_ba…> to support these Functions: 1. Lexeme 2. Lexeme form 3. Wikidata item 4. Wikidata statement 5. Wikidata property Particularly the latter three will be incomplete representations of Items, Statements, and Properties, as we focus on the parts that we need for the initial access to forms. We invite you to leave comments and suggest changes to the Types we will need to create and to comment on the document as a whole. Once we have incorporated any comments, we will be creating the necessary Types, which will allow us to work on the changes in the orchestrator that will access Wikidata. Please have a look at the proposal <https://www.wikifunctions.org/wiki/Wikifunctions:Type_proposals/Wikidata_ba…>, and leave comments and improvements. Typed lists now open beyond Booleans and Strings Typed lists <https://www.wikifunctions.org/view/en/Z881> were not yet fully supporting elements of types other than Booleans <https://www.wikifunctions.org/view/en/Z40> and strings <https://www.wikifunctions.org/view/en/Z6>. We have extended typed list support to now support all types that we support, which are natural number <https://www.wikifunctions.org/view/en/Z13518> and integer <https://www.wikifunctions.org/view/en/Z16683>, sign <https://www.wikifunctions.org/view/en/Z16659>, Gregorian <https://www.wikifunctions.org/view/en/Z16098> and Igbo calendar month <https://www.wikifunctions.org/view/en/Z16927>, and day of the week <https://www.wikifunctions.org/view/en/Z17402>. In the future, whenever we introduce a new type, typed lists of that type should be automatically available. Please let us know if you have trouble using typed lists of the newly defined types. Recording of the Volunteers’ Corner now available on Commons <https://www.wikifunctions.org/wiki/File:Abstract_Wikipedia_Volunteer_Corner…> The recording of the last Volunteer’s Corner is now available as always on Wikimedia Commons <https://commons.wikimedia.org/wiki/File:Abstract_Wikipedia_Volunteer_Corner…>. Please, let us know if you have comments! Recent Changes in the software[edit source <https://www.wikifunctions.org/w/index.php?title=Wikifunctions%3AStatus_upda…> ] Last week, we spent a fair bit of time trying to debug and fix an issue with running Functions (T368892 <https://phabricator.wikimedia.org/T368892>). We think – hope! – that this is Resolved as of Tuesday 2024-07-09, but please let us know if you think things are still broken. The fix involved disabling the recent change that split out the returned meta-data from sub-calls within each Function call. We're looking into how to re-enable it without breaking production. As part of our work this Quarter, we've continued improving the logs we're making in the back-end services by adjusting our logging utility (T364413 <https://phabricator.wikimedia.org/T364413>); more work to come here soon. We also completed the re-write of the last of our browser test suites, related to connecting and disconnecting Implementations and Tests (T349836 <https://phabricator.wikimedia.org/T349836>), which was a big focus last Quarter. We've fixed the Function evaluator widget to immediately let you run a Function once an Implementation is connected, rather than needing to refresh the page (T343586 <https://phabricator.wikimedia.org/T343586>). We've re-built the object selector widget, so that when clicking away from the menu after typing into the widget will select an exact matching value if there is one, or restores the widget to the previous state if there isn't, to be consistent with user expectations (T351206 <https://phabricator.wikimedia.org/T351206>). We've fixed an oversight noticed by User:ScienceD90 <https://www.wikifunctions.org/wiki/User:ScienceD90>, and created the Z189/Validator <https://www.wikifunctions.org/view/en/Z189> and Z289/Built-in validator <https://www.wikifunctions.org/view/en/Z289> objects for Z89/HTML fragments <https://www.wikifunctions.org/view/en/Z89> (T368318 <https://phabricator.wikimedia.org/T368318>). We've added support for a number of new languages: Waali, as Z1405/wlx <https://www.wikifunctions.org/view/en/Z1405> (T368046 <https://phabricator.wikimedia.org/T368046>); Interslavic, via Z1750/isv-latn <https://www.wikifunctions.org/view/en/Z1750> and Z1924/isv-cyrl <https://www.wikifunctions.org/view/en/Z1924> (T366171 <https://phabricator.wikimedia.org/T366171>); Chitonga, as Z1925/toi <https://www.wikifunctions.org/view/en/Z1925>, and Chiluvale, as Z1926/lue <https://www.wikifunctions.org/view/en/Z1926> (T368856 <https://phabricator.wikimedia.org/T368856>); Jakaltek, as Z1927/jac <https://www.wikifunctions.org/view/en/Z1927> (T369095 <https://phabricator.wikimedia.org/T369095>); Kihunde, as Z1928/hke <https://www.wikifunctions.org/view/en/Z1928> (T369157 <https://phabricator.wikimedia.org/T369157>); Abron, as Z1929/abr <https://www.wikifunctions.org/view/en/Z1929> (T369464 <https://phabricator.wikimedia.org/T369464>); and Suret (Assyrian Neo-Aramaic), as Z1930/aii <https://www.wikifunctions.org/view/en/Z1930>. If you're curious, this work is generally triggered by desire in the wider Wikimedia movement to support and use these languages, especially via TranslateWiki. Function of the Week: Greatest common divisor (Z13612) <https://www.wikifunctions.org/view/en/Z13612> The Function of the Week for this week has been suggested by User:Autom <https://www.wikifunctions.org/wiki/User:Autom>. Thank you for the suggestion! If you want to make a suggestion, feel free to make it on the Function of the Week page <https://www.wikifunctions.org/wiki/Wikifunctions:Function_of_the_Week#Sugge…> . <https://www.wikifunctions.org/wiki/File:Euklid2.jpg>The Euclidean algorithm was probably invented before Euclid, depicted here holding a compass in a painting of about 1474. In mathematics, the greatest common divisor <https://en.wikipedia.org/wiki/Greatest_common_divisor> of two numbers is the greatest number that can divide both numbers without a remainder. This is a long-known mathematical problem, and gives us one of the oldest algorithms named after a person, the Euclidean algorithm <https://en.wikipedia.org/wiki/Euclidean_algorithm>, named after Euclid <https://en.wikipedia.org/wiki/Euclid> whose description of the algorithm is the oldest we know today. Descriptions of the algorithm that seem to have been developed independently from both India and China are also known. Greatest common divisor and the Euclidean algorithm are a good example of how to highlight the difference between a Function and an Implementation: the Euclidean algorithm is but one way to calculate the greatest common divisor. It can be also calculated by getting the two lists of the prime factors of the two arguments, and then multiplying all shared primes. And there are many other ways to get to the greatest common divisor. All these different ways to calculate the result can take more or less time. In Wikifunctions, we currently have four different implementations for the greatest common divisor: 1. One composition <https://www.wikifunctions.org/view/en/Z13639> 2. One in Python <https://www.wikifunctions.org/view/en/Z13642> 3. One in JavaScript <https://www.wikifunctions.org/view/en/Z14707>, with all three implementations so far being based on the Euclidean algorithm 4. One using the Python standard library <https://www.wikifunctions.org/view/en/Z14857>, which offers the greatest common divisor directly The first composition claims to follow the Euclidean algorithm in its name, but doesn’t actually implement it correctly. We have four tests, the pairs - 42 and 18 <https://www.wikifunctions.org/view/en/Z13613> which results in 6 - 99 and 1 <https://www.wikifunctions.org/view/en/Z13614> which results in 1 - 42 and 0 <https://www.wikifunctions.org/view/en/Z13615> which results in 42 - 0 and 0 <https://www.wikifunctions.org/view/en/Z13616> which is defined as 0 The first test uncovers that the first implementation is incorrect: the implementation results in 18, but should result in 6. Nevertheless, the composition is connected. I would suggest that we should either disconnect or fix the faulty implementation. The tests mostly cover edge cases (three of the four). It would probably be a good idea to add more normal cases (to really capture an incorrect implementation such as the composition), but also to cover even more edge cases, such as twice the same number without being 0 or 1. User:Autom points out that this would be a good opportunity to discuss the possible different speed different algorithms can have, but in the case of Wikifunctions, for now, the difference between programming languages – whether we are using Python or JavaScript or Composition – is far more significant in this case. For now, Python has a higher overhead than JavaScript, and Compositions can in many cases (but not always) be slower than an implementation in code. Accordingly, the system prefers in this case the JavaScript implementation, followed by the two Python implementations, and with the composition trailing. For the first test case, arguably the only test case that is not an edge case, the composition currently takes more than 11 seconds, the Python implementations about 4-5 seconds, and the JavaScript implementation a bit more than one second. We hope to improve our backend performance considerably for all of these implementations, so that algorithm efficiency plays a much bigger role, but we are not there yet. Thanks to User:Autom for suggesting this Function!

1 0

Newsletter 162: Quarterly planning
by Denny Vrandečić 04 Jul '24

04 Jul '24

The on-wiki version of this newsletter can be found here: https://www.wikifunctions.org/wiki/Wikifunctions:Status_updates/2024-07-03 -- Wikimedia Foundation annual plan The Wikimedia Foundation recently announced its Annual Plan for the 2024/2025 financial year <https://meta.wikimedia.org/wiki/Wikimedia_Foundation_Annual_Plan/2024-2025>, which started this week and will end on 30 June 2025. If you’re interested in what the Foundation is up to, you can find it described in a lot of detail there. This includes the work we will be doing on Wikifunctions and Abstract Wikipedia. <https://www.wikifunctions.org/wiki/File:Wikimedia_Foundation_Annual_Plan_20…> The work on Abstract Wikipedia is part of the Product & Technology department. The Objectives and Key Results (OKRs) of the Product & Technology department <https://meta.wikimedia.org/wiki/Wikimedia_Foundation_Annual_Plan/2024-2025/…> are also published as part of the annual plan. We are part of the Wiki Experiences <https://meta.wikimedia.org/wiki/Wikimedia_Foundation_Annual_Plan/2024-2025/…> objective around Encyclopedic content <https://meta.wikimedia.org/wiki/Wikimedia_Foundation_Annual_Plan/2024-2025/…> (WE2). Our work will fall under the following key result (WE2.4 <https://meta.wikimedia.org/wiki/Wikimedia_Foundation_Annual_Plan/2024-2025/…> ): *“By the end of Q2, enable Wikifunctions calls on at least one smaller language Wikipedia to provide a more scalable way to seed new content.”* Context: *“To reduce our knowledge gaps effectively, we need to improve workflows that support scalable growth in quality content, especially in smaller language communities.”* This is further broken down into three Hypotheses that will guide our work (WE2.4.1–WE2.4.3) in the first Quarter of the financial year. You can find these in the list of Hypotheses <https://meta.wikimedia.org/wiki/Wikimedia_Foundation_Annual_Plan/2024-2025/…> : 1. "If we build a prototype of Wikifunctions calls embedded within MediaWiki content, we will be ready to use MediaWiki’s async content processing pipeline and test its performance feasibility in Q2" (T261472 <https://phabricator.wikimedia.org/T261472>) 2. "If we create a design prototype of an initial Wikifunctions use case in a Wikipedia wiki, we will be ready to build and test our integration when performance feasibility is validated in Q2, as stated in Hypothesis 1" (T363391 <https://phabricator.wikimedia.org/T363391>) 3. "If we make it possible for Wikifunctions users to access Wikidata lexicographical data, they will begin to create natural language functions that generate sentence phrases, including those that can handle irregular forms. If we see an average monthly creation rate of 31 for these functions, after the feature becomes available, we will know that our experiment is successful" (T282926 <https://phabricator.wikimedia.org/T282926>) Hypotheses will be formed throughout the year, in order to actively plan work on a quarterly cadence based on our progress and things we learn. The next section shows the work we’ve planned for testing the above Q1 hypotheses, plus additional projects we think are important for supporting the themes <https://www.mediawiki.org/wiki/Abstract_Wikipedia_team#Themes_for_FY_2024-2…> of our strategic goals. Quarterly planning As we did the previous Quarter <https://www.wikifunctions.org/wiki/Wikifunctions:Status_updates/2024-05-03> and the Quarter before <https://www.wikifunctions.org/wiki/Wikifunctions:Status_updates/2024-02-07>, we are publishing our plan for the Quarter that just started. And, as you can see by the publication dates of our plans, we are getting better at planning in a timely manner. For the upcoming three months, we are planning to work on: - *Prototype Wikifunctions calls in MediaWiki <https://phabricator.wikimedia.org/T261472>*: We will have a prototype implementation that will allow function calls embedded in the wikitext of a MediaWiki page, and the result of that function call will be displayed when reading the page. We do not plan to deploy this prototype on a production wiki in this Quarter, but it will prepare us for the next. - *Design prototype for Wikifunctions use case in Wikipedias <https://phabricator.wikimedia.org/T363391>*: We will create and publish designs on how Wikipedia contributors can embed function calls while editing Wikipedia. - *Enable access to Wikidata content from Wikifunctions <https://phabricator.wikimedia.org/T282926>*: We will enable the Wikifunctions community to access Lexicographic Forms of a given Lexeme, and thus to get irregular forms from Wikidata. This will make it possible to construct grammatically correct sentence fragments using Wikifunctions. - *Performance improvements <https://phabricator.wikimedia.org/T367933>*: Currently, Wikifunctions has noticeable performance issues. We will spend time on understanding the issues better, and deploy at least one significant performance improvement. - *Production monitoring logging <https://phabricator.wikimedia.org/T368000>*: We will improve the logging on Wikifunctions. This will help us with fixing issues, particularly with regards to performance. - *Internal roadshow demoing WF and talking about AW*: We will be presenting internally about Wikifunctions and Abstract Wikipedia, with the goal of having more people at the Foundation better understand what we are doing. - *Improve About widget experience for translators and multilingual contributors <https://phabricator.wikimedia.org/T360610>*: We have shared designs for improving the About widget, particularly with regards to improving multilinguality on Wikifunctions. We will integrate community feedback and implement the design. - *Testing Wikifunctions Services with Catalyst <https://phabricator.wikimedia.org/T368002>*: We want to improve the testing of Wikifunctions, in order to find issues sooner and confidently continue development of new features. We will work with the Quality and Test Engineering team to reach that goal. - *Design outline for HTML output <https://phabricator.wikimedia.org/T368005>*: We will capture the team’s developing shared understanding on how in the future we might go beyond raw text output in Wikifunctions, written up in a document. This will guide work in the following quarters. An overview of this Quarter’s work can be seen in a brand new Phabricator board <https://phabricator.wikimedia.org/project/view/7244/>. (Almost) all the tasks listed above are represented in the column “Epics for this Quarter”. Current issues on Wikifunctions We currently experience a lot of issues running functions on Wikifunctions. We are investigating. The main task in Phabricator to follow our work is T368892 <https://phabricator.wikimedia.org/T368892>. We apologise for the inconvenience. Because of the US holiday and other schedule issues, we do not expect the situation to be resolved quickly, but expect issues to continue at least into next week. We still have not uncovered the root cause of the current problems, which makes predictions of when it will be resolved challenging. Thank you for understanding. Recent Changes in the software Last week we finished off the Quarter (and Wikimedia Foundation fiscal year) by fixing a few loose ends and preparing for this week's start of a new Quarter. As a small, but hopefully valuable, quality-of-life improvement, you can now press "Ctrl"+"↵" (or "⌘"+"↵" on a Mac) when writing in the edit summary field to trigger publication (T348182 <https://phabricator.wikimedia.org/T348182>). If you press just the Enter key ("↵"), you will be reminded of the feature in a message. This is the same shortcut and notice as used in the visual editor, the 2017 wikitext editor, and other places. When you try to publish changes to a Function definition as a Functioneer, we show a big warning that this will likely break all the attached Test cases and Implementations. However, if your Function doesn't yet have any, we now don't show that warning to you, as there's nothing to break (T326548 <https://phabricator.wikimedia.org/T326548>). If the system has an error when running a function that's caught in the middleware, such as a back-end service being down, we now show an error message to you rather than a mysterious blank space (T314267 <https://phabricator.wikimedia.org/T314267>) and don't crash the widget (T361683 <https://phabricator.wikimedia.org/T361683>), and emit a better error from the middleware in the first place (T368531 <https://phabricator.wikimedia.org/T368531>). The tables of Implementations and Test cases on Functions will now update the numbers in the pager counter when you expand to all items (T362587 <https://phabricator.wikimedia.org/T362587>). When you approve or deactivate an Implementation or Test case, we now add a basic edit summary ( T303430 <https://phabricator.wikimedia.org/T303430>). This is not yet internationalised (so whatever language you read and edit in, the history page will show the message in English), and you cannot add any comments of your own (such as "this is a great second example of how to do this in JS but is slow so won't be used"); those features may come later. We simplified how we monitor use of the function-calling API to capture "inline" definitions of Functions and their Implementations, as used for example when running Test cases or trying out a specific Implementation ( T356228 <https://phabricator.wikimedia.org/T356228> and T360369 <https://phabricator.wikimedia.org/T360369>). We upgraded our JavaScript code auto-documentation <https://doc.wikimedia.org/WikiLambda/master/js/js/index.html> to the latest version of the Wikimedia-wide standard template, v1.1.0, alongside other teams (T368081 <https://phabricator.wikimedia.org/T368081>). We, along with all Wikimedia-deployed code, are now using the latest version of the Codex UX library, v1.8.0, as of this week. It should have no user-visible changes on Wikifunctions, so please comment on the Project chat or file a Phabricator task if you spot an issue. We are excited for our transition from Minerva to the highly responsive Vector-2022 as the new mobile skin, scheduled for early next week. This update aims to enhance user experience, ensuring a more welcoming and intuitive interface for readers, while maintaining the functionality that our current editors rely on. Volunteers’ Corner on 8 July 2024 Next week, on Monday, 8th July 2024, at 17:30 UTC <https://zonestamp.toolforge.org/1720459800>, we will have our monthly Volunteers’ Corner <https://meet.google.com/xuy-njxh-rkw>. We are sorry for postponing it at the last minute from this to next week, due to several people on the team being unavailable. Unless attendees have many questions, we will follow our usual agenda of giving updates on the upcoming plans and recent activities, having plenty of time and space for your questions, and building a Function together. Looking forward to seeing you on Monday! Reminder: Input needed for design proposal towards better multi-linguality of the About widget During this Quarter, we’ve been working on improving the experience of use for multi-lingual readers and editors. We started a page for designs on Wikifunctions <https://www.wikifunctions.org/wiki/Wikifunctions:Design/About_widget_improv…>, that also hosts this particular design. We'd love to hear your thoughts about this proposal. Feel free to leave any feedback on the Discussion page <https://www.wikifunctions.org/wiki/Wikifunctions_talk:Design/About_widget_i…>. Thank you to the community members who have already given feedback, there and elsewhere. Function of the Week: get total count of a given day in a specific month and year <https://www.wikifunctions.org/wiki/File:Lunar_Year_of_Rabbit_Water_in_Manil…> Have you ever wondered how many Sundays there will be next July? Now, there’s an app for that! I mean… a Function on Wikifunctions! The Function count a day of the week in a month (Z17452) <https://www.wikifunctions.org/view/en/Z17452> takes three arguments: 1. A day of the week <https://www.wikifunctions.org/view/en/Z17402> 2. A Gregorian calendar month <https://www.wikifunctions.org/view/en/Z16098> 3. A natural number <https://www.wikifunctions.org/view/en/Z13518> representing the year The function then returns a Natural number <https://www.wikifunctions.org/view/en/Z13518> that tells you how many of the selected days of the week have or will occur in the given month and year. For example, looking at the given picture taken in Manila of a calendar page for January 2023, we can see that there have been five Sundays. If we ask the Function and enter Sunday, January, and 2023, it returns 5, as expected. The Function currently has three tests: 1. that there are 5 Thursdays in February 2024 <https://www.wikifunctions.org/view/en/Z17456> 2. that there are 4 Saturdays in February 2022 <https://www.wikifunctions.org/view/en/Z17457> 3. that there are 4 Wednesdays in February 2023 <https://www.wikifunctions.org/view/en/Z17455> And it has a single Implementation, written in JavaScript <https://www.wikifunctions.org/view/en/Z17454>. The Implementation uses JavaScript’s built-in Date class to iterate through each day of the given month, check whether it is the day we are looking for, and counting those. I really like the scope of the Function, going well beyond what standard libraries usually offer.

1 0

Newsletter 161: Welcome, Daphne!
by Denny Vrandečić 26 Jun '24

26 Jun '24

The on-wiki version of this newsletter can be found here: https://www.wikifunctions.org/wiki/Wikifunctions:Status_updates/2024-06-26 -- Welcome, Daphne! This week we are happy to welcome a new member on the Wikifunctions team. Daphne Smit is joining us as a senior software engineer, to work on all the parts and pieces of Wikifunctions, with a particular eye towards the front-end user experience. Here we have Daphne saying hello in her own words: *Thrilled to join the Abstract Wikipedia Team as a Senior Software Engineer. My coding journey started back when tables were the new thing and we had luckily almost forgotten about iFrames <https://en.wikipedia.org/wiki/HTML_element#Frames>. Previously, I worked as a freelance developer making long legal documents available to everyone. Now, it’s time to step up my game and be part of a movement making knowledge freely available to everyone. I’m ready to bring my passion for problem-solving and user-centric design to Wikimedia.* <https://www.wikifunctions.org/wiki/File:Hagelslag_chocolate_sprinkles.jpg> *I’ve just moved from the bustling canals of Amsterdam to the cozy charm of Zwolle <https://en.wikipedia.org/wiki/Zwolle>, a Hanseatic City <https://en.wikipedia.org/wiki/Hanseatic_League> that has already won me over. When I'm not crafting impactful user experiences, you’ll find me playing basketball, tackling bouldering walls, or surfing the waves in Portugal or France. I live with my cat, Silver, who occasionally assists in debugging by walking across my keyboard. I also love hiking, with favorites like the Tongariro Crossing <https://en.wikipedia.org/wiki/Tongariro_Alipne_Crossing> in New Zealand and the Pico do Areeiro <https://en.wikipedia.org/wiki/Pico_do_Areeiro> - Pico Ruivo <https://en.wikipedia.org/wiki/Pico_Ruivo> trek in Madeira.* *I’m excited to start learning and contributing to this great project, where Abstract Wikipedia <https://en.wikipedia.org/wiki/Abstract_Wikipedia> and Wikifunctions team up like peanut butter and hagelslag <https://en.wikipedia.org/wiki/Hagelslag> (yes we do that in The NL).* Please join me in welcoming Daphne to the team! Input needed: Design proposal towards better multi-linguality of the About widget During this Quarter, we’ve been working on improving the experience of use for multi-lingual readers and editors. Wikifunctions currently provides a set of features that let translators and other multi-lingual editors contribute in their own language. Despite being possible to add content in multiple languages, the process is not as simple as it could be. Moreover, sometimes Wikifunctions displays content in a language that readers don’t know, or can’t speak (T359772 <https://phabricator.wikimedia.org/T359772>). The goals of this update that you'll find at the page on the About widget’s improvements <https://www.wikifunctions.org/wiki/Wikifunctions:Design/About_widget_improv…>, are: - for readers (and function users), to confidently display content in languages that each person is familiar with, and make it clear when content in their UI language is not available to provide a potential entry point for contribution. - for editors, to streamline the translation process, making it possible to add multiple translations with ease in a single publishing step. We started a page for designs on Wikifunctions <https://www.wikifunctions.org/wiki/Wikifunctions:Design>, that also hosts this particular design. We'd love to hear your thoughts about this proposal. Feel free to leave any feedback on the Discussion page. Volunteers’ Corner on July 1st, 2024 Next week, on Monday, July 1st, 2024, at 17:30 UTC <https://zonestamp.toolforge.org/1719855000>, we will have our monthly Volunteers’ Corner <https://meet.google.com/xuy-njxh-rkw>. Unless you have many questions, we will follow our usual agenda, of giving updates on the upcoming plans and recent activities, having plenty of time and space for your questions, and building a Function together. Looking forward to seeing you on Monday! Recent Changes in the software This week we've been making minor improvements to complete the Quarter's work. We landed a fix to last week's improvement to how "enum" Types (ones with an identity key, like Month) are displayed, in order to show the special radio control for Booleans, rather than the drop-down, and rushed this out to production ahead of the release to avoid disruption (T367159 <https://phabricator.wikimedia.org/T367159>). We identified a change in behaviour in the back-end services, and for now have disabled the failing test whilst we investigate and fix it; we do not think this should directly impact community-written Test cases, but please report if you're affected (T368041 <https://phabricator.wikimedia.org/T368041>). Our newest team member, Daphne (above) landed her first patches with us, one to disable the code editor control when creating a new Implementation until you've selected the language (T343635 <https://phabricator.wikimedia.org/T343635>), and another to fix some lint errors in our jest test structure code. We also adjusted the control flow of our Object editing database access layer, avoiding the deprecated MediaWiki code that assumes global language state. We've added infrastructure to track the relationships between Objects in a "secondary" database table (T357552 <https://phabricator.wikimedia.org/T357552>). Though this for now is mostly meant so we can report better on what Types are used in Function definitions and how often, to help the community focus attention where it will have the most impact, we expect to expand this feature for tracking in future. Finally, we fixed the code for publishing new Objects, making the substitution of 'Z0' to the new ZID when creating new Type converters just like for Implementations (T367168 <https://phabricator.wikimedia.org/T367168>), which will allow for better community control of custom Types in the future. New Type: Day of the week We released a new Type <https://www.wikifunctions.org/view/en/Z17402>, an enumeration, for the seven days of the week <https://www.wikifunctions.org/view/en/Z17402>, implementing the community proposal <https://www.wikifunctions.org/wiki/Wikifunctions:Type_proposals/Day_of_the_…> . We are still soliciting proposals for months from other calendars, and, if relevant, for weekdays of other calendars. You can use the proposals for the Gregorian calendar month <https://www.wikifunctions.org/wiki/Wikifunctions:Type_proposals/Gregorian_c…> and the Igbo calendar month <https://www.wikifunctions.org/wiki/Wikifunctions:Type_proposals/Igbo_calend…> as templates. We would very much prefer proposals from people who know a given calendar very well, than trying to build it ourselves based on the relevant Wikipedia articles. There is now also a proposal for calendar dates <https://www.wikifunctions.org/wiki/Wikifunctions:Type_proposals/Gregorian_c…> (of the proleptic Gregorian calendar, to be precise) and related Types. Feedback is very welcome. Function of the Week: subtract integers Last week we introduced Integers <https://www.wikifunctions.org/wiki/Wikifunctions:Status_updates/2024-06-20>, Natural numbers with signs, so that we can finally represent negative numbers too! The community immediately seized the opportunity to create plenty of new Functions, and now we have more than three dozen Functions dealing with Integers. Thank you all! Many of the Functions are versions of the Functions with Natural numbers, now extended to Integers: addition, multiplication, and number comparisons are now all available for the whole Integer range. The one Function that highlights the Integer range the best is the subtraction Function: subtraction with Natural numbers is floored on zero <https://www.wikifunctions.org/view/en/Z13569>. But now, we have an Integer-based subtraction Function <https://www.wikifunctions.org/view/en/Z17111>, and we can subtract a bigger number from a smaller number (and thus yield a negative number as the result <https://www.wikifunctions.org/view/en/Z17117>). Accordingly, that’s one of the three Test cases. The other two Tests are subtracting a smaller number from a bigger number, resulting in a positive number <https://www.wikifunctions.org/view/en/Z17115>, and finally subtracting a negative number from a number <https://www.wikifunctions.org/view/en/Z17118>. Besides three Tests we also have three Implementations. Two are in code: one in Python <https://www.wikifunctions.org/view/en/Z17114>, one in JavaScript <https://www.wikifunctions.org/view/en/Z17127>, both simply using the binary '-' operator in the given languages. My favourite Implementation, as usual, is the composition <https://www.wikifunctions.org/view/en/Z17248>: it uses addition <https://www.wikifunctions.org/view/en/Z16693>, but negates <https://www.wikifunctions.org/view/en/Z17186> the second argument before adding it up. I.e. when you want to calculate 2 - -7, it instead negates the second argument, turning the -7 into a 7, and then adds the two numbers up, calculating 2 + 7. Another interesting variant Function is a subtraction Function for two Natural numbers <https://www.wikifunctions.org/view/en/Z17315> that results in an Integer, and thus has no constraints on the input arguments.

1 0

Newsletter #160: New Type - Integer
by Denny Vrandečić 21 Jun '24

21 Jun '24

The on-wiki version of this newsletter can be found here: https://www.wikifunctions.org/wiki/Wikifunctions:Status_updates/2024-06-20 -- New Type: Integers We are happy to announce a new Type: Integer <https://www.wikifunctions.org/view/en/Z16683>. Integers are the whole positive and negative numbers, and zero. <https://www.wikifunctions.org/wiki/File:Background_azul_n%C3%BAmeros_entero…> Integers will allow us to have functions that increase our coverage of mathematical functions, *e.g.* our current subtraction function <https://www.wikifunctions.org/view/en/Z13569> floors at zero. This will also help us with figuring out how to deal with overlapping Types, since the Integer <https://www.wikifunctions.org/view/en/Z16683> and the Natural numbers <https://www.wikifunctions.org/view/en/Z13518> Types are closely related. The Integer Type is also our first complex Type to be introduced since launch. A complex Type is a Type that has more than a single Key, and thus benefits particularly from the parser and renderer systems. We know that the parser and renderer makes them a bit slower. We are working on improving the system performance. We invite you to build functions with the new type and are excited to see how it will work. Recent Changes in the software We're about to finish the Quarter (April–June 2024), and so a lot of the work recently (and for the next two) is around completing those eight Epics <https://www.wikifunctions.org/wiki/Wikifunctions:Status_updates/2024-05-03>, and setting us up for the next Quarter (July–September 2024), which we have planned out this week. We will report on the results of the planning soon. As part of our long-term work on Type support, when prompted to enter a "enum" Type (*i.e.*, one with Identity values, like Z16098/Gregorian calendar month <https://www.wikifunctions.org/view/en/Z16098>), you'll have a select drop-down control, instead of a text box where you have to search or know what the valid options are (T366628 <https://phabricator.wikimedia.org/T366628>). We improved the front-end experience when creating Type converters related to Identity keys, and generally cleaned up the code in this area (T367159 <https://phabricator.wikimedia.org/T367159>), and made it more possible to use the UI to create Type converters rather than needing to use the API ( T367168 <https://phabricator.wikimedia.org/T367168>). We split out the rights for editing type converters, with everyone able to create and edit them when new or unconnected, but (like with Functions) having them locked-down once they're 'live', so that people can't accidentally break all uses of a Type (T367270 <https://phabricator.wikimedia.org/T367270>). You can see the updated documentation on our User rights documentation <https://www.mediawiki.org/wiki/Help:Wikifunctions/User_rights>. We also updated the definitions of Z46/Type converter to code <https://www.wikifunctions.org/view/en/Z46> and Z64/Type converter from code <https://www.wikifunctions.org/view/en/Z64> to mark their 'identity' keys (Z46K1 and Z64K1 respectively) as identity keys via setting Z3K4/is identity <https://www.wikifunctions.org/view/en/Z3> to true (T359233 <https://phabricator.wikimedia.org/T359233>). On the Epic related to improving our tests (T363389 <https://phabricator.wikimedia.org/T363389>), we continued our work on re-writing our browser test suites, and have now completed all but the last suite, related to connecting and disconnecting Testers and Implementations from Functions, which we will work on next (T349836 <https://phabricator.wikimedia.org/T349836>). Related to the Epic for giving meta-data for function sub-calls (T363384 <https://phabricator.wikimedia.org/T363384>), we added front-end support for showing the information (T363396 <https://phabricator.wikimedia.org/T363396>), and we're preparing to deploy the latest version of the back-end services with this information (T366498 <https://phabricator.wikimedia.org/T366498>), and we hope to enable this feature soon (T366829 <https://phabricator.wikimedia.org/T366829>). The last task this Quarter for better UX related to language (T363383 <https://phabricator.wikimedia.org/T363383>) was to make it so that short descriptions on Objects will now wrap their contents if someone adds a long word with no character breaks, rather than expanding into the content ( T360510 <https://phabricator.wikimedia.org/T360510>). In preparation for next Quarter's work, as part of the Wikimedia Foundation Annual Plan for 2024–25 <https://meta.wikimedia.org/wiki/Wikimedia_Foundation_Annual_Plan/2024-2025/…> to "*enable [cross-wiki] Wikifunctions calls on at least one smaller language Wikipedia*" (WE2.4 <https://meta.wikimedia.org/wiki/Wikimedia_Foundation_Annual_Plan/2024-2025/…>), we moved our very early prototype code for making Wikifunctions calls into its own extension, WikifunctionsClient <https://gerrit.wikimedia.org/g/mediawiki/extensions/WikifunctionsClient>. Expect more on this soon! Beyond the Quarterly work, we landed a few bug fixes and improvements. We fixed a bug where new (empty) Objects would run their Renderer function, even though no input had been given yet (T367157 <https://phabricator.wikimedia.org/T367157>). We improved the accessibility of close-dialog controls, using a better, more specific message for screen readers. We updated support for several languages in Wikifunctions, correcting codes to align with the industry standard BCP47 codes as the primary codes and relegating the MediaWiki bespoke non-standard ones to secondary. This means that Z1755/sgs <https://www.wikifunctions.org/view/en/Z1755> now has 'bat-smg' as secondary, rather than the other way around (T360672 <https://phabricator.wikimedia.org/T360672>); similarly, Z1231/de-x-formal <https://www.wikifunctions.org/view/en/Z1231> now has 'de-formal' (T360673 <https://phabricator.wikimedia.org/T360673>) and Z1664/ro-cyrl-md <https://www.wikifunctions.org/view/en/Z1664> has 'ro' (T360674 <https://phabricator.wikimedia.org/T360674>); and Z1508/als <https://www.wikifunctions.org/view/en/Z1508> has had the old Z1405 'gsw' object (T360675 <https://phabricator.wikimedia.org/T360675>) and Z1726/egl <https://www.wikifunctions.org/view/en/Z1726> the old Z1750 'eml' object ( T360678 <https://phabricator.wikimedia.org/T360678>) merged in, with the old ones deleted. Some of the tasks previously worked on as "Fix-It" to address technical debt landed. We have tweaked many parts of our front-end testing code to reduce the number of warnings from the Vue framework, and so make it easier to spot actual issues (T325412 <https://phabricator.wikimedia.org/T325412>). We have audited all the inline "TODO" comments in our PHP code, and ensured that they are still relevant, and if so have a Phabricator task (T296401 <https://phabricator.wikimedia.org/T296401>). We found and fixed a long-standing typo in our maintenance database cache deletion code which we think should improve language-related bugs (T343164 <https://phabricator.wikimedia.org/T343164>, T357702 <https://phabricator.wikimedia.org/T357702>), and added some more testing to avoid this issue in future. We led the pack across Wikimedia, upgrading our code linting tools (stylelint-config-wikimedia to 0.17.2, and eslint-config-wikimedia to 0.28.2), which included migrating from explicit to arrow function style. This is the new Wikimedia-wide standard, now that Internet Explorer support has finally been dropped. Our thanks to our colleague Ed Sanders, principal for the Editing team, for his leadership and help in this regard. We, along with all Wikimedia-deployed code, are now using the latest version of the Codex UX library, v1.7.0, as of this week. It should have no user-visible changes on Wikifunctions, so please comment on the Project chat or file a Phabricator task if you spot an issue. Function of the Week: following month in the Igbo calendar Last week, we introduced <https://www.wikifunctions.org/wiki/Wikifunctions:Status_updates/2024-06-13> the Igbo calendar month Type <https://www.wikifunctions.org/view/en/Z16927>, and today we have half a dozen Functions with that Type. One of the basic Functions for calendars is a Function to figure out the following <https://www.wikifunctions.org/view/en/Z16972> and previous months <https://www.wikifunctions.org/view/en/Z16990> given a certain month. Both of these Functions exist now for the Igbo calendar months in Wikifunctions. The following month function <https://www.wikifunctions.org/view/en/Z16972> offers six tests, including the edge case of the last month of the calendar year being followed by the first one <https://www.wikifunctions.org/view/en/Z16989>. The Function has three implementations, and each of them works slightly differently: - One in Python <https://www.wikifunctions.org/view/en/Z17016>, which uses the fact that we convert the months to numbers. It first checks whether the input argument is the last month, 13 (the Igbo calendar has 13 months), in which case it returns the first one, or else it just adds 1. - One in JavaScript <https://www.wikifunctions.org/view/en/Z16982>, which also uses the fact that we convert the months to numbers, adds 1, but then calculates modulo 13 in order to deal with the overflow. - One as a composition <https://www.wikifunctions.org/view/en/Z16980>, which turns the input month into a number <https://www.wikifunctions.org/view/en/Z16973>, increments the number by one <https://www.wikifunctions.org/view/en/Z13578>, and turns that result back into a month <https://www.wikifunctions.org/view/en/Z16955>. Because that last Function is robust against an overflow and underflow by one, we relegate taking care about the overflow to that Function. Thanks to the community for diligently creating new Functions when a new Type comes out! You are amazing!

1 0

Newsletter 159: New Type: Igbo calendar months
by Denny Vrandečić 13 Jun '24

13 Jun '24

New Type: Igbo calendar months We are happy to announce another new Type this week: an enumeration for the thirteen months of the Igbo calendar <https://en.wikipedia.org/wiki/Igbo_calendar> (Igbo calendar month (Z16927) <https://www.wikifunctions.org/view/en/Z16927>). <https://www.wikifunctions.org/wiki/File:Nsibidi_moon.jpg>The symbol for the Moon in Nsibidi <https://en.wikipedia.org/wiki/Nsibidi>, an Igbo system in use since the 5th century CE The Type follows the Type proposal <https://www.wikifunctions.org/wiki/Wikifunctions:Type_proposals/Igbo_calend…> led by Dolphyb <https://www.wikifunctions.org/wiki/User:Dolphyb>. We created the thirteen months of the Igbo calendar: Ọnwa Mbụ <https://www.wikifunctions.org/view/en/Z16928>, Ọnwa Abụo <https://www.wikifunctions.org/view/en/Z16929>, Ọnwa Ife Eke <https://www.wikifunctions.org/view/en/Z16930>, Ọnwa Anọ <https://www.wikifunctions.org/view/en/Z16931>, Ọnwa Agwụ <https://www.wikifunctions.org/view/en/Z16932>, Ọnwa Ifejiọkụ <https://www.wikifunctions.org/view/en/Z16933>, Ọnwa Alọm Chi <https://www.wikifunctions.org/view/en/Z16934>, Ọnwa Ilo Mmụọ <https://www.wikifunctions.org/view/en/Z16935>, Ọnwa Ana <https://www.wikifunctions.org/view/en/Z16936>, Ọnwa Okike <https://www.wikifunctions.org/view/en/Z16937>, Ọnwa Ajana <https://www.wikifunctions.org/view/en/Z16938>, Ọnwa Ede Ajana <https://www.wikifunctions.org/view/en/Z16939>, and Ọnwa Ụzọ Alụsị <https://www.wikifunctions.org/view/en/Z16940>. A first function was also introduced, to check two Igbo months for equality <https://www.wikifunctions.org/view/en/Z16945>. We are looking forward to seeing more Type proposals <https://www.wikifunctions.org/wiki/Wikifunctions:Type_proposals> for calendar months, particularly for other calendar systems that are currently in use, and that are relevant to Wikipedia. In related news about new Types, we are still working on some final tasks that will enable the use of the (signed) integer Type. Presentation on Wikifunctions and Abstract Wikipedia in Munich Next Thursday, June 20, 2024, at 19:00 local time in Munich, Germany,, Kristbaum <https://www.wikifunctions.org/wiki/User:Kristbaum> will be presenting on Wikifunctions and Abstract Wikipedia. Attendance is free, but they ask for an informal registration either via Email or on the wiki page of the event: - WikiMUC: Sind Wikifunctions und Abstract Wikipedia die Zukunft der Wikipedia? <https://de.wikipedia.org/wiki/Wikipedia:WikiMUC/2024-06-20_Sind_Wikifunctio…> Recent Changes in the software We added the relevant rights for creating and editing instances of 'enum' Types like Z16098/Month <https://www.wikifunctions.org/view/en/Z16098> and Z16659/Sign <https://www.wikifunctions.org/view/en/Z16659> (T366610 <https://phabricator.wikimedia.org/T366610>). For now, alongside Type creation, these rights are reserved for Function Maintainers (and Wikifunctions staff); as always, all users can add and edit their labels, short descriptions, and aliases. We landed a few patches written last week as part of our regular "Fix-It" technical debt clearance initiative. We completed adding test coverage for our local Vue components <https://doc.wikimedia.org/cover/WikiLambda/lcov-report/>, now covering the CodeEditor one alongside the others (T358207 <https://phabricator.wikimedia.org/T358207>). We moved a handful of our legacy global functions out of the global JS namespace (T362925 <https://phabricator.wikimedia.org/T362925>). We updated some of our browser tests to use i18n-independent selectors, as part of work to make them more stable (T349836 <https://phabricator.wikimedia.org/T349836>). Function of the Week: do these charges electrostatically attract? Last week, we announced the Sign Type <https://www.wikifunctions.org/wiki/Wikifunctions:Status_updates/2024-06-06>, and I foolishly assumed that there wouldn’t be too many Functions for it. That was not meant as a challenge, but there are now more than a dozen Functions dealing with Signs. <https://www.wikifunctions.org/wiki/File:Opposites_attract.svg> In order to recognize that work we selected one of these as the Function of the Week: do these charges electrostatically attract? (Z16781) <https://www.wikifunctions.org/view/en/Z16781>, do these charges electrostatically attract? The Function takes two inputs of type Sign <https://www.wikifunctions.org/view/en/Z16659> and returns a Boolean <https://www.wikifunctions.org/view/en/Z40>. The inputs are the two charges which are checked for whether they attract each other, or not. As the saying goes, opposites attract <https://en.wikipedia.org/wiki/Opposites_Attract_(disambiguation)>: negative and positive attract each other, and if one value is negative and the other positive, the answer is true. In all other cases, it is false. The Function has four Tests, one with an example of where it attracts – negative and positive <https://www.wikifunctions.org/view/en/Z16783> – and three examples that do not: positive and positive <https://www.wikifunctions.org/view/en/Z16784>, positive and neutral <https://www.wikifunctions.org/view/en/Z16785>, and neutral and neutral <https://www.wikifunctions.org/view/en/Z16786>. For this Function, that’s a nice, balanced set of Tests. The Function currently has one Implementation, a composition <https://www.wikifunctions.org/view/en/Z16782>: it relies on multiplying the two input Signs <https://www.wikifunctions.org/view/en/Z16728> and checking whether the result of that multiplication is negative <https://www.wikifunctions.org/view/en/Z16662> using the same Sign <https://www.wikifunctions.org/view/en/Z16667> Function. When multiplying, you only get a negative result if one of the inputs is negative and the other is positive. And that’s what the Function is checking for. The implementation seems quite a bit smarter than the one I would have made: using if <https://www.wikifunctions.org/view/en/Z802> conditions to check whether one result is negative and the other positive, or the other way around, and return false <https://www.wikifunctions.org/view/en/Z42> otherwise. This is a Function I certainly did not have in mind when we introduced the Sign Type. I am happy to be surprised with the creativity of the community.

1 0

Newsletter #157: A single singular or a plurality of plurals?
by Denny Vrandečić 31 May '24

31 May '24

The on-wiki version of this newsletter can be found here: https://www.wikifunctions.org/wiki/Wikifunctions:Status_updates/2024-05-30 -- A single singular or a plurality of plurals? <https://www.wikifunctions.org/wiki/File:Latin_dictionary.jpg>18th century Latin dictionary We are working towards functions being able to access data from Wikidata. The first use-case we are aiming for is to access the lexicographic Forms of a Lexeme, given a Lexeme ID. For example, consider a function that creates sentences such as *“There are four apples.”*, where both the number *“four”* as well as the noun *“apple”* are arguments to the function that creates the sentence. What should the Functions for accessing Lexeme Forms look like? If you have ideas to sketch that out, please go ahead, unbound by technical limitations. We’ll look forward to seeing your ideas and using them as inspiration in order to mold what we can achieve technically on top of the platform we have. In the above example, we could have a Function that creates *“four”* based on the natural number 4, and *“apples”* based on the Lexeme ID L3257 <https://www.wikidata.org/wiki/Lexeme:L3257>. The Lexeme has two forms: L3257-F1 being *“apple”*, marked with the grammatical feature singular <https://www.wikidata.org/wiki/Q110786>, and L3257-F2 being *“apples”*, marked with the grammatical feature plural <https://www.wikidata.org/wiki/Q146786>. In order to get the right Form, we can either look up the relevant Form Id manually, which will hardly scale, or we use the grammatical features to request the right form. In other words, there could be a Function e.g. "return form" which takes a Lexeme ID and a list of grammatical features and returns all matching Forms. return form(L3257, [plural]) would return *“apples”*. Accordingly, for the Estonian verb *“amüseerima”* (to amuse), we would make the call return form(L350582, [third person, plural, present tense, indicative]) to return *“amüseerivad”*. One question we will have is whether the English plural and the Estonian plural should be the same object in Wikifunctions, or whether they should be two different Objects. In Wikidata, the answer is that they are (in general) the same Item, plural <https://www.wikidata.org/wiki/Q146786> – the form for more than one, or zero, depending on the language. There are several languages which have other grammatical numbers, such as *paucal*, *dual*, *trial*, and others, which are not used in English and other languages that only have the two. Even for languages that use only two values, there are differences; for instance, English uses the plural form for zero ('*He ate zero eggs*'), whereas French uses the singular ('*Il a mangé zero œufs*', or more idiomatically '*Il n'a mangé aucun œuf'*). In Wikifunctions, we could choose to have individual enumerations for each language, which would have the advantage allowing for simpler, but different user interfaces for each language, where we display only the features relevant to a given language: so that for English we don’t show the other number classes, or ask for grammatical features which are not relevant for the language. There are several different solutions, and the following list is not even exhaustive: 1. a single enumeration of all grammatical features, as in Wikidata 2. shared enumerations for the groups of grammatical features, just as cases, numbers, etc. 3. enumerations for the groups of grammatical features that actually appear for languages, i.e. one shared enumeration for all languages that use only the singular and plural 4. one enumeration for each language, and for each group of grammatical feature We have been discussing this question in the Natural Language Generation Special Interest Group. Another solution that was mentioned was to use sub-typing, for example to have “English numbers” be a subtype of the “Grammatical numbers” type, with shared elements. But without Wikifunctions having support for sub-types, this isn’t currently an option. It is very likely that we won’t be able to resolve this issue fully until we have actually built it and found in practice how it works out. It might even be that we change some of the decisions later, as we discover patterns of Wikifunctions usage that make Wikifunctions friendlier and easier to use. But it would be good to start thinking about what we would like to aim for and what the principles are along which we align our design decisions. Recent Changes in software The big piece of work that we landed this week was a comprehensive re-build of the front-end code for how we show labels. As is standard with MediaWiki-based tools, if your language was set to French, but there wasn't a label in French and was one in English, we show the fallback English label. Previously, we were resolving the label into a string based on your view language and displaying that, which mostly worked, but meant that the label would not be hinted for language or directionality when they were different from the context. We now fully pass down the label's language, and thus directionality, in all places (T343464 <https://phabricator.wikimedia.org/T343464>, T342661 <https://phabricator.wikimedia.org/T342661>). In the future, we may adjust how fallback labels like this are displayed, possibly to explain inline what language is being shown, and/or give a call-to-action to translate the label; you can add ideas to the top-level task (T343460 <https://phabricator.wikimedia.org/T343460>). Alongside the above work, we adjusted the function-calling API code to correctly pass along the activity tracing headers (T365053 <https://phabricator.wikimedia.org/T365053>), and made a few code quality improvements. Additionally, we have been investigating performance-related issues with the back-end services, and hope to have more to report soon. Function of the Week: days in month when not a leap year <https://www.wikifunctions.org/wiki/File:Month_-_Knuckles_(en).svg> Are you using your knuckles <https://en.wikipedia.org/wiki/Knuckle_mnemonic> whenever you try to remember how many days are in a given calendar month? No need for that anymore! Welcome the function days in month when not a leap year <https://www.wikifunctions.org/view/en/Z16332> (Z16332). OK, admittedly, your knuckles may often be more readily available than access to Wikifunctions, but let’s ignore that wrinkle for a moment. The new Function takes a Gregorian calendar month <https://www.wikifunctions.org/view/en/Z16098>, which we have introduced as a new Type last week <https://www.wikifunctions.org/wiki/Wikifunctions:Status_updates/2024-05-22>, and returns a natural number <https://www.wikifunctions.org/view/en/Z13518>, depending on how many days that month has in a year that is not a leap year (a complementary function for leap years <https://www.wikifunctions.org/view/en/Z16332> also exists). The function has twelve Tests, one for each month (making it a completely covered Function), and currently two Implementations, both in Python: - One Implementation using a lookup in a Python dictionary <https://www.wikifunctions.org/view/en/Z16347>, where for each month number we have the number of days, - One Implementation using an unusual formula <https://www.wikifunctions.org/view/en/Z16329> that I’ve never seen before One nice thing with a good, or even complete test coverage, like in this case, is that you don’t even have to understand or prove the formula in order to trust it (although that sure doesn’t hurt): you can simply check that all test cases are what you would expect, and that they pass (as they do). Thanks to the community for so swiftly adopting the new Type, and for having created more than a dozen new Functions using the new Type.

2 1

Newsletter #156: New Type: Gregorian calendar months
by Denny Vrandečić 22 May '24

22 May '24

The on-wiki version of this newsletter can be found here: https://www.wikifunctions.org/wiki/Wikifunctions:Status_updates/2024-05-22 -- New Type: Gregorian calendar months <https://www.wikifunctions.org/wiki/File:Wheel-of-life-mother-nature-forrer-…>*The Wheel of Mother Nature: This is Her Image*, France, ca. 1400 CE. Atop the wheel is Time, her four wings the seasons, with the months as feathers. We are proud to announce our initial, flagship enumeration Type: Gregorian calendar months <https://www.wikifunctions.org/view/en/Z16098>. Gregorian calendar months are an enumeration of twelve values, starting with January <https://www.wikifunctions.org/view/en/Z16101> and February <https://www.wikifunctions.org/view/en/Z16102> and going all the way to November <https://www.wikifunctions.org/view/en/Z16111> and December <https://www.wikifunctions.org/view/en/Z16112>. For testing purposes, we created two functions for now: "same month <https://www.wikifunctions.org/view/en/Z16137>", discussed below as the Function of the Week, and "following month <https://www.wikifunctions.org/view/en/Z16136>", which returns the month that follows the given month. We are curious to see what kind of functions you will build with that. Unlike with Natural numbers <https://www.wikifunctions.org/view/en/Z13518>, we don’t expect to see a large number of new functions immediately – but we would be very happy to be surprised! Eventually, Gregorian calendar months will be used as a building block for dates of the Gregorian calendar, increasing the number of functions this type will be used with. Thanks to the Wikifunctions community for being a great sport! When we created this Type, we merely put a small plea into the English description, asking not to use it yet. And indeed, this wish was mostly respected, which allowed us to fix one more bug before we rolled it out today. Please let us know if there are problems or wrinkles with using the new Type. We will keep monitoring the situation as best as we can. We also hope to swiftly add more enumeration Types, particularly for month enumerations for other calendar systems. It would be great if you could write proposals for those <https://www.wikifunctions.org/wiki/Wikifunctions:Type_proposals>, so that in a few weeks' time we can start creating them. If major issues are not discovered, and any minor issues resolved, we plan to move on with more enumerations, first for calendar months and then for other domains, in as early as two or three weeks. If you have any questions, please feel free to ask! Thank you for your coöperation and help with this rollout. Recent Changes in the software Our main work this Quarter is around the eight areas <https://www.wikifunctions.org/wiki/Wikifunctions:Status_updates/2024-05-03> we set out earlier. For enumeration support in Types, as mentioned above, we rolled out a fix for the production services, which was about not eagerly evaluating type references in Objects when they're marked as identities in their Type. With this, as discussed above, we hope that the feature work here is complete for the Quarter (T363390 <https://phabricator.wikimedia.org/T363390>), and have been focussing on the other areas. Our most visible next set of changes will be improvements to how labels are shown in different languages (T363383 <https://phabricator.wikimedia.org/T363383>). The first improvement here is that you can now use MediaWiki's fake language code qqx as a view language, which will help you translate Wikifunctions better, by letting you identify Object keys and interface messages; you can see this by visiting view/qqx/Z801 <https://wikifunctions.org/view/qqx/Z801> (T359999 <https://phabricator.wikimedia.org/T359999>). In other priority areas, we continued our work on streamlining, simplifying, and otherwise improving our browser tests (T349836 <https://phabricator.wikimedia.org/T349836>) as part of our general testing improvements work (T363389 <https://phabricator.wikimedia.org/T363389>). We have been adjusting our back-end services' control and information flow to make the work to better report sub-call meta-data possible (T363384 <https://phabricator.wikimedia.org/T363384>). We have also been examining service performance and management issues within our work to better monitor production (T363387 <https://phabricator.wikimedia.org/T363387>). Outside of our priority work, we tweaked the load-order of our front-end code, to avoid occasional race-conditions in our dependencies on MediaWiki. Our production services now run on Node 20, up from Node 18, and have had various minor bug fixes deployed. Our database-accessing code in MediaWiki was made more modern, now using the expression builder abstraction layer in most places (T350993 <https://phabricator.wikimedia.org/T350993>). Thank you to Umherirrender <https://www.wikifunctions.org/wiki/User:Umherirrender> for this, and many other improvements for Wikifunctions and the wider Wikimedia ecosystem, over the years. We tweaked our languages, updating Z1221/nan <https://www.wikifunctions.org/view/en/Z1221> to merge in zh-min-nan; our particular thanks to Winston Sung <https://www.wikifunctions.org/wiki/User:Winston_Sung> for their leading work on cleaning up our language support (T348370 <https://phabricator.wikimedia.org/T348370>). We, along with all Wikimedia-deployed code, are now using the latest version of the Codex UX library <https://www.mediawiki.org/wiki/Codex>, v1.6.0, as of this week. It should have no user-visible changes on Wikifunctions, so please comment on the Project chat or file a Phabricator task if you spot an issue. Call for Functions: Spell out the number! Last week, we called for you to create functions which spell out numbers <https://www.wikifunctions.org/wiki/Wikifunctions:Status_updates/2024-05-15> in different languages, and you have answered. As of now, functions for fifteen languages have been set up: Bengali, Croatian, English, French, German, Igbo, Klingon, Low German, Malay, Moroccan Arabic, Polish, Ukrainian, Standard Arabic, Swedish, and Láadan. A page for this project <https://www.wikifunctions.org/wiki/Wikifunctions:Cardinal_numbers> has been started, and we are looking forward to seeing the project develop. If you need any help, feel free to ask! Wikifunctions on Beta Cluster broken For the last week or two, Wikifunctions on Beta Cluster has been failing. We are investigating, but are a bit of a loss of what the issue is. We currently have no prediction when this will be fixed. Function of the Week: Same month Since we just introduced a new Type, Gregorian calendar month <https://www.wikifunctions.org/view/en/Z16098>, we also created two functions. One very useful function for every new Type is the identity function, which checks whether two given values are the same. We named the function "same month <https://www.wikifunctions.org/view/en/Z16137>". It takes as input two arguments of our new Type for Gregorian calendar months, and returns a Boolean <https://www.wikifunctions.org/view/en/Z40> value: true <https://www.wikifunctions.org/view/en/Z41>, if the two months are the same, and false <https://www.wikifunctions.org/view/en/Z42> otherwise. The identity function is the most basic function for all enumerations, and it allows checking for the value of the enumeration. We can see it in action in the composition for "following month" <https://www.wikifunctions.org/view/en/Z16148>, using eleven ifs <https://www.wikifunctions.org/view/en/Z802> sequentially, checking the argument against all possible values and then returning the appropriate answer (that particular implementation times out currently, though, an issue we are working on). For "same month", we created six tests (out of a possible 144 tests, which would be a bit excessive). We created three pairs of text, each pair with a test that should return true, and one that should return false. The three pairs in turn are once using the month as a literal, once as a reference, and once a mixed function call: 1. Checking that two literals are the same <https://www.wikifunctions.org/view/en/Z16138> 2. Checking that two literals are different <https://www.wikifunctions.org/view/en/Z16139> 3. Checking that two references are the same <https://www.wikifunctions.org/view/en/Z16140> 4. Checking that two references are different <https://www.wikifunctions.org/view/en/Z16141> 5. Checking that a literal and a reference are the same <https://www.wikifunctions.org/view/en/Z16228> 6. Checking that a literal and a reference are different <https://www.wikifunctions.org/view/en/Z16229> There are two implementations for the function, one in Python <https://www.wikifunctions.org/view/en/Z16143> and one in JavaScript <https://www.wikifunctions.org/view/en/Z16142>. And although both of them look very different – they use the identity operator of the given language to compare the two values – they work quite a bit differently for the two languages: in both languages, the incoming value is translated to a number, but, following the standard libraries of both languages, in Python January is represented by a 1, whereas in JavaScript January is represented by a 0.

1 0

Newsletter #155: Call for Functions: Spell out the number!
by Denny Vrandečić 15 May '24

15 May '24

The on-wiki version of this newsletter can be found here: https://www.wikifunctions.org/wiki/Wikifunctions:Status_updates/2024-05-15 -- Call for Functions: Spell out the number! Natural numbers, like most things, have different words for them in different languages <https://en.wikipedia.org/wiki/Numeral_(linguistics)>. A number such as 7 is called *‘seven’* in English, *‘sedam’* in Croatian, *‘ayɔpɔin’* in Dagbani, *‘asaa’* in Igbo, and so on. In many languages, names of larger numbers are often composed according to rules from smaller numbers. <https://www.wikifunctions.org/wiki/File:Chiffre-babylonien-1000.svg>The number 1000 in Babylonian cuneiform. For many numbers, Wikidata offers names. Either through lexemes such as L347774 <https://www.wikidata.org/wiki/Lexeme:L347774>, or on labels on the respective items, such as on Q23350 <https://www.wikidata.org/wiki/Q23350>. In Wikifunctions, we already have a function to create names for the English cardinal numbers <https://www.wikifunctions.org/view/en/Z13587>. It is presented below as the Function of the Week. For other languages, we don’t have that function yet. This is a call to the community to create such functions for the languages that you speak! In order to help with kicking those off, we drafted a PAWS Notebook <https://public-paws.wmcloud.org/User:Denny/numbers/numbers.ipynb> to create a first draft of the function implementation in JavaScript, using the lexemes and labels in Wikidata for a given language. Feel free to ask Denny <https://www.wikifunctions.org/wiki/User_talk:DVrandecic_(WMF)> to run the function for your language. Instead, you may also want to use one of the implementations of the English function below as a template and adapt it to your language. One interesting source of inspiration for this might be Grammatical Framework’s solution for creating number names <https://github.com/GrammaticalFramework/gf-contrib/tree/master/numerals>, or any of the many <https://github.com/marlun78/number-to-words> libraries <https://github.com/kwn/number-to-words> doing the same thing. Looking forward to seeing how this challenge develops! Let’s spell out the number! Recent Changes in the software One of our big pieces of work this Quarter is supporting identity Types, like singular/plural or passive/active (T363390 <https://phabricator.wikimedia.org/T363390>). This week, we landed middle-ware and front-end support for identity keys in Types (T363405 <https://phabricator.wikimedia.org/T363405> and T363497 <https://phabricator.wikimedia.org/T363497>); expect further movement on this soon! The "About" dialog, where you can add and edit labels, short descriptions, and aliases, now updates the 'count' of available languages consistently with the publish state (T346031 <https://phabricator.wikimedia.org/T346031>). The information in the pop-up meta-data dialog is now rounded to 4 significant figures, rather than letting floating-point noise obscure the main information in *e.g.* how long a function call took to run. We also landed some more minor fixes, including consolidating our front-end code to have only one method to determine if you're creating a new Object ( T358596 <https://phabricator.wikimedia.org/T358596>), and improving our browser tests to be more reliable and focussed on testing the main expected behaviour (T349836 <https://phabricator.wikimedia.org/T349836>). We added some logging when language look-up unexpectedly fails in the server-side code (T357702 <https://phabricator.wikimedia.org/T357702>), though we think this should now be fixed due to database content updates that landed last week. We also updated our code-documentation generation to use the latest template, and tweaked our JavaScript code to align with Wikimedia-wide coding style updates, using defineComponent() for making Vue components clearer to linters, and avoiding the unnecessary jQuery's $.extend() in favour of Object.assign(). Function of the Week: English cardinals English cardinals (Z13587 <https://www.wikifunctions.org/view/en/Z13587>) is a function that, given a natural number, provides the name of the number in English. Looking at the tests, we can find the following examples: - 42 is <https://www.wikifunctions.org/view/en/Z13589> *forty-two* - 0 is <https://www.wikifunctions.org/view/en/Z13590> *zero* - 101 is <https://www.wikifunctions.org/view/en/Z13591> *one hundred and one* - 777777777777 is <https://www.wikifunctions.org/view/en/Z13592> *seven hundred and seventy-seven billion seven hundred and seventy-seven million seven hundred and seventy-seven thousand seven hundred and seventy-seven* - 12 is <https://www.wikifunctions.org/view/en/Z13593> *twelve* - 777777777777777777777777777777777777777777777777 is <https://www.wikifunctions.org/view/en/Z13594> *seven hundred and seventy-seven quattuordecillion seven hundred and seventy-seven tredecillion seven hundred and seventy-seven duodecillion seven hundred and seventy-seven undecillion seven hundred and seventy-seven decillion seven hundred and seventy-seven nonillion seven hundred and seventy-seven octillion seven hundred and seventy-seven septillion seven hundred and seventy-seven sextillion seven hundred and seventy-seven quintillion seven hundred and seventy-seven quadrillion seven hundred and seventy-seven trillion seven hundred and seventy-seven billion seven hundred and seventy-seven million seven hundred and seventy-seven thousand seven hundred and seventy-seven* - report an overflow error <https://www.wikifunctions.org/view/en/Z13595> for a number with more than 48 digits The last should throw a proper error, not just a string that says error. We need to work on this. There are two implementations for this function, one in Python <https://www.wikifunctions.org/view/en/Z13588> and one in JavaScript <https://www.wikifunctions.org/view/en/Z15955>, both having a few dozen lines of code and quite a bit more complex than most of the Functions of the Week we have looked at so far. They may be used as templates for implementations for other natural languages, supporting the Call for Functions going out this week!

1 0

Newsletter #154: Flagship type for enumerations: Months of the Gregorian calendar
by Denny Vrandečić 10 May '24

10 May '24

The on-wiki version of this newsletter can be found here: https://www.wikifunctions.org/wiki/Wikifunctions:Status_updates/2024-05-10 -- Flagship type for enumerations: Months of the Gregorian calendar <https://www.wikifunctions.org/wiki/File:Plates_of_the_Twelve_Lunar_Months_L…>*Plates of the Twelve Lunar Months, Ogata Kenzan (Japan, 1663-1743)* As we announced last week <https://www.wikifunctions.org/wiki/Wikifunctions:Status_updates/2024-05-03>, our work for this quarter includes developing type support for enumerations <https://phabricator.wikimedia.org/T363390>. An enumeration is a type consisting of a set of named instances. Unlike open types such as natural number <https://www.wikifunctions.org/view/en/Z13518> or string <https://www.wikifunctions.org/view/en/Z6>, which can be created on the fly and can have an arbitrary number of instances, an enumeration must have all its instances predefined. In Wikifunctions, all instances of an enumeration must have distinct ZIDs and are distinct objects. We already have a few types which could be regarded as enumerations, such as Booleans <https://www.wikifunctions.org/view/en/Z40> (with the two values true <https://www.wikifunctions.org/view/en/Z41> and false <https://www.wikifunctions.org/view/en/Z42>) and natural languages <https://www.wikifunctions.org/view/en/Z60> (with currently hundreds of values). We will want many more enumerations in Wikifunctions, be it for the sign of a number, weekdays, cardinal directions, and much more. For natural language generation, we will need it to represent grammatical features, such as grammatical number, which we need for the function we worked together on in this week’s Volunteers’ Corner (see below). Just like last quarter with natural numbers <https://www.wikifunctions.org/view/en/Z13518>, we chose a flagship type to go as the first new enumeration type: months of the Gregorian calendar <https://www.wikifunctions.org/wiki/Wikifunctions:Type_proposals/Gregorian_c…>. The community is invited to join the discussion of the specification: should this also encompass the Julian calendar? Is there a good name for a single type that covers both? What other considerations are there? We would also like to ask the community to prepare and discuss similar enumerations for other calendar systems, so that, once this type works, we can move swiftly to create them in order to have parity across the world's calendar systems. Abstract Wikipedia at the Hackathon Our tech lead, James <https://www.wikifunctions.org/wiki/User:Jdforrester_(WMF)>, attended the annual Wikimedia Hackathon <https://www.mediawiki.org/wiki/Wikimedia_Hackathon_2024> as a volunteer last weekend, which took place in Tallinn, Estonia. He was glad to meet several existing Wikifunctions community members, and help explain the Wikifunctions and Abstract Wikipedia visions. There were extensive discussions about linguistic variations and how our community might hope to model them in forthcoming language generation functions. It was his pleasure to assist someone making their very first function, even though technical issues meant it didn't work at first. He and the rest of the team looks forward to speaking with more people about Wikifunctions. Recent Changes in the software Over the past two weeks, we've focused on the areas we laid out last week – Identity support on Types, production observability improvements, multi-language interface design improvements, research for the future Wikipedia integration, and much more. Beyond that work, we've made a few minor improvements that some of you may notice. We adjusted the front-end to batch requests for objects, grabbing at most 50 items at once, rather than unlimited; though in practice we've not hit this yet, in the future as community-written functions get more complex, this would have been reached and caused odd breakages in the front-end (T359035 <https://phabricator.wikimedia.org/T359035>). We fixed a missed piece of internationalisation in the aria-label of the Toggle button, for screen readers and other assistive devices (T362056 <https://phabricator.wikimedia.org/T362056>). We consolidated our duplicate maintenance scripts for managing pre-defined Objects, merging reloadBuiltinData into loadPreDefinedObject. We added the last remaining feature from the internal ApiQueryZObjects Action API to the new Fetch REST API, which will allow us to migrate to these cheaper, faster calls in future (T274269 <https://phabricator.wikimedia.org/T274269>). All Wikimedia-deployed code is using the latest version of the Codex UX library, v1.5.0, as of this week. Though we do not believe the library upgrade will have any user-visible changes in our use on Wikifunctions, please comment on the Project chat <https://www.wikifunctions.org/wiki/Wikifunctions:Project_chat> or file a Phabricator task <https://phabricator.wikimedia.org/project/view/4876/> if you spot an issue. Volunteers' Corner on May 6th We met with some of our wonderful Wikifunctions volunteers on Monday. We discussed our work for this quarter in more detail and built a function together for language-specific numerical singulars and plurals <https://www.wikifunctions.org/view/en/Z15982>. The recording of the event is available on Wikimedia Commons <https://commons.wikimedia.org/wiki/File:Abstract_Wikipedia_Volunteer_Corner…> . Function of the Week: Binomial Coefficient (Z13848) Binomial coefficients <https://en.wikipedia.org/wiki/Binomial_coefficient> represent the number of ways you can choose a certain number of items from a larger set, regardless of the order. They're often represented as "n choose k", where n is the total number of items and k is the number of items to choose. <https://www.wikifunctions.org/wiki/File:Wikifunctions_binomial_function_res…> For example, imagine we have five beads of different colors (Red, Blue, Green, Yellow, Orange), and we want to randomly choose two beads from them at a time. The binomial coefficient "5 choose 2" would tell us how many different pairs of beads we can make. In this case, it would be 10 pairs: 1. Red and Blue 2. Red and Green 3. Red and Yellow 4. Red and Orange 5. Blue and Green 6. Blue and Yellow 7. Blue and Orange 8. Green and Yellow 9. Green and Orange 10. Yellow and Orange So, binomial coefficients help you figure out how many combinations you can make from a set of items. The image shows our function returning a result of 10 for “5 choose 2” <https://www.wikifunctions.org/view/en/Z13848>. Mathematically speaking, the binomial coefficient, often denoted as (nk), represents the number of ways to choose k items from a set of n distinct items, without considering their order. It's calculated using the formula: (nk) = n!/(n-k)! Where n! (read as "n factorial") denotes the product of all positive integers up to n, and k! is the factorial of k, and so on. We have a function for the factorial <https://www.wikifunctions.org/view/en/Z13667>, too, which is used in one of the compositions <https://www.wikifunctions.org/view/en/Z13907>. The binomial coefficient function on Wikifunctions has 4 implementations – 2 compositions, and 2 implementations in Python : - binomial composition via factorial <https://www.wikifunctions.org/view/en/Z13907>, as just mentioned - binomial coefficient, python <https://www.wikifunctions.org/view/en/Z13850>, looping for a factorial - binomial recursive composition <https://www.wikifunctions.org/view/en/Z13912> - binomial coefficient, python <https://www.wikifunctions.org/view/en/Z14852> (using math.comb from the standard library) Binomial coefficients find their practical uses in probability predictions, to find the chance of getting a specific number of successes in a series of trials with only two possible outcomes or the likelihood of winning the lottery, or combinatorics , to count different ways to arrange or choose things, like distributing items into groups or selecting members for a committee.

1 0

Newsletter #153: Team meeting and Quarterly planning
by Denny Vrandečić 03 May '24

03 May '24

The on-wiki version of this newsletter can be found here: https://www.wikifunctions.org/wiki/Wikifunctions:Status_updates/2024-05-03 -- Team meeting in San Francisco <https://www.wikifunctions.org/wiki/File:Maiden_Lane,_San_Francisco_-_View_f…>Maiden Lane, San Francisco, view from near the office Last week saw our annual team meeting, and this time we gathered for the first and last time in the current office space of the Wikimedia Foundation in San Francisco. Some of us met for the first time, and we used the meeting to get to know each other, and to sketch out our plans for upcoming work on Abstract Wikipedia and Wikifunctions. We improved our shared understanding of the project and how we work together, and one of the results is our plan for this quarter, which we present below. We also had interesting discussions around how Abstract Wikipedia could look like in the future. We want to capture some of the thoughts from that session in more detail in an upcoming update, as it opens many questions for how Abstract Wikipedia can flourish and grow as a project that is rooted and anchored in the work of our contributors. It was a bittersweet opportunity for the team to see the current office, as the Wikimedia Foundation will move to a smaller office space <https://meta.wikimedia.org/wiki/Wikimedia_Foundation_Annual_Plan/2024-2025/…> in the fall as our lease ends. Quarterly planning One of the results of the meeting was to establish a plan for the current quarter. Here is a quick overview of the main tasks we will be working on: - *Visual prototype for Wikipedia integration <https://phabricator.wikimedia.org/T363392>*: based on our ongoing research, what could designs for the integration of Wikifunctions into Wikipedia look like? This will also be used to improve cross-functional collaboration and to identify next steps towards building Abstract Wikipedia. - *Type support for identity / enumeration <https://phabricator.wikimedia.org/T363390>*: supporting types that have a specific set of values, such as grammatical number in English (plural, singular), cases in Russian (nominative, dative, etc.), signs for integers (positive, negative, and neutral), or months in the year (January, February, etc.). This should allow us to create all types that are necessary to access lexicographic data in Wikidata, which would come next. - *Improve production monitoring <https://phabricator.wikimedia.org/T363387>*: so we have an easier time understanding when something goes wrong, or where the time in orchestration and evaluation is going. This will also inform future work on caching, which is critical for integration into Wikipedia. - *Improve integration with MediaWiki core tests and other test support <https://phabricator.wikimedia.org/T363389>*: changes to core are currently not automatically tested against the WikiLambda extension. We will work on changing that. - *Demos in a box <https://phabricator.wikimedia.org/T363394>*: provide resources that help community members to give presentations about Wikifunctions and Abstract Wikipedia. - *Wikifunctions’s UX drives user behavior to increase linguistic accessibility <https://phabricator.wikimedia.org/T363383>*: changes to the UX that make it easier for users to provide missing translations and a better experience in other languages than English. - *DB table for expanded metrics support <https://phabricator.wikimedia.org/T363439>*: allow for collecting more metrics about Wikifunctions. - *Help users debugging implementations by providing more metadata <https://phabricator.wikimedia.org/T363384>*: function calls are currently a bit of a black box. We want to provide some more insight into what is going on inside a function call, and this might help contributors fix issues more easily. An overview of this quarter’s work can be seen in a brand new Phabricator board <https://phabricator.wikimedia.org/project/board/7067/>. All the tasks listed above are represented in the column “Epics for this quarter”. Recent Changes in the software and Function of the Week Because this newsletter is already so long, and due to the team meeting and the Hackathon, we are skipping these sections this week. Volunteers’ corner on May 6 On Monday, May 6, 2024, we are going to have our Volunteers’ corner at 17:30 UTC <https://zonestamp.toolforge.org/1715016600>. Bring questions and curiosity! We will give an overview of recent changes, ongoing work, have ample opportunities to answer questions and discuss concerns by the community, and if there’s time, also work collaboratively on a function. Abstract Wikipedia team at the Wikimedia Hackathon in Tallinn This weekend sees the Wikimedia Hackathon 2024 <https://www.mediawiki.org/wiki/Wikimedia_Hackathon_2024> in Tallinn, Estonia. James Forrester of the Abstract Wikipedia team will be there and if you want to discuss anything about Wikifunctions or Abstract Wikipedia, feel free to approach him. (Also, he’s an awesome fellow to chat with even if you don’t.)

1 0

2024

2023

2022

2021

2020

Abstract-Wikipedia