Jump to content

Wikifunctions:Status updates/2024-06-20

From Wikifunctions
Wikifunctions Status updates Translate

<translate> Abstract Wikipedia via mailing list</translate> <translate> Abstract Wikipedia on IRC</translate> <translate> Wikifunctions on Telegram</translate> <translate> Wikifunctions on Mastodon</translate> <translate> Wikifunctions on Twitter</translate> <translate> Wikifunctions on Facebook</translate> <translate> Wikifunctions on YouTube</translate> <translate> Wikifunctions website</translate> Translate

New Type: Integers

We are happy to announce a new Type: Integer. Integers are the whole positive and negative numbers, and zero.

Integers will allow us to have functions that increase our coverage of mathematical functions, e.g. our current subtraction function floors at zero. This will also help us with figuring out how to deal with overlapping Types, since the Integer and the Natural numbers 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 weeks) is around completing those eight Epics, 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), 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). We improved the front-end experience when creating Type converters related to Identity keys, and generally cleaned up the code in this area (T367159), and made it more possible to use the UI to create Type converters rather than needing to use the API (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). You can see the updated documentation on our User rights documentation. We also updated the definitions of Z46/Type converter to code and Z64/Type converter from code to mark their 'identity' keys (Z46K1 and Z64K1 respectively) as identity keys via setting Z3K4/is identity to true (T359233).

On the Epic related to improving our tests (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).

Related to the Epic for giving meta-data for function sub-calls (T363384), we added front-end support for showing the information (T363396), and we're preparing to deploy the latest version of the back-end services with this information (T366498), and we hope to enable this feature soon (T366829).

The last task this Quarter for better UX related to language (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).

In preparation for next Quarter's work, as part of the Wikimedia Foundation Annual Plan for 2024–25 to "enable [cross-wiki] Wikifunctions calls on at least one smaller language Wikipedia" (WE2.4), we moved our very early prototype code for making Wikifunctions calls into its own extension, 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). 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 now has 'bat-smg' as secondary, rather than the other way around (T360672); similarly, Z1231/de-x-formal now has 'de-formal' (T360673) and Z1664/ro-cyrl-md has 'ro' (T360674); and Z1508/als has had the old Z1405 'gsw' object (T360675) and Z1726/egl the old Z1750 'eml' object (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). 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). We found and fixed a long-standing typo in our maintenance database cache deletion code which we think should improve language-related bugs (T343164, 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 the Igbo calendar month Type, 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 and previous months given a certain month. Both of these Functions exist now for the Igbo calendar months in Wikifunctions.

The following month function offers six tests, including the edge case of the last month of the calendar year being followed by the first one. The Function has three implementations, and each of them works slightly differently:

  • One in Python, 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, 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, which turns the input month into a number, increments the number by one, and turns that result back into a month. 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!