Abstract-Wikipedia July 2024

abstract-wikipedia@lists.wikimedia.org

1 participants
2 discussions

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

10 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ć 03 Jul '24

03 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

2026

2025

2024

2023

2022

2021

2020

Abstract-Wikipedia July 2024