We are proud to announce our initial, flagship enumeration Type: Gregorian calendar months.
Gregorian calendar months are an enumeration of twelve values, starting with January and February and going all the way to November and December. For testing purposes, we created two functions for now: "same month", discussed below as the Function of the Week, and "following month", 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, 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, 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.
Our main work this Quarter is around the eight areas 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), 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). 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 (T359999).
In other priority areas, we continued our work on streamlining, simplifying, and otherwise improving our browser tests (T349836) as part of our general testing improvements work (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). We have also been examining service performance and management issues within our work to better monitor production (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). Thank you to Umherirrender for this, and many other improvements for Wikifunctions and the wider Wikimedia ecosystem, over the years.
We tweaked our languages, updating Z1221/nan to merge in zh-min-nan; our particular thanks to Winston Sung for their leading work on cleaning up our language support (T348370).
We, along with all Wikimedia-deployed code, are now using the latest version of the Codex UX library, 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.
Last week, we called for you to create functions which spell out numbers 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 has been started, and we are looking forward to seeing the project develop. If you need any help, feel free to ask!
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.
Since we just introduced a new Type, Gregorian calendar month, 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".
It takes as input two arguments of our new Type for Gregorian calendar months, and returns a Boolean value: true, if the two months are the same, and false 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", using eleven if
s 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:
There are two implementations for the function, one in Python and one in JavaScript. 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.