We are happy to announce another new Type this week: an enumeration for the thirteen months of the Igbo calendar (Igbo calendar month (Z16927)).
The symbol for the Moon in Nsibidi, an Igbo system in use since the 5th century CEThe Type follows the Type proposal led by Dolphyb. We created the thirteen months of the Igbo calendar: Ọnwa Mbụ, Ọnwa Abụo, Ọnwa Ife Eke, Ọnwa Anọ, Ọnwa Agwụ, Ọnwa Ifejiọkụ, Ọnwa Alọm Chi, Ọnwa Ilo Mmụọ, Ọnwa Ana, Ọnwa Okike, Ọnwa Ajana, Ọnwa Ede Ajana, and Ọnwa Ụzọ Alụsị.
A first function was also introduced, to check two Igbo months for equality.
We are looking forward to seeing more 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.
Next Thursday, June 20, 2024, at 19:00 local time in Munich, Germany,, 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:
We added the relevant rights for creating and editing instances of 'enum' Types like Z16098/Month and Z16659/Sign (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, now covering the CodeEditor one alongside the others (T358207). We moved a handful of our legacy global functions out of the global JS namespace (T362925).
We updated some of our browser tests to use i18n-independent selectors, as part of work to make them more stable (T349836).
Last week, we announced the Sign Type, 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.
In order to recognize that work we selected one of these as the Function of the Week: do these charges electrostatically attract? (Z16781), do these charges electrostatically attract?
The Function takes two inputs of type Sign and returns a Boolean. The inputs are the two charges which are checked for whether they attract each other, or not. As the saying goes, opposites attract: 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 – and three examples that do not: positive and positive, positive and neutral, and neutral and neutral. For this Function, that’s a nice, balanced set of Tests.
The Function currently has one Implementation, a composition: it relies on multiplying the two input Signs and checking whether the result of that multiplication is negative using the same Sign 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 conditions to check whether one result is negative and the other positive, or the other way around, and return false 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.