Wikifunctions:Status updates/2024-08-16

◀

Wikifunctions Status updates

▶

Wikimania 2024 edition

Galder Gonzalez presenting possible ways that Abstract Wikipedia might help build towards the philosophical dream of a "universal language"

The “Abstract Wikipedia and the dream of a Universal Language” presentation took us through the history of the desire for a universal language. The presentation explored the historical ambition for a universal language, emphasizing its long-term, multigenerational nature. It highlighted the challenges that prevented the idea from gaining immediate traction, such as insufficient effort and the inability to agree on a common linguistic structure. Additionally, the talk noted how certain prominent world languages unintentionally began to function as de facto universal languages, diminishing the urgency for creating a truly unified global language. It also discussed how the efforts of the Abstract Wikipedia team, along with other teams within the Foundation, are aligned with this goal. To watch the entire presentation, please visit our public youtube link.

'Wikifunctions tutorial' session by our tech lead James Forrester

As previously mentioned in our newsletter, our team hosted two sessions. In the 90-minute 'Wikifunctions Tutorial,' we introduced the audience to the basics of Wikifunctions, its purpose, and practical, straightforward ways to contribute. James Forrester, our tech lead, and Nicolas Vigneron, a highly active community member with over 10 years of experience supporting our projects, guided participants through building their own functions on Wikifunctions, offering support and troubleshooting throughout the process. To watch the entire presentation, please visit our public youtube link.

Our community coordinator Luca Martinelli presenting 'State of Wikifunctions'

During our 30-minute 'State of Wikifunctions' presentation, we introduced the concept of Abstract Wikipedia and explained how Wikifunctions integrates with it. We provided an overview of the platform's role in enabling a more inclusive and multilingual knowledge base. Additionally, we showcased several key improvements and projects from the past year, from technical enhancements to community-driven initiatives. Looking ahead, we outlined our plans to further develop the platform, with a focus on expanding functionality and strengthening collaboration with contributors worldwide.To watch the entire presentation, please visit our public youtube link.

Recent Changes in the software

This update will cover the last two weeks' activity, as we didn't give an update last week during Wikimania. The week before Wikimania was one of our regular "Fix-It" weeks, where we spend a week every two months working on technical and product debt. Last week we also corrected several bugs.

In terms of user-facing features, we currently do not have a length limit on the labels and description, so we added code to enforce a limit on the length of labels and short descriptions in the API (T343767); this is initially very high so that all existing Functions and Objects will still save, but we will reduce it once on-wiki pages are fixed (T371882).

We changed how we fetch language Objects from our cache database table to fix a bug that meant some language codes like 'lv' would break the UX, but their other code ('lvs' in this case) would load as expected (T372052 and T372086). Thank you to User:Papuass for reporting this issue! We also fixed the way the title displays on the page when you use the About dialog add or remove the label in your display language, so it will remove or show a language 'chip' as appropriate (T361715). We fixed the encoding of pipe characters in an edge case so that they can be passed through the API – sorry about the delay on this edge case (T358089).

We re-wrote the entire error-emission and handling stack between MediaWiki and the Vue front-end to be more consistent and approachable (T345010 and T361683). We found that a few tests which previously had been broken in the Beta Cluster are now working again, so re-enabled them, including from when we changed how the Python runner operated (T361125) and programming language selection failure (T361124). We also extended our code coverage in a few bits of the codebase, and made some tweaks to the README and set-up scripts to help with local development (T371652 and T371896).

We, along with all Wikimedia-deployed code, are now using the latest version of the Codex UX library, v1.11.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.

Finally, we renamed the main ResourceLoader 'module' directory from "ext.wikilambda.edit" to "ext.wikilambda.app", reflecting how the original scope of the code expanded in the last four years to viewing Functions and Objects, not just editing them.

Implementation selection change resulting from community discussion

Based on feedback and discussions with community members, we have modified the algorithm by which a function's implementations are ordered. Implementations are ordered (roughly) by their speed of execution and, in most settings, Wikifunctions selects the fastest implementation to handle requested function calls. Thanks to community feedback, we became aware that Wikifunctions was sometimes selecting longer-running implementations, resulting in unnecessarily long wait times (and even timeouts) for function results. We realized that these counterintuitive selections were happening because the ordering was based on the CPU time used by each implementation. User experience is much more attuned to elapsed time, so we changed the algorithm to consider that instead of CPU time.

We appreciate the feedback and substantial help from the community in identifying and understanding this concern! Some of the discussion occurred in Phabricator task T363908, and some on Telegram. It should be noted that the ordering algorithm also considers the number of successful test executions. Also, it is possible to request a function call execution using a specific implementation. For additional details, please see Implementation ordering and choosing.

Function of the Week: convert X11 color to hex

For this week’s function, I wanted to choose one that was created during our Wikimania week. This function takes an X11 color as a string input and gives its equivalent hex code as output.

An X11 color is a named color from the X Window System's standardized set, commonly used in web design and graphical interfaces. A function that converts X11 color names to hex values has several practical applications. It has obvious use in web design and development, where it can help developers quickly translate X11 color names into hex codes for consistent use across websites, ensuring compatibility with CSS standards.

Design tools can also benefit by allowing designers to choose colors by name, which are then converted into hex values for easy use in sharing digital assets and for collaboration within a project between designers and engineers. Also, the function can be integrated into applications where users can select from a set of predefined colors that seamlessly translate into hex values.

This function has one connected implementation in JavaScript and one similar, yet to be connected implementation in Python. The connected JavaScript implementation maintains a list of all X11 colors and their corresponding hex values and outputs based on the input X11 color.

The function also has 4 tests (1, 2, 3, 4) that verify the function for four different color inputs. This function also encourages us to envision an implementation that is more dynamic and uses a data set that is available at run time.