Wikifunctions:Project chat

Welcome to the Project chat, a place to discuss any and all aspects of Wikifunctions: the project itself, policy and proposals, individual data items, technical issues, etc.

Other places to find help:

• Wikifunctions:Administrators' noticeboard
• Wikifunctions:Report a technical problem
• Wikifunctions:FAQ

SpBot archives all sections tagged with {{Section resolved|1=~~~~}} after 1 day and sections whose most recent comment is older than 30 days.

edit
Archives
2023/08 2023/09 2023/1 2023/10 2023/11 2023/12 2024/01 2024/02 2024/03 2024/04 2024/05 2024/06 2024/07 2024/08 2024/09 2024/10 2024/11 2024/12 2025/01 2025/02 2025/03 2025/04

expression error with eastern numerals languages

Hi, for a while I noticed an "expression error" appearing in some pages whose languages ​​use eastern numerals "according to mediawiki settings". Perhaps the numbers are converted to eastern numerals and the system does not recognize the value. An example of these pages are the main page templates: ar, fa, bn, hi. Also ,look at this old revision of a page that was translated from one that used #exp: magic word for the number of administrators, It was later reverted--Mohanad (talk) 13:23, 15 February 2025 (UTC)

I think {{#time:U}} in {{Random function}} needs to be {{#time:U|now|en}}. YoshiRulz (talk) 19:44, 15 February 2025 (UTC)

Maybe turning off $wgTranslateNumerals for wikifunctions is a better long term solution for a code publishing project, multiple projects have done it --Mohanad (talk) 23:07, 17 February 2025 (UTC)

Other solution is to use the magic word: {{formatnum:...any variable num...|R}} where ever expr: is used with variables, Ex: {{#expr:{{formatnum:{{NUMBEROFADMINS}}|R}}-2}} --Mohanad (talk) 16:29, 5 March 2025 (UTC)

I’m just hoping that it won’t be long before we can use a Wikifunctions function here. GrounderUK (talk) 16:46, 5 March 2025 (UTC)

It's for RNG though? Anyway, I already posted a solution. YoshiRulz (talk) 16:01, 28 March 2025 (UTC)

I've made the change you suggested here. Did that fix the issue? --99of9 (talk) 13:32, 7 April 2025 (UTC)

proposed Reader and Display functions for Byte Type

I suggest we use the following functions as a reader and display function for the Byte Type:

• read Byte (Z22866)
• display Byte (Z22887)

Feel free to add an implementation to either with a language configuration if you would like to convert to a different numeral script. --99of9 (talk) 05:40, 27 February 2025 (UTC)

How do you feel about displaying in three or more formats: hex, binary, decimal and (maybe) octal? Something like “F1 (hex), 11110001 (binary), 241 (decimal), 361 (octal)” or “F1 [16], 11110001 [2], 241 [10], 361 [8]”? GrounderUK (talk) 12:09, 2 March 2025 (UTC)

They all seem too long IMO. Imagine how they would show up in rendered displays (e.g. on Tests). I agree that choosing a base has no right answer, but I think choosing any is still better than all. --99of9 (talk) 22:21, 2 March 2025 (UTC)

Ah, yes… you’re right, of course! GrounderUK (talk) 23:24, 2 March 2025 (UTC)

Can we proceed with this one? In particular the reader will be useful to accept a wider range of inputs. 99of9 (talk) 00:31, 26 March 2025 (UTC)

@DVrandecic (WMF): I know you've been busy, and am sorry to be pushy, but you asked for this about 6 weeks ago, and I tried to get it done the next day. --99of9 (talk) 06:32, 14 April 2025 (UTC)

Which number type to use on WP facing functions

We have two real options for which number type to use in Wikipedia facing functions for precision beyond the integer. These are:

• Rational number
• float64

This is an important choice, and I think it will be better to make an explicit choice now instead of going with whatever is initially most popular.

For clarification, Wikipedia facing functions are functions with the primary purpose of serving Wikipedias. They should generally use a capital letter and accept a language input. Feeglgeef (talk) 13:44, 9 March 2025 (UTC)

Rational number, because float64 is unnecessarily restricted in range. Rational number often has bad conversion out for Wikipedia use cases, but calls can always be wrapped in a function to fix this problem Feeglgeef (talk) 13:47, 9 March 2025 (UTC)

Maybe we should improve the display function for cases where the (simplified) denominator is divisible by 10 (or it is 2, 4, 5, 8?) , displaying as decimals? GrounderUK (talk) 14:32, 9 March 2025 (UTC)

No, we should keep our display function optimised for representing general values of the Type. It would be rare for the result of a wiki calculation to end up with a denominator being a power of 10. I agree with @Feeglgeef that we will need a range of formatting functions constraining sig figs, decimal places, expressing percentages, units, currencies, etc etc. That will be necessary no matter which underlying format we use. 99of9 (talk) 00:54, 10 March 2025 (UTC)

Oh, yes… a range of formatting options is the right way to go, but that’s not what we’ll go live with. The Wikipedia user will have a restricted range of functions, because they must read and display strings. They won’t be able to wrap functions according to the desired format; they’ll just get what the display function gives them. I imagine the “plain text” limitation means that the function call’s plain text evaluation can’t be embedded in Wikipedia-resident formatting either. GrounderUK (talk) 08:55, 10 March 2025 (UTC)

I understand that we can ultimately only return a string. But it's not clear to me that we won't be able to call a (formatting) function of a (calculating) function. Maybe I'm too hopeful? 99of9 (talk) 11:44, 10 March 2025 (UTC)

Maybe I’m too “realistic”? Wikifunctions can wrap useful functions for a range of formats, and Wikipedia users can choose from the wrapped functions (among others), I suppose. But we’d have to create such a wrapped function for every “useful” function for which fractions or long decimal strings would be inappropriate in Wikipedia. I don’t think that is necessarily evil and, of course, my understanding may be incorrect, but if we start down this track, it doesn’t much matter whether the wrapped function uses Rationals or floats. GrounderUK (talk) 15:12, 10 March 2025 (UTC)

If float64 has a renderer that outputs completely intelligible to the parser, this should work. I was also hoping that we could select from a list of approved renderers (that can also take inputs) attached to the type. This should hopefully make rational numbers more convincing for you on the WP editor and WP user end (again, the target of this RfC) Feeglgeef (talk) 13:13, 11 March 2025 (UTC)

float64 (or future SI measurement) is my current preference, but I think it is too early to decide what will be most useful until we can see the options in action. I don't buy the range restriction argument, because for a written work we will inevitably want to make it simple and readable (scientific notation, heavily rounded, or similar), and the values we deal with are very unlikely to be out of the enormous range that float64 permits. If we ever do need extreme values, it would be easy enough to write that particular function using rationals. If we really want to worry about edge cases, it would be good to figure out how to deal with irrationals well, because numerous maths articles need them (currently coded with markup). For regular pages it will be things like population/area or %increase in value, which will look terrible in our default rational display. If we have to write a wrapper anyway, then it won't usually matter what the underlying type is. 99of9 (talk) 00:46, 10 March 2025 (UTC)

• you can't represent irrationals with float64
• values are likely to be imprecise when calculations are done and such
• we should strive for a completely compatible system. Rational numbers are a superset of float64
• the way you want to render a number will obviously change from one article to the next, I don't think it's a good idea to pick a worse type because it has a renderer that's better in some cases

Feeglgeef (talk) 14:06, 10 March 2025 (UTC)

Despite the flaws you've pointed out, I still feel inclined to agree with 99of9 here on opting for float64. I believe many languages (such as JavaScript and Lua, if I recall) use floating-point numbers as the default decimal type or default number type in general. The imprecision that comes with using float64s will always remain an unfixable issue, but the higher bit width and fact that most outputs of float64 functions will end up getting rounded or truncated in the end anyways makes the issue manageable enough to warrant using it over rational numbers. I understand we are working with all manner of types here and going with what a bunch of programming languages do already is certainly not a very logical approach to take, but I point out the pattern because I feel its inclusion is for a meaningful reason beyond popularity, i.e. its versatility—among other things. Representing decimal numbers using their fractional parts, as well as other methods of representing decimals such as fixed-point, have their uses, but floating-point numbers seem like more of a sensible, foolproof default (barring imprecision). Of course, rational numbers will always exist on Wikifunctions, as will their associated functions, so defaulting to using floating-point numbers won't do much harm when an editor can always choose to opt for whatever type is most appropriate for their use case. It just makes the most sense to use float64 as the common denominator, in my opinion. — rae^5e <talk> 04:18, 11 March 2025 (UTC)

float64 is default? Rational numbers are literally the standard in math sense, float is arbitrary appeal to how computers work, which should again not be what we are targeting. The only real argument for float64 that presented is popularity in computing spaces (which is, again, not our target here) Feeglgeef (talk) 13:06, 11 March 2025 (UTC)

I don't know what you mean when you say "float64 is default?", but I didn't say or imply any of that, at least not intentionally. I'm not attempting to base the decision purely off of consensus. I concur with all of the things 99of9 says in the parent post, I was just adding my own thoughts on why I think float64 should be used. I wasn't pointing out the commonness of floating-points in programming languages as a rationale to use it as the default on its own, but I was using it to attempt to demonstrate the familiarity around it and the fact that, to me, its high usage communicates that it's acknowledged to be flexible, versatile, and unobtrusive enough for most use cases. I don't think any of those languages would opt for the type just due to consensus. — rae^5e <talk> 12:47, 12 March 2025 (UTC)

"but floating-point numbers seem like more of a sensible, foolproof default."

Rational numbers are much more versatile for anything that's not code, and, again, our goal is to abstract away from code. Appealing to an option that's worse because of ease of use in our context is short-sighted and only really offloads the cost from us to users.

I'd like to point out that the average Wikipedia editor or user has no idea what floating point is, and would very much like to just have things work and not see 0.3000000001 or something when they try to add 0.1 and 0.2.

Feeglgeef (talk) 19:13, 12 March 2025 (UTC)

I've given it some thought and I believe that if rational numbers don't incur a significant performance cost compared to floats, they would fit as a sensible, non-technical default—basically every wiki editor knows what a fraction is, but I'd imagine not many know what a mantissa is. My preference towards using them at this moment is not particularly strong, and I still believe more people should weigh in on this issue before a consensus is even remotely reached, but the unfixable problem of floating point precision errors is unignorable and you make a good point about them. We could always round or truncate the results, however, as I don't believe most editors will need to display the full range of precision of double-precision floats except in technical cases when demonstrating the type itself. When not displayed in full and errors are corrected by way of rounding, the results floats provide are still quite accurate; accurate enough for many scientific and graphing calculators to use them by default, at least, which at least means something for the mathematical capability of the type. Float values on Wikifunctions when not sent through a reader or display function are very, very unwieldy to use. I'm sure you remember that this is how they had to be interfaced with for a time (at least, from my perspective) and it made it very difficult to actually use them, being someone not strongly knowledgeable of the workings of floating-points in the first place. That being said, that was only temporary exposure to the more ugly parts of the type that in modern times is never required knowledge for use of the type itself in user-facing applications. Nasty precision errors are usually never seen due to correction or are told to users using them beforehand as a warning of what and what not to expect. I think float64 should hold some prominence in wiki-facing function calls, maybe by the discretion of the editor, maybe in special cases that warrant them (if ever there are any); irregardless, I believe most of what you said is correct, and I change my stance towards rational numbers, but not heavily. At this moment I'm primarily just concerned about how much overhead the latter (rationals) would have in comparison to the former. — rae^5e <talk> 13:06, 10 April 2025 (UTC)

You make some good points. Specifically on performance, it depends… Because a float64 (Z20838) is a more complex object, there are additional overheads before and after evaluation. For simple arithmetic, using converted float64 (Z20838) objects also tends to be more efficient because it’s all integer-based. No doubt there are more complex cases where it is more efficient, overall, to use float64s, so I suggest we try and find some and set them up as test cases so that we can see the differences. Ideally, that would be end-to-end, but we do not see the read and display performance in the evaluation of a test case. GrounderUK (talk) 13:34, 10 April 2025 (UTC)

If the goal is to replace some ParserFunctions/Lua calls while maintaining compatibility, wouldn't a function need to use float64 throughout? YoshiRulz (talk) 04:50, 10 March 2025 (UTC)

No? Float and Rational are in the same technical place when it comes to Wikipedia use. Feeglgeef (talk) 14:00, 10 March 2025 (UTC)

I don’t have a strong view on this, although I’ve never been keen on floats. I’ve created two functions that may be of interest.

• number as Rational number (Z23668): returns a Natural number, Integer or Float64 as a Rational number (returning a Rational number unaltered or simplified and an error for any other type)
• Rational number as simplest type (Z23660): returns a non-negative integer value as a Natural number object and any other integer value as an Integer object (any other Rational number remains unchanged)

I haven’t added these to the Catalogue as I’m not sure we want to be going down this route. GrounderUK (talk) 07:26, 9 April 2025 (UTC)

Humours Suggestion...

On other porjects the central discussion has it's own name. Wikipedia: Viage Pump, Wikisource:Scriptorum, Wikivoyage: Traveller pub.. Can calling the central discussion here the 'Chalkboard" ? ShakespeareFan00 (talk) 20:58, 24 March 2025 (UTC)

On a more serious note: Are there plans to try and implement all the common functions in the CRC handbook? ShakespeareFan00 (talk) 20:58, 24 March 2025 (UTC)

Personally, I won't be working on many functions related to scientific measurements until we've implemented something like Wikifunctions:Type_proposals/SI_units, so that the units can be attached. 99of9 (talk) 01:19, 25 March 2025 (UTC)

Function request: Cartesian to Polar.

Input 1 matrix [x,y] Output 1 matrix [θ,r] Short text : Polar conversion of x,y to polar space, (centre at 0,0) Constraints: x,y,r are rationals (floats), θ lies in the range -π<0<π

The reverse could also be implemented. ShakespeareFan00 (talk) 23:28, 25 March 2025 (UTC)

These look worthwhile to me. A good place to put suggestions so that they stay on the record is at Wikifunctions:Suggest a function. --99of9 (talk) 00:37, 26 March 2025 (UTC)

Operations in polar shuch a shifting a point or reflecting it could also be implementedShakespeareFan00 (talk)

Function request:

Name: Charcter to Hershey. Input: Unicode code point.

Output: Hershey Character Number (Real), Occidental (Boolean)

Supplied with a Unicode character point, returns the number of the charcter in the numbers used to define the Hershey character sets. — Preceding unsigned comment added by ShakespeareFan00 (talk • contribs)

@ShakespeareFan00: what do you mean by "Hershey Character Number"? Is it Hershey fonts? (from what I gathered, there is no possible calculation, we have to do a one-on-one mapping, is it right? see https://github.com/Kaloffl/Hershey-Unicode-Mapping which is luckily free licensed). Cheers, VIGNERON (talk) 14:32, 26 March 2025 (UTC)

This would be a one to one mapping , if it is out of scope, LMK. The Occidental flag is because there is a seperate Japanese series of Hershey characters. And yes this is about the Hershey fonts. ShakespeareFan00 (talk) 15:10, 26 March 2025 (UTC)

Numeric type : Real number ?

In order to allow π to be supported in my previously suggested cartesian/polar conversion function, I note that a 'real' type needed to be supported.

A 'real' differs from a rational in that it it can take any supportable numerical value.

Obviously for Wikifunctions purposes a real has a floor and ceiling value for positive/negative infinity, and underflow infinity ( i.e too close to zero). Can someone assist me on converting this into a formal explanation?

I had this so for for real : Constraint : $\pm |(\mathrm{\infty }>x>0)|$ Representation: "[0-9]*\.[0-9](\E((\+|\-)|)[0-9]*|)" Pi would then be - Function Name: Pi Function type: Constant value - Real. Constraint : 3.141... Unless in abstract there's a different way to define it.

Formal methods is not an area I thave that much experience with. ShakespeareFan00 (talk) 08:37, 26 March 2025 (UTC)

Defining a color for referenche elsehwere either as :

Representation:\#[0-9A-F]{6}. \* Hex String *\ Representaion: (\1\.\0|\0\.[1-9]+)\,{2}(\1\.\0|\0\.[1-9]+) \* 3 value float (0.0 < n 1.0 *\

We don’t have a Type proposal for Real numbers yet. We can support arbitrarily precise approximations for an irrational number as a Rational number (Z19677) and we already have a float64 approximation for pi (float64 approximation) (Z20862), but someone should propose a Real number type (or, perhaps, an Irrational number type) if they have a clear idea of how it might work. I’m rather drawn to the idea of a separate Irrational number type, without thinking it through… GrounderUK (talk) 10:28, 26 March 2025 (UTC)

Broken formulas

I tried asking on Telegram and didn't get a response, so trying here.

In the discussion right above this one ("Numeric type : Real number ?"), there are some broken Math formulas. I didn't look deeply into the configuration, but the possible reason is that wikifunctions.org not connected to Restbase. That's usually the thing that causes failures to render Math formulas.

It typically happens when a Wikipedia is created in a new language: the domain is created first, and some other services, like Content Translation, Wikidata, and Restbase, are enabled a few days later, and during these days, those things don't work.

AFAIK, Restbase is not used for many things except rendering Math formulas, and in some time in the future it is going to be completely disabled, and rendering Math will be moved to something else. But since it hasn't happened yet, perhaps Wikifunctions should be connected to Restbase so that people can use Math formulas?

Or maybe it is connected, and the rendering errors are caused by something else? Amir E. Aharoni (talk) 11:29, 27 March 2025 (UTC)

@Amire80: Restbase isn't installed here because it's not meant to be used on new wikis, and the owning team said expanding it to this new wiki family wasn't supported. Math rendering here is only supported via MathML/MathJax, but unfortunately we can't disable the broken mode, so if you've got that set in your preferences you'll see that form until it's no longer supported, yes. (As always, please file Phabricator tasks for technical issues.) Jdforrester (WMF) (talk) 16:51, 28 March 2025 (UTC)

Feature petitions page

I've made a page to add and sign petitions for Wikilambda features, to help the community voice priorities. Feel free to add some or sign existing ones. Feeglgeef (talk) 23:37, 27 March 2025 (UTC)

@Feeglgeef: This feels rather low-value compared to a conversation about what and why we might want to add features? I think it might be worth talking about things first before "voting" on them? Jdforrester (WMF) (talk) 16:48, 28 March 2025 (UTC)

Of course. I made this because I (and others on the telegram/IRC) feel some of our priorities have been consistently ignored (phab:T385895, phab:T386422, phab:T386671). I'm hoping to make our priorities clearer and more accessible with this. Feeglgeef (talk) 18:33, 28 March 2025 (UTC)

I wouldn’t say “ignored”, but the prioritisation process is opaque and lacks a mechanism for community input or interaction. But I agree that voting is not the priority! GrounderUK (talk) 23:30, 28 March 2025 (UTC)

Thanks for kicking this off. I’ve added the Feature requests that I have raised in the past and one that @99of9 and I discussed on Telegram. I haven’t looked at my Bug reports yet. I’m not happy with the page title; I think “Feature proposals” or “Proposed features” would be more appropriate. In my view, the page should include (our) high-priority Bug reports, but I don’t think we need to worry about the distinction. GrounderUK (talk) 09:58, 30 March 2025 (UTC)

Reference desk?

I have some functions and use cases I was wanting, I know they are 'defined' somewhere. Can we have a Refdesk equivalent to help find functions and implementations? ShakespeareFan00 (talk) 14:17, 28 March 2025 (UTC)

WF:Find has some helpful tips and a spot to ask at the end. Feeglgeef (talk) 14:22, 28 March 2025 (UTC)

Having problems

Hi!

I submitted three-dimensional perlin noise, with an implementation. However, it says "Status: Disconnected". It's not at all clear what this means. After some searching, I discovered that only "functioneers" can "connect" an implementation. (Maybe we should make this easier to find?) After looking at the page history for the function, I saw that the implementation was "added" and then quickly "removed", with no reasoning or explanation.

I thought maybe the reason it was removed is because the function has no tests. So I created a test. It failed with an "unspecified error", and the error contains (along with a wall of impenetrable Z-ids) "cannot convert to bigint". I don't know why (or what) it's trying to convert to a "bigint" because the output is supposed to be a float64.

Can anyone help me? Sillypantscoder (talk) 23:54, 5 April 2025 (UTC)

It is probably because you tried to sum regular js Numbers with BigInts inside the code (js doesn't permit you to do this). Note also that input parameters, of type Integer (Z16683), are automatically converted to BigInts before being passed to your function.

As the error infobox suggests, you can always use Wikifunctions.Debug to print debug logs.

I hope I this is helpful. Dv103 (talk) 06:41, 6 April 2025 (UTC)

I tried adding Wikifunctions.Debug. When I was saving the function, it warned me to not use this function, which is odd because I seem to be unable to run the function without saving it first.

After this change, the test gave me an "Invalid executor response" with no other information. Sillypantscoder (talk) 21:40, 6 April 2025 (UTC)

I've fixed the debugs, so they are now showing up in the output. (BigInts needed to be converted to strings, because Debug only prints strings). Now the error is "cannot convert to bigint". This is because all of the inputs are bigints, but all of the numbers in the code are regular integers. --99of9 (talk) 00:35, 7 April 2025 (UTC)

I figured out the problem with the function, thank you!

One other thing, though-- When I was editing the function, it tried to show me whether the test had passed. But it always reported "failed", and when I clicked the "details" button it said "Unable to run tests. Please reload." This message persisted after reloading. Do you know why this could happen? Sillypantscoder (talk) 03:06, 7 April 2025 (UTC)

Yes, this is reasonably common when the tests are all being rerun. If you wait long enough (~10sec * number_of_tests * number_of_implementations) before refreshing, it will almost always be done by then. --99of9 (talk) 05:14, 7 April 2025 (UTC)

For the function, can I suggest that you add the size of the system as a parameter. The way you have it, it must always use the hardcoded default size of 35. 99of9 (talk) 05:15, 7 April 2025 (UTC)

Wikifunctions & Abstract Wikipedia Newsletter #196 is out: Quarterly Planning for April–June 2025; We are looking for a Senior Product Manager

There is a new update for Abstract Wikipedia and Wikifunctions. Please, come and read it!

In this issue, we present our work plan for the upcoming quarter (April-June 2025), we publish a new job opening for joining the team, and we take a look at the latest software developments.

Want to catch up with the previous updates? Check our archive!

Also, we remind you that if you have questions or ideas to discuss, the next Volunteers' Corner will be held on April 7, at 17:30 UTC (link to the meeting).

Enjoy the reading! -- User:Sannita (WMF) (talk) 14:22, 6 April 2025 (UTC)

The recording of yesterday's Volunteers' Corner is now available on Commons. Enjoy! Sannita (WMF) (talk) 11:15, 8 April 2025 (UTC)

MonoBook search

Are there any plans to implement the new search functionality in the MonoBook skin? I'm aware that the status update explicitly stated that this cannot be done:

Note that this search tool is only available in the Vector-2022 skin; in the legacy experiences, you will have the old search experience, as those unfortunately can't be extended but only replaced.

However, I notice that Wikidata has custom search functionality on the MonoBook skin that I so far haven't had any major issues with. Could a similar approach be applied to getting better object search working on MonoBook for this wiki? If Wikidata could, I don't see how Wikifunctions couldn't (potential difficulty notwithstanding). — rae^5e <talk> 16:14, 9 April 2025 (UTC)

@Theki: I fear you're being rather optimistic about how much work this would. We for Wikifunctions aren't providing a search tool (which has been subject to huge amounts of design, development, testing, and validation). We just plug in a search API into that. The search tool is provided by the skin. As I understand it, the "new" (2020) search system used by Vector 2022 and other skins can't integrate with legacy skins like MonoBook or Vector 2010 without breaking lots of existing gadgets/etc., and the consensus in community conversations was that people didn't want that. Consequently, people using those legacy, unsupported experiences can't get the new search system. (By way of context, remember that legacy skins like Vector 2010 and MonoBook haven't been supported with new features for many years now.)

Wikidata does indeed have a hack that over-writes the legacy search system. It is also unsupported, and breaks several things; I believe that there have been conversations between the Wikidata and Web teams about building a system that could support their needs for a few years, but so far nothing solid has happened. If that were to happen, we could possibly integrate with it too, but we certainly aren't going to break things for Wikifunctions by bodging in a replacement, especially not for the MonoBook skin. If you want to write a user script to hack your experience, you can, but I don't think we can at all justify spending effort to support a handful of people who don't use the current tools. Jdforrester (WMF) (talk) 20:02, 16 April 2025 (UTC)

That is perfectly understandable. I had assumed that I am one of only a small portion of editors using the legacy appearances and as such any effort put into supporting those would be disproportionate to the amount of use that it could potentially have for its now small userbase. A userscript could work for this, but Special:Search has always been effective for me regardless of its occasional impracticality. If I had to do anything to get improved search to work on MonoBook I'd likely just write a custom userstyle that makes Vector 2022 look as close to MonoBook as possible (if one doesn't exist already). I do hope that the Wikidata folk come to a solution eventually but this and other compatibility issues don't irk me to the point where I'd want to switch. Thank you for the explanation and I apologize for any hassle. — rae^5e <talk> 20:17, 16 April 2025 (UTC)

@Theki: No hassle at all, and thank you for being understanding. I hope we can soon give you a great experience even in MonoBook, in this and everything else. Jdforrester (WMF) (talk) 20:20, 16 April 2025 (UTC)

Wikifunctions & Abstract Wikipedia Newsletter #197 is out: Quarter in review, and lots of material to watch

There is a new update for Abstract Wikipedia and Wikifunctions. Please, come and read it!

In this issue, we evaluate our work done for the recently closed quarter (January-March 2025), we present you a number of video and blogpost about us to watch and read, and we take a look at the latest software developments.

Want to catch up with the previous updates? Check our archive!

Also we remind you that the next Natural Language Generation Special Interest Group meeting will be held on April 15, at 16:00 UTC (link to the meeting).

Enjoy the reading! -- User:Sannita (WMF) (talk) 11:20, 11 April 2025 (UTC)

Using functions on main page

Now that functions can be used on wikitext pages on wikifunctions.org, I think it would be a good idea to use at least a few of these functions on the main page. Additionally, while we are at it, it would be a good idea to update the welcome section with current goings-on. Feeglgeef (talk) 19:09, 16 April 2025 (UTC)

Yes this is a good idea from my point of view. What functions do you want to publish there. I think for example a function to get difference between two dates would be interesting. Another thing is the information how many months Wikifunctions exists so far. Hogü-456 (talk) 21:07, 16 April 2025 (UTC)

Although we can’t actually count the number of functions, I think we could replace the plaintext count with a function that formats the value of some Natural number object. Picking up on @Hogü-456’s suggestion, we could have a Wikifunctions data object (a list destined to become a map), and select the required datum from there. GrounderUK (talk) 08:51, 17 April 2025 (UTC)

Is it possible to count the number of functions with a script. At Special:ListObjectsByType I have not found the total number of functions as the count is not related to the total number of objects of the selected type and instead to the objects displayed. Hogü-456 (talk) 20:53, 18 April 2025 (UTC)

Yes. I meant we can’t have a Wikifunctions function that counts them, but we could have a function that displays the count according to language and rounded appropriately. GrounderUK (talk) 23:07, 18 April 2025 (UTC)

Wikifunctions & Abstract Wikipedia Newsletter #198 is out: Wikifunctions integrated in Dagbani - and Wikifunctions; and the date of Easter

There is a new update for Abstract Wikipedia and Wikifunctions. Please, come and read it!

In this issue, we announce that this week we switched on the ability to call Wikifunctions functions from within Dagbani Wikipedia (our first wiki to do so!), we discuss the functions related to calculating the dates of Easter, and we take a look at the latest software developments.

Want to catch up with the previous updates? Check our archive!

Enjoy the reading! -- User:Sannita (WMF) (talk) 14:29, 17 April 2025 (UTC)

proposed Display functions for Day of the week Type

I suggest we use the following functions as a display function for the Day of the week Type:

• display day of the week (Z24041): returns a string representing the day of the week (a Wikidata label) in exactly the selected language, or a blank string

Types without display functions aren't supported when called from Wikipedias, so IMO it is a priority that we continue to connect display functions. --99of9 (talk) 12:35, 19 April 2025 (UTC)

Support That function works pretty well, thanks for your contributions 99of9! ~/Bunnypranav:<ping> 12:43, 19 April 2025 (UTC)

You're welcome. Though most of the credit for the hard work done on this one goes to GrounderUK (talk · contribs). --99of9 (talk) 12:53, 19 April 2025 (UTC)

I have no problem with the function, but I do have reservations about setting an unfortunate precedent by relying on labels. I think the “officially correct” approach would be to go from the Wikifunctions object to the corresponding Wikidata item and from there to the item’s lexeme and the appropriate form/representation. Failures are possible, of course, and we have two fallback routes to consider, according to the language.

First, for language varieties with a lot of overlap, like Australian English and (en) English, we should fall back to the more common variety. (Note that the function currently returns a blank for Australian English. I imagine that the general fallback for Australian English would be to British English before (en) English, with US-English as a last resort, but even this simple example leads us into treacherous waters.)

Secondly, (also by language), whether we prefer labels to lexemes or a specific function, or (assuming defaults are excluded or handled when a specific function is the option) lexeme/label first then label/lexeme in specified language, or lexeme/label in any fallback language then label/lexeme in any fallback language… and then our default (fall-through) option.

How might this work in practice? We could have a Configuration of functions for given languages (Z14294) that would handle the second cases first. For example, English might be set to prefer labels whereas Italian might prefer lexemes (because « domenica » is feminine whereas other days are masculine, so we’d have « domenica prossima » (“next Sunday”) but « lunedì prossimo » (“next Monday”), per esempio). I guess we’d have separate functions for label then lexeme, lexeme only, lexeme then label, label only; the default function here might also be configured by language for a “native Wikifunctions” experience.

However, configuration by language doesn’t allow the specified language to be switched (from “en-au” to “en”, for example). This suggests that language-switching should be handled separately in the configured functions. It might be a common function, but the sequence may differ according to whether you're looking for labels or lexemes. In any event, I suspect that "language" is better specified as a list, with an empty list defaulting to "mul" (say) and falling through to the default specified in the configuration (or a "mul"-specific alternative). (And when I say “list”, I suppose it would have to be a string representation, for integration, so we might see something like “[Z60, "dag", "en", "mul"]”. I guess we can’t use a read or display function for a generic type, though, and perhaps that challenge is better considered under a separate heading.) GrounderUK (talk) 11:46, 20 April 2025 (UTC)

Good thoughts. I think your proposed "officially correct" function would be worth writing (as would some of the variants you mention), and may indeed work even better for some languages. For language fallbacks, I think we can get separate functions to handle that without changing the input type of a display function. It will take some building, and will be more than a configuration by language, but I don't think it will be too much worse. Just as you were posting this, I was writing a crude language fallback map: general language from language variant (Z24097) as a start! --99of9 (talk) 12:10, 20 April 2025 (UTC)

Update: I've now adjusted the implementations to use the general language fallback if variants (like en-au) come up empty. And the test Saturday in Australian English is en:"Saturday" (Z24105) now passes (with a long runtime). --99of9 (talk) 12:42, 20 April 2025 (UTC)

Perhaps “crude” is a little harsh… but switching between “nn” and “no” then falling back to “sv” or “en” (according to personal preference) is the sort of scenario we might contemplate. One step at at time, though… so long as we don’t trip over one another’s feet! (You have a free run today, as far as I’m concerned! When I get started, I’m more interested in pursuing the lexeme route, but I want graceful fallback from Find lexemes for a Wikidata item (Z6830) outwards, and that means the option to switch languages if no lexeme is found, and (logically) a list of properties to work through too. Although such searches may have less of a performance overhead than item labels, I guess we’d only be able to manage a couple if we want to be able to default to labels afterwards.) GrounderUK (talk) 13:16, 20 April 2025 (UTC)

I'm not aiming for personal preference, because in my understanding display functions will generally apply to all users of a uselang. So I'm just aiming for the best (configurable) outcome for every language. For now I'll stick within the label space rather than the lexemes, but I agree it would be good to have a robust lexeme path available too. --99of9 (talk) 13:27, 20 April 2025 (UTC)

You’re probably right, but I’m speculating that a personal preference and a project default could/should/would look the same at the function level. GrounderUK (talk) 14:25, 20 April 2025 (UTC)

Althouh we obviously want as much progress on lexemes as possible, I've realised that I don't agree it is "officially correct" for display functions. These are rendered output of single day values in a language, not lexically correct parts of a sentence. I think the intent is almost exactly coincident with the intent of a Wikidata label. 99of9 (talk) 01:03, 21 April 2025 (UTC)

I take your point. Without phab:T366459, the display function cannot display the Wikifunctions object label, and even assuming the counterfactual, I can see the sense in defaulting to the label for the corresponding Wikidata item. Presumably, this is how “light-weight enumerations” (T390558) will operate, since there will be no persistent instances to which to attach labels. In any event, as I said before, “I have no problem with the function” and I am happy to withdraw my remark about the lexeme route being « “officially correct” ». (@DMartin (WMF) Any thoughts about displaying the string for a light-weight enumeration? Does the generic type get read and display functions?)

That having been said, the performance is a concern and I am getting a time-outs for Thursday in a language-fallback scenario like (en) “Tuesday” from (Tuesday, “simple”) (Z24106). I suggest we defer language-fallback until we can return multiple selected labels from a single visit to an item. I just used apply a two-parameter function to a common first argument and a list of second arguments (Z13436) in Wikidata lexemes available, Composition (Z24109) to support Wikidata lexeme references for multiple languages (Z24110) but I think “label-list from item for language-list” will require a code implementation, in the absence of a variadic filter function (T390226). I’ll get started on that. GrounderUK (talk) 08:38, 21 April 2025 (UTC)

Renderlang and parselang

From the documentation it's said that you can set the render and the parse language in function calls from Wikipedia, but they don't seem to work. Are they actually supported? Dv103 (talk) 16:38, 19 April 2025 (UTC)