Wikifunctions:Project chat/Archive/2025/06

Wikifunctions & Abstract Wikipedia Newsletter #205 is out: Where will Abstract Content go?

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

In this issue, we give you some updates on the discussion about where to store abstract content, we present you the recordings of our latest presentations and meetings, 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) 13:38, 9 June 2025 (UTC)

This section was archived on a request by: Sannita (WMF) (talk) 13:21, 16 June 2025 (UTC)

Import citation related templates

It looks like Template:Cite web and similar templates are being used on this wiki while they don't exist. Would it be possible to import them from the English Wikipedia? Laura240406 (talk) 15:35, 17 June 2025 (UTC)

@Laura240406 What do you think is the need of having cite templates here? I do not think that they will be useful, since our project does not host raw wiki content (atleast as of now). ~/Bunnypranav:<ping> 15:38, 17 June 2025 (UTC)

e.g. to link to a specification but I can also see why it might be unnecessary since one could just link to it normally Laura240406 (talk) 15:40, 17 June 2025 (UTC)

@Laura240406: Thanks for flagging; I've removed the one attempted use of that template. Jdforrester (WMF) (talk) 18:28, 17 June 2025 (UTC)

This section was archived on a request by: 99of9 (talk) 06:41, 25 June 2025 (UTC)

Change integer to natural number request

Hey, I've only now noticed that some of the functions I wrote only deal with positive integers and should use Natural number (Z13518) instead of Integer (Z16683).

Could someone with sufficient rights change the types of the following functions:

• RSA derive d (Z25404)
• ChaCha20 (Z25376)
• FNV-1 (64 bit) (Z25416)
• FNV-1a (64 bit) (Z25419)

and also delete the following tests since they're pointless now:

• Unlabelled (Z25389)
• Unlabelled (Z25388)

Thanks :) Laura240406 (talk) 21:21, 19 June 2025 (UTC)

Hi @Laura240406 - Thanks for these contributions! I've just changed each Integer I/O type to Natural number. I didn't look at the implementations, but I assume you will be updating them appropriately. Regarding the tests to delete, there is a procedure for getting something deleted but I'm not completely up to date on that. I think there's a place to list things that should be deleted. If someone has that info handy, please post it here. DMartin (WMF) (talk) 02:20, 20 June 2025 (UTC)

thanks Laura240406 (talk) 08:21, 20 June 2025 (UTC)

Just noting here that the deletion has been done per Special:Permalink/195269#ChaCha20 tests ~/Bunnypranav:<ping> 12:18, 20 June 2025 (UTC)

This section was archived on a request by: 99of9 (talk) 06:41, 25 June 2025 (UTC)

Raw type editing

I've recently requested to change some types of functions I created (see topic above) since I don't have the rights to do so myself. I've just realized that I can change the types by manually editing the JSON of a function with this userscript.

I ran into a similar Integer vs Natural number issue but I managed to change it myself.

Is this intentional or is this a security issue? Laura240406 (talk) 06:32, 22 June 2025 (UTC)

btw I've only done this to functions where I wrote all of the implementations and tests and that aren't connected or used anywhere as to not cause any disruption Laura240406 (talk) 06:34, 22 June 2025 (UTC)

I think anyone registered user can edit functions which do not have connected implementations. Functioneers can in practice also edit the types of other functions, since they can disconnect the impl.s, and then edit it. ~/Bunnypranav:<ping> 07:04, 22 June 2025 (UTC)

hmm okay yeah makes sense, the option to edit types of unconnected functions doesn't appear for me for some reason Laura240406 (talk) 07:12, 22 June 2025 (UTC)

I managed to change it for Z25557 using my alt which does not have functioneer, see Special:Diff/195742. You go into Edit source and then just enter the new type under each input/output's Type dropdown. ~/Bunnypranav:<ping> 07:24, 22 June 2025 (UTC)

ahh okay thanks

It looks like the "Edit source" mode is different from the usual label editing mode when you click on the pen icon. That's what confused me. Laura240406 (talk) 09:18, 22 June 2025 (UTC)

Happy to help :) ~/Bunnypranav:<ping> 09:19, 22 June 2025 (UTC)

This section was archived on a request by: 99of9 (talk) 06:42, 25 June 2025 (UTC)

Help with template translation

Hi. I made a minor edit to {{userpage/text}} to make it compatible with dark mode, but its translations, such as {{userpage/text/en}}, have not been updated. It won't let me edit the translation directly, and the translation tool disables translations from en to en. Is it possible to edit the translation? Thanks. [​[User:CanonNi]​] (💬 • ✍️) 13:27, 22 June 2025 (UTC)

@CanonNi, No, you cannot edit the source code of a translation page, maybe Ameisenigel can help by marking changes for translation. Next time, it's better to visit this page: Translators' noticeboard --Mohanad (talk) 01:19, 27 June 2025 (UTC)

Yes, the page needs to be marked for translation again. This is now done. --Ameisenigel (talk) 02:51, 27 June 2025 (UTC)

Thanks a lot. [​[User:CanonNi]​] (💬 • ✍️) 03:29, 27 June 2025 (UTC)

This section was archived on a request by: [​[User:CanonNi]​] (💬 • ✍️) 03:31, 27 June 2025 (UTC)

Solvers (and color spectrum reconstruction.)

I am posting here as I wasn't sure how to define it formally for requesting directly.

A specific spreadsheet used for reconstructing approximate 'reflectance' data from RGB triplets, uses the Generalized Reduced Gradient(GRG) solver from Excel. This doesn't exist in Libre Office.

That spreadsheet is linked from ( http://scottburns.us/reflectance-curves-from-srgb-10/.(Burns,2025) The author also links - http://scottburns.us/matlab-octave-and-python-source-code-for-refl-recon-chrom-adapt/ (I don't see a license indication, but the authors are approachable, and have licensed some of their online contributions under Creative Commons, and I've already suggested they look into writing a contribution for Wikiversity under Open Access.)

My understanding of what the GRG does is that for a range of input values, a function is setup for the results set, with the sum of the intermediate steps having to meet some 'goal'(in the linked use case a 'minimized' value, these intermediate calculations being used to generate a set of finalised 'results'.

In the use case for (Burns,2025), the results set obtained through the GRG approach, is further constrained. Namely that an XYZ color, obtained from applying CIE observer functions to the generated 'reflectance' data must match a pre determined input XYZ color, although obtained by applying a suitable conversion from an sRGB triplet).

Would it be possible for some kind of 'solver' function/algorithim to be considered for Wikifunctions, to allow for the kinds of approaches taken in Burns, to be developed or expanded upon?

I appreciate the specific use case is a bit niche, and implentations are possibly beyond me, but having 'solvers' would be useful I think.

As an aside, having Wikifunctions able to make use reconstructed 'refelctance' data for typical RGB triplets might prove useful long term, especially if the approach can be extended to approximate for any 'color' ( such as xyz spaces recently added in CSS and recent browsers). A different author (Ronald Van Winjen, 2025), also uses approximated reflectance curves to implement a 'pigment' style subtractive color mixing 'function' as Spectral.js (https://github.com/rvanwijnen/spectral.js). (That code is under MIT license, and uses a faster but possibly less specfic approximation technique.)

My apologies if I sound a bit more formalised in places, and if opthers are able to improve the referencing , feel free. ShakespeareFan00 (talk) 08:59, 5 June 2025 (UTC)

Many solvers use something like w:Newton's method. We have a few functions that attempt something like this (Z24539, Z24553) which you could have a look at to incorporate into your colour analysis field. --99of9 (talk) 05:04, 6 June 2025 (UTC)

Actual coding is beyond my expertise, but I figured I'd put the suggestion down for future reference. In Excel what it's doing is 'guessing' for an entire set of vlaues and tweaking those at goes I think. The estimation method you linked is for a single value, not a constrained set I think. ShakespeareFan00 (talk) 11:22, 6 June 2025 (UTC)

A guide to easily implement a lenient Gregorian calendar date reader

I have created a guide on how to implement a specialisation of read Gregorian Calendar Date (Z20808) for new languages (since for now it is specialised only for English, Italian and Dagbani, while all the other languages have to rely on the suboptimal generic reader). I hope it is easy to understand (otherwise let me know). At the end I also added the instructions on how to implement a localised version of the function read Day of Roman Year (Z24990), even if is not yet the Day of Roman year (Z20342) reading function. Dv103 (talk) 14:09, 9 June 2025 (UTC)

This is fantastic - those implementations can be a bit intimidating! I hope we can set the read/display for Z20342 soon. --99of9 (talk) 14:59, 9 June 2025 (UTC)

equality function for Time of day

@DMartin (WMF) Please can you add same times (Z25098) as the equality function for Time of day (Z6060)? --99of9 (talk) 12:58, 12 June 2025 (UTC)

Okay, that's done. Thank you! DMartin (WMF) (talk) 17:07, 12 June 2025 (UTC)

FYI: The fastest way to detect a vowel in a string

https://austinhenley.com/blog/vowels.html ―Justin (koavf)❤T☮C☺M☯ 01:32, 14 June 2025 (UTC)

proposed Read and Display functions for Day of Roman Year

I suggest we use the following functions as a read and display function for the Day of Roman year (Z20342) Type:

• read Day of Roman Year (Z24990)
• display Day of Roman Year (Z22941)

The reader is intended to be as lenient as possible, but splits by language for specific month names and ambiguity. If there are other possible input formats, feel free to extend it to include them.

The display is configured by language. Choose the function appropriate to your language!

Thanks User:Dv103 for all the work on the read functions. --99of9 (talk) 00:01, 11 June 2025 (UTC)

@DMartin (WMF) Dv103 (talk) 07:51, 17 June 2025 (UTC)

These look good to me, and I've added them to the definition of Day of Roman year (Z20342). Thanks to both of you for making them available! DMartin (WMF) (talk) 05:52, 19 June 2025 (UTC)

Thanks! --99of9 (talk) 05:56, 19 June 2025 (UTC)

This section was archived on a request by: Denny (talk) 13:25, 15 July 2025 (UTC)

code conversion for Time of day

I've written some code conversion functions for Time of day (Z6060). The details for this were not discussed in the type proposal Wikifunctions:Type_proposals/Wikidata_time apart from "We expect to get started by relying on the existing default conversion strategy; something more sophisticated could come later if needed." I've followed that (just three keys for both languages, K1=hours, K2=minutes, K3=seconds). But if anyone knows of a more suitable in-code representation of 24 hour times, please speak now, because IMO it is very challenging to change the code conversion after many code implementations have been written. My draft conversion functions are:

• Python converter from Time of day (Z25175)
• JavaScript converter from Time of day (Z25176)
• Python converter to Time of day (Z25177)
• JavaScript converter to Time of day (Z25178)

Since staff have usually written our conversion functions, I'm specifically hoping that @DMartin (WMF) and @DVrandecic (WMF) @Denny will have a chance to review and discuss these. --99of9 (talk) 05:54, 13 June 2025 (UTC)

A "native" time-of-day type for JavaScript, Temporal.PlainTime, is currently recommended for implementation meaning it will be standardised as soon as Chrome and Safari finish their implementations. I'm guessing it's not available here either. YoshiRulz (talk) 09:48, 13 June 2025 (UTC)

Should be be asking @DMartin (WMF) for a fourth (optional?) key to represent subseconds? Or maybe the third key should be rational? 99of9 (talk) 22:27, 13 June 2025 (UTC)

Regarding one or more additional keys to represent subseconds, that's easy to do; just didn't know if there would be a demand for that. DMartin (WMF) (talk) 05:30, 17 June 2025 (UTC)

@YoshiRulz: Note that we don't run either Chrome or Safari (or Firefox or any other browser) to run user-written code, but QuickJS, so we'll have to evaluate when that will be available. Jdforrester (WMF) (talk) 13:53, 16 June 2025 (UTC)

Yes, very happy to have these conversion functions; thanks so much! I didn't have time to review them today but should be able to get to it tomorrow. DMartin (WMF) (talk) 05:28, 17 June 2025 (UTC)

The conversion functions look fine to me; thanks again for them. Regarding entering them in the type definition, if it's okay I'd like to hold off another day Or two in case anyone else wants to comment. Denny and one or two others have more experience with conversion functions. DMartin (WMF) (talk) 05:58, 18 June 2025 (UTC)

Okay – I took another look at the conversion functions and, in the absence of any other comments, I have added them to the type definition. Thanks again! DMartin (WMF) (talk) 21:27, 22 June 2025 (UTC)

This section was archived on a request by: Denny (talk) 13:25, 15 July 2025 (UTC)

Wikifunctions & Abstract Wikipedia Newsletter #206 is out: Closing the consultation about the location of Abstract Content

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

In this issue, we announce the closing of the discussion about where to store abstract content, we remind you about our current discussions about types and our next NLG SIG meeting, 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) 12:56, 16 June 2025 (UTC)

This section was archived on a request by: Denny (talk) 13:25, 15 July 2025 (UTC)

Wikifunctions & Abstract Wikipedia Newsletter #207 is out: Quarterly Planning for July–September 2025

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

In this issue, we outline our priorities for the next quarter (July–September 2025), we give you some updates related to our new types, 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) 12:38, 23 June 2025 (UTC)

This section was archived on a request by: Denny (talk) 13:25, 15 July 2025 (UTC)

proposed JavaScript conversion functions for Wikidata quantity

I've prepared the following JavaScript conversion functions:

• Convert to Wikidata quantity, JavaScript (Z25704)
• Convert from Wikidata quantity, JavaScript (Z25698)

Feedback is welcome; I'm still gaining experience in writing conversion functions. Since Wikidata quantity contains 3 Rational number (Z19677) elements, I copied code from the JavaScript conversion functions for Rational number. I'm planning to create similar Python conversion functions tomorrow. (But if anyone is already working on those, please let me know.)

Hi User:DMartin (WMF). My first impression was that you can save a few lines by not redefining gcd over and over. But I wonder if in this case it would actually help us not to simplify the fractions at all. This is because they can be used to retain the number of decimal places. For example, maintaining the difference between 5/1000 (from 0.005) and 50/10000 (from 0.0050) helps us to respect the precision of the incoming data. Any time they get sent into actual rational number functions, this will dissolve, but for formatting functions and similar, it would help to keep them unsimplified. This would especially apply to Z25698, but maybe also Z25704. --99of9 (talk) 05:14, 25 June 2025 (UTC)

Thanks @99of9! Of course you're right about redefining gcd, and I also like the idea of not simplifying the fractions. I'll make those changes. Furthermore – I communicated with the team about this, and turns out it should be possible to define a function inside of a function (i.e., I could define convertRational inside of the Wikidata quantity conversion function, and call it 3 times). I may also try that. DMartin (WMF) (talk) 14:30, 25 June 2025 (UTC)

I've been through these once more, and don't have any further suggestions. --99of9 (talk) 03:35, 26 June 2025 (UTC)

Thanks! I've just added them to the type definition. DMartin (WMF) (talk) 04:25, 26 June 2025 (UTC)

This section was archived on a request by: Denny (talk) 13:25, 15 July 2025 (UTC)

proposed Python conversion functions for Wikidata quantity

I've prepared the following Python conversion functions:

• Convert from Wikidata quantity, Python
• Convert to Wikidata quantity, Python

Feedback/discussion is welcome! A couple notes:

• Based on previous discussion where we decided not to reduce rational numbers to lowest terms, I am not using Python's fractions module, because it reduces to lowest terms. Therefore, each nested instance of Rational number (Z19677) is converted to a simple python dict. (Of course, a function writer can still choose to use the fractions module if desired.) Therefore, conversion of Rational numbers inside Wikidata quantity happens differently than conversion of non-nested Rational numbers, and this could occasionally be a source of confusion.
• I've used a couple nested functions in Convert to Wikidata quantity, Python (Z25827), which makes the code nicer, but haven't yet done that in Convert from Wikidata quantity, Python (Z25784). DMartin (WMF) (talk) 23:50, 26 June 2025 (UTC)

After some more testing and a few small revisions, I've added these conversion functions to the type definition. DMartin (WMF) (talk) 05:16, 1 July 2025 (UTC)

This section was archived on a request by: Denny (talk) 13:25, 15 July 2025 (UTC)

proposed Read and Display functions for Time of day

I suggest we use the following functions as a read and display function for the Time of day (Z6060) Type:

• read Time of day (Z25118)
• display Time of day (Z25091)

The reader is intended to be as lenient as possible, but splits by language for names of am/pm and specific times. If there are other possible input formats, feel free to extend it to include them.

The display is configured by language. There are so many possible formats for 12-hour times ("am"/"AM"/"a.m."/"A. M."/etc). Write a function appropriate to your language!

Thanks User:Dv103 for all the work on the main read function. --99of9 (talk) 06:37, 25 June 2025 (UTC)

Outstanding! Love the range of formats that can already be read. Thanks! I've just entered them in the type definition.

One question, just curious – where's the code that handles the Japanese test cases? Just from glancing through the implementations I didn't see anything that looked like them. DMartin (WMF) (talk) 01:34, 26 June 2025 (UTC)

You're right, there's no jp-specific code. The Japanese gets lucky that the digit 0 is in the midnight example, and the numeral 12 appears in one of the noon ones. Those get mapped by the default that ignores everything in the string except numbers. --99of9 (talk) 01:40, 26 June 2025 (UTC)

This section was archived on a request by: Denny (talk) 13:25, 15 July 2025 (UTC)

Proposed display function for Wikidata datetime

I've prepared the following printing function for Wikidata datetime (Z6061), that simply concatenates the Gregorian calendar date (Z20420) and the Time of day (Z6060) printing functions:

• display Wikidata datetime (Z25721)

It always assumes that the date is of type Gregorian calendar date (Z20420), since the Julian calendar is not supported yet. While this printing function should work for most languages, it is possible to coustomize it for specific languages. If "mul" is used as the printing language, it uses the ISO 8601 format yyyy-mm-ddThh:mm:ss. Dv103 (talk) 08:41, 25 June 2025 (UTC)

And same Wikidata datetime (Z25758) could work as the comparing function for Wikidata datetime (Z6061). Dv103 (talk) 14:00, 25 June 2025 (UTC)

Excellent! I've just entered both of these functions in the type definition. Thank you! DMartin (WMF) (talk) 04:16, 26 June 2025 (UTC)

This section was archived on a request by: Denny (talk) 13:25, 15 July 2025 (UTC)

equality function for Wikidata quantity

@DMartin (WMF) please can you set identical quantity (including bounds) (Z25286) as the equality function for Wikidata quantity (Z6010). Secondly, is there a reason not to rename it just as "quantity"? I understand that it needs to be structured like this to be consistent with Wikidata, but it seems general enough to use it for quantities from other sources too? 99of9 (talk) 03:26, 16 June 2025 (UTC)

I wouldn't be so sure about considering it the default type for quantities, mainly because it is quite difficult to do arithmetic with it (how do you multiply the units? Do you have to mantain a database of all the compounds units in Wikidata? What if you need a compound unit that doesn't have a Wikidata item?). Dv103 (talk) 06:59, 16 June 2025 (UTC)

How about "quantity with units" then? I'm not giving up on processing units, but all the questions you ask are certainly challenging. --99of9 (talk) 08:22, 16 June 2025 (UTC)

I don't know how we should call Wikidata quantity (Z6010), but to process units I think it is necessary to create a new type to actually represents units in a way that can be worked with. Wikifunctions:Type proposals/SI units should be a good starting point (even if, as I already mentioned in the comments section of the proposal, I think that it should be better to support all the units, even non-SI ones). Dv103 (talk) 08:34, 16 June 2025 (UTC)

Yes, I've been thinking about your challenge to support all the units. I'm still hoping we can support many units using the statements on the Wikidata items, together with some lookup tables. --99of9 (talk) 12:56, 16 June 2025 (UTC)

I actually have in mind an alternative model to represent all the units. When I have time I'll try to write it down. Dv103 (talk) 13:04, 16 June 2025 (UTC)

If there's going to be a ranged quantity without units, then maybe we should be using that as the first key for this Type. Gradually building the hierarchy up like we do for the dates. 99of9 (talk) 08:23, 16 June 2025 (UTC)

I have already tried to propose Wikifunctions:Type proposals/Value with error. It actually represents a concept that is a bit different than the Wikidata ranged quantity, since the ranged quantity defines the bounds whithin which the real value is surely placed (at least, this is the intrepretation I understood from the documentation, but maybe I'm wrong), while the value with error would represent the gaussian error of the value. Even if those two concept seem very similar, they are actually different, and behave very differently in mathematical operations. Both those concept can be useful in real life; in science, the gaussian error is usually used, while the maximum error is useful in many ingegneristic environments when you need precice bounds. Dv103 (talk) 08:45, 16 June 2025 (UTC)

The bounds in Wikidata are sometimes used to represent precise bounds but sometimes used to represent statistical uncertainties (one sigma or two?). To be clearer they could have qualifiers attached, but I haven't looked into that deeply. Your proposed Value with error is a simpler structure anyway, assuming symmetric errors. I'm not sure which would get more use. --99of9 (talk) 12:53, 16 June 2025 (UTC)

In Wikidata I've seen both usages without qualifiers, so when we use Wikidata values in Wikifunctions it's our duty to interpret the data correctly. My proposal has a deribelately simple structure, since it's the current standard for scientific calculations: it's easier to handle and most of the times it's the better we can do (we usually have very little information about the error itself, and have no idea about its asymmetry). In science, the convention is to consider as the error the width of 1 sigma (meaning that we think that the probability of the real value being inside the error is about 2/3).

That said, in an ideal world both error should be used in the right contexts, but (as Wikidata proves) in real life those two concepts are many times conflated, and this is why I think we should be very cautious when handling errors. Dv103 (talk) 13:22, 16 June 2025 (UTC)

Regarding Wikidata quantity (Z6010), currently it's declared to represent units as Wikidata item references (Z6091), but it could be loosened up. The Wikidata documentation allows for the value of unit to be any IRI. So far I've only encountered values that refer to Wikidata items, but if there are other IRIs we could just import them as strings. So sometimes the unit property might have a Wikidata item reference, and other times a string. Would that be helpful? DMartin (WMF) (talk) 19:14, 16 June 2025 (UTC)

Personally I'd prefer not to loosen it unless Wikidata are genuinely using other IRIs. This is already a complex time to deal with, and the units will be the trickiest bit to deal with well, but while they are QIDs we have a good chance of extracting more info from Wikidata statements about them. --99of9 (talk) 02:31, 17 June 2025 (UTC)

Sounds good; I agree, at least for now. However, for now if we receive a Quantity from Wikidata having an IRI that's not an entity reference, the statement containing that Quantity will be dropped (not imported). I've put in logging statements to alert the team to any such cases that come across. Also, I've made a ticket to add warnings that come back to the UI in the function call metadata (Details). DMartin (WMF) (talk) 05:20, 17 June 2025 (UTC)

Sounds good for now. --99of9 (talk) 06:14, 17 June 2025 (UTC)

I set identical quantity (including bounds) (Z25286) as the equality function for Wikidata quantity (Z6010). Thanks! Regarding the name of the type, yeah I briefly considered naming it "quantity". After a bit of discussion we felt like we shouldn't claim that most general name for something that was pretty clearly tied to Wikidata structure. That is, we figured things could evolve towards recognizing a need for something that's more general. Anyway, the labels can easily be changed in future of course. DMartin (WMF) (talk) 05:26, 17 June 2025 (UTC)

Cheers, that will take a step out of creating tests. --99of9 (talk) 06:15, 17 June 2025 (UTC)

proposed Display functions for Wikidata quantity

Tracked in Phabricator:
Task T397660

I suggest we use the following functions as a display function for the Wikidata quantity (Z6010) Type:

• display quantity with digits and unit (Z25326)

This would replace the very simple default @DMartin (WMF) put in place to get it working:

• Simple display of Wikidata quantity (Z25620)

The new one deals more cleverly with bounds, and meets most of the objectives in the Phabricator task. It is configured by language. Choose the function appropriate to your language! --99of9 (talk) 12:42, 24 June 2025 (UTC)

Looks great to me! Thanks a million ([≥999,999; 1,000,000; ≤10,000,000])! I will go ahead and declare it as the display function.

Just one small thing occurs to me – are we confident that every unit item has a P5061 statement (either in English or the designated language)? Denny told me there are over 3300 units in use. If A unit doesn't have the desired P5061 statements, it might be helpful to return the item's label (from the designated language, if available or English label as fallback). Not saying it's high priority, though. DMartin (WMF) (talk) 22:51, 24 June 2025 (UTC)

Thanks. In general I don't mind if an absence of data has the consequence of pointing users toward improving the data source. But I agree, a more reliable fallback would be nicer. --99of9 (talk) 05:03, 25 June 2025 (UTC)

Something I just learned: due to implementation requirements, a display function will only be used (in the UI presentation of a ZObject) if both the display and reader function have been registered (declared in the type definition). Has anyone started on the reader function for Wikidata quantity, or has plans to? DMartin (WMF) (talk) 14:37, 25 June 2025 (UTC)

I suspected something like this because Denny always did them together. I'll get there eventually, but haven't started yet. I'm enjoying your enthusiasm for connecting supporting infrastructure. See the following sections for a couple of things that are ready. 99of9 (talk) 21:23, 25 June 2025 (UTC)

@DMartin (WMF) I got this working read Wikidata quantity (Z25785). Likely the most complex function I've written to date. I needed to create 11 new helper functions on top of what we already had. It can read in any of the three formats that the display function outputs (exact value, symmetric error, asymmetric bounds), including language configuration. But it's not flexible enough to include people making up their own formats (some may accidentally work, but others will crash). For all of them it jumps through all the required hoops to preserve the original unsimplified decimal ratio implied by the amount in the string. For the unit key, QID from unit symbol (Z25792) is fun. It looks up a giant dictionary of all unit symbols that were downloaded from a SPARQL query from Wikidata. That means that every symbol set in Wikidata will work, but some will be ambiguous because two QIDs have the same unit symbol. In those cases, I've defaulted to the lowest value QID (the first created). I think this is a reasonable heuristic guess for what the user will usually want, but sometimes they will need to check and change the QID it comes up with. --99of9 (talk) 13:34, 27 June 2025 (UTC)

I just remembered it relies on the rational number reader, which means that it will sometimes stumble with cases like "99,999" in English is 99999/1 (Z25846) where ambiguous commas default to a radix but are actually a separator, because we haven't configured the rational number reader by language yet. That fix should be easy enough, but I'm done for the evening. --99of9 (talk) 13:43, 27 June 2025 (UTC)

Thanks for the great work on this! Excellent to have both Read and Display working. Good to know that a large lookup table is workable, and thanks for documenting the query. I've connected both of them, but one note for now:

• Unfortunately, we won't get the full benefit of the Display function until this issue is resolved, which should happen by Wednesday at the latest. This is because many Wikidata entities contain both quantities and time values, and currently fetching of entities with times is broken.

DMartin (WMF) (talk) 16:19, 29 June 2025 (UTC)

Catalogue display issue

Tracked in Phabricator:
Task T399081

I was browsing Wikifunctions:Catalogue/String operations and noticed that labels and descriptions for each function, which are normally shown by the Z+ template, aren't. I've tried clearing my cache and purging the page, but no luck. Is anyone else experiencing this? [​[User:CanonNi]​] (💬 • ✍️) 13:03, 26 June 2025 (UTC)

That does not seem to work with the Parsoid update. Works with using the legacy parser with &useparsoid=0 at the end (try the link). ~/Bunnypranav:<ping> 13:17, 26 June 2025 (UTC)

Yeah, that works. Thanks! I guess I'll just use the old parser on Wikifunctions then. [​[User:CanonNi]​] (💬 • ✍️) 13:23, 26 June 2025 (UTC)

Unfortunately, that is the only option. But it will also break the Wikifunctions function to wikitext output integration as well though. Is there a way to fix that template to work with new parser, perhaps using the {{#function: feature itself to get the label of a function? ~/Bunnypranav:<ping> 13:28, 26 June 2025 (UTC)

The object label (Z16568) function is not currently an available function for the #function feature. See phab:T366459; it may now be possible to return a quoted ZReference for an input ZID string, which might allow the #function feature to be used. The Z+ template returns the Z2K5/short description rather than the Z2K3/label, however, so an equivalent for object labels (Z16556) would also be required (straightforward apart from the call to fetch Persistent object (Z828)). GrounderUK (talk) 16:22, 26 June 2025 (UTC)

It seems the Z template is similarly afflicted. GrounderUK (talk) 16:25, 26 June 2025 (UTC)

I swear it was working with Parsoid enabled as recently as last week, when I read the newsletter. Was there an update to the parser? YoshiRulz (talk) 20:52, 28 June 2025 (UTC)

I’ve switched off parsoid but I only get the labels, not the descriptions. I think https://gerrit.wikimedia.org/r/1167859 may (intentionally) support fixing only the Z template, not the Z+ template that Wikifunctions:Catalogue relies on. @Sannita (WMF) I’m thinking the catalogue issue will not be fixed soon. Do you think we should add something to the Wikifunctions:Status page if there is no immediate plan to get Z+ working again? (phab:T399081 refers only to the Z template but if we don’t fix Z+ “somehow”, we’ll have to re-write the catalogue and (worst case scenario) make it translatable.) GrounderUK (talk) 10:15, 16 July 2025 (UTC)

@GrounderUK Let's keep that as a worst case scenario solution. I'll see if we can work on a fix also for the Z+ template. Sannita (WMF) (talk) 10:17, 16 July 2025 (UTC)

We could for now at least use the label when someone calls Z+ -- that should be at least a bit helpful with the catalogue (more than just the ZID for sure). For the description, I'll check in what options we have. My understanding is that we could maybe provide a parser function that gives the description, or we could do the same trick as we did with the label and put it into the page properties as well. But for now I think it would be great if we update the Z template, and maybe at least show the label for Z+, but keep this open as a task until the description is solved too. What do folks think? --DVrandecic (WMF) (talk) 11:05, 18 July 2025 (UTC)

Seems sensible. Anything is better than nothing! --99of9 (talk) 12:09, 18 July 2025 (UTC)

Agreed. We should aim to get the Catalogue back to how it was before it broke, but just displaying the linked label with parenthetical ZID (current behaviour when not using Parsoid) is preferable to just showing a linked ZID (current behaviour when using Parsoid). That said, we could consider an embedded function that returns just the supplementary text. As I understand it, that’s not currently feasible for the description until we get phab:T366459, but it would pave the way for extended Catalogue entries that would include the function signature, for example. A parser function could do that too, I suppose. GrounderUK (talk) 14:07, 18 July 2025 (UTC)

Hmm, since the patch has been deployed, I wanted to give it a try and fix the Z template, but I have no idea how to access a page property from wiki, and couldn't find any documentation. Asking around. --Denny (talk) 16:17, 19 July 2025 (UTC)

Looks like @Jdforrester (WMF) has fixed both {{Z}} and {{Z+}}. Thanks to all involved! Done GrounderUK (talk) 17:12, 21 July 2025 (UTC)

This section was archived on a request by: Dv103 (talk) 08:27, 12 August 2025 (UTC)

Wikifunctions & Abstract Wikipedia Newsletter #208 is out: How many people are needed to write an encyclopedia?

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

In this issue, we share a short essay from Denny about writing an encyclopedia, 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) 15:38, 28 June 2025 (UTC)

I read the part about how many people are needed to write an encyclopedia. From my point of view it is not possible to estimate the number of people who are needed. I hope it will be possible to publish simple abstract content without language specialists. It is great if language specialists will participate in Abstract Wikipedia. The biggest challenge for Abstract Wikipedia is the availability of enough data in Wikidata. At the moment many topics are not well sourced and there are only a few statements in the related Wikidata item. From my point of view it is necessary to check a text before publishing it. This is a task for a person who can speak the language the text will be published in. I prefer for simple abstract texts boilerplate templates for each language. It is necessary to get more people involved in Wikidata. If there is enough data then it can be converted into a text. It is from my point of view necessary to understand the data structures in Wikidata to generate a boilerplate template and the same is true for Abstract Content. Hogü-456 (talk) 19:46, 29 June 2025 (UTC)

I think that if we need to check a text created or updated by Abstract Wikipedia every time, then we loose a major advantage of the system. The goal is explicitly to be able to publish a text or an updated to a text without having to rely on that being reviewed by a human contributor.

I don't think that's different than, for example, the year articles that have been created by bots in many Wikipedias, or the city articles created by RamBot for English Wikipedia. They haven't been individually checked either before publication. Why do you think it would be necessary here? --DVrandecic (WMF) (talk) 13:18, 15 July 2025 (UTC)

I do not understand how to make sure the text can be fully translated into the other language out of the abstract content. As I understand there are language specific renders needed to be able to get it working. How do you want to make sure all the necessary renderers are availble. Especially when trying to write more advanced abstract text it can be difficult. If texts are structured in the same way then I agree with you that they havent been individually checked before publication. Hogü-456 (talk) 19:30, 15 July 2025 (UTC)

Yes, that's correct: language specific renderers will be needed (and lexemes as well). And only if they are available, the rendering will work. Their provision and maintenance will be the task of the language specialists. If they do not exist for a given language, no text will be rendered in that language. --DVrandecic (WMF) (talk) 10:39, 18 July 2025 (UTC)

This section was archived on a request by: Sannita (WMF) (talk) 10:36, 12 August 2025 (UTC)

WikiCon

Anfang Oktober findet in Potsdam die WikiCon statt. Derzeit können Programmvorschläge eingereicht werden. Ich fände es sehr schön, wenn wir dort etwas zu Wikifunctions und Abstract Wikipedia präsentieren könnten. @Hogü-456 and DVrandecic (WMF): hättet ihr Lust, hier mitzumachen? --Ameisenigel (talk) 19:05, 29 June 2025 (UTC)

Ich habe Lust mitzumachen um an der WikiCON zu Wikifunctions zu präsentieren. Hogü-456 (talk) 19:20, 29 June 2025 (UTC)

Hast Du was eingereicht? Kann ich Dich dabei unterstützen? --DVrandecic (WMF) (talk) 13:20, 15 July 2025 (UTC)

Ich habe einen Vorschlag zu dem Thema eingereicht. Meine Vorstellung ist, das ganze in zwei Teile aufzuteilen: Zuerst eine Präsentation mit grundlegenden Infos zu den Projekten und dann einen Teil für Fragen + Antworten. Wenn du dafür Material hast, wäre das natürlich hilfreich. --Ameisenigel (talk) 07:59, 16 July 2025 (UTC)

Prima! Ich habe Google Slides auf Deutsch vom WikiCon 2023 und 2021, sowie weitere Vorträge. Die sind natürlich veraltet, können aber vielleicht helfen. Soll ich Dir die Links per Email schicken? Falls Google Slides nicht passt, kann ich diese auch in etwas konvertieren, und Dir die Dateien schicken. --DVrandecic (WMF) (talk) 10:57, 18 July 2025 (UTC)

Gerne, Google Slides wären auch in Ordnung. --Ameisenigel (talk) 18:04, 19 July 2025 (UTC)

@Ameisenigel Let me know if we can be of any help with the proposal! Sannita (WMF) (talk) 08:52, 30 June 2025 (UTC)

This section was archived on a request by: ―Justin (koavf)❤T☮C☺M☯ 00:07, 14 August 2025 (UTC)

Indicating unknown day/month values in Day of Roman Year

In Day of Roman year (which is used by Gregorian calendar date), to my knowledge there is no designated way to record an unknown day or month. The AW team is currently writing built-in code that instantiates Gregorian date/time from Wikidata's "time" datatype, which frequently includes zeros to indicate unknown day/month. So far we are thinking to simply insert the Natural number 0 for Z20342K2 for an unknown day (and there were already comments that 0 values should be allowed on the type proposal page). For an unknown month, we are planning to insert Z24/void for Z20342K1. (Technically this is a bit of a cheat, but it will become fully legitimate once union types are supported.) The use of Z24/void in Z20342K1 might call for updates to functions that use Day of Roman year; haven't found time to check on this. Thoughts on these 2 choices? DMartin (WMF) (talk) 23:16, 11 June 2025 (UTC)

This is going to cause trouble no matter what we do! I didn't notice this in your Wikidata time Type proposal until now, so thanks for raising it here. The verdict on Wikifunctions:Type_proposals/Day_of_Roman_year was not to support 0 (certainly not as the month!?), so we have gone headlong without it. Only one/two of our DORY functions even have a well-defined output if an input is unknown (and one of those is casting back to Gregorian calendar month (Z16098)). These uncertainties only really make sense within an overall Wikidata time, so we may be able to use the precision to cleverly to ensure we never call a DORY function when its value is invalid/unknown. I'll think more carefully about this over the next few days, but wanted to express my caution quickly. P.S. are the new types you just dropped open for action? --99of9 (talk) 00:40, 12 June 2025 (UTC)

Thanks for mentioning. I didn't actually expect them to already be deployed this week. I think it's okay to start using them, but best not to rush ahead until after the built-in code that imports these types, from Wikidata content, gets deployed (which probably will be next week). It's possible final review and testing of this code might suggest another refinement or 2 in the types, but at present that doesn't seem too likely. DMartin (WMF) (talk) 06:12, 12 June 2025 (UTC)

Hi @99of9 and all, Any new thoughts about the issue of unknown day/month values? Most likely the new code that instantiates Day of Roman Year will be deployed tomorrow. So if someone creates a function that fetches Wikidata content and then calls existing functions for Day of Roman Year, those functions could break. So the deployment could be seen as encouragement for updating the relevant functions, assuming we are comfortable with the choices for representing unknown values (mentioned above). Another option would be to omit Wikidata statements that contain date/time with unknown month or day, for now, but there are many of these so that would be a loss. DMartin (WMF) (talk) 15:58, 17 June 2025 (UTC)

Go ahead with your plan. Many of the existing functions will need to return errors anyway, but I'll have a go at updating any that can sensibly be updated. This will be an interesting experiment with effectively optional parameters. I assume you saw @GrounderUK's caution somewhere else about void behaviour? --99of9 (talk) 00:45, 18 June 2025 (UTC)

Thanks. I saw a comment indicating that we should take care that the void value isn't interpreted as an error; is that what you are referring to?  That shouldn't be a problem.  That's not the "meaning" of the void value.  It is true, when the envelope comes back with void as the function call return, that happens when the function call encountered an error condition.  But that's just the use of void in that context, and void doesn't actually mean "error"; it just means nothing here; no value returned. DMartin (WMF) (talk) 04:30, 18 June 2025 (UTC)

Okay thanks, let's try it then! --99of9 (talk) 04:55, 18 June 2025 (UTC)

The built-in code that instantiates Gregorian date/time from Wikidata content has been deployed, and we see an expected error message for statements with unknown (void) month. Looks like an easy thing to fix; i'm going to go ahead and update Z22993 / date as English "Month day" string, as follows: If the month value is void, return the string "unknown"; else if the day value is 0, return just the English name of the month; else do what it currently does. (I don't expect to have time to fix other languages, but I'm eager to do a bit of this because I need more experience with read/display functions.) DMartin (WMF) (talk) 23:54, 20 June 2025 (UTC)

That's done now, but my updated implementation is still not working for month = void. Not sure why; need to investigate further. DMartin (WMF) (talk) 01:41, 21 June 2025 (UTC)

To me it seems to work. How should we handle a date with a known day but an unknown month?

And we should modify converters from and to code in order to handle also unknown dates. Dv103 (talk) 06:23, 21 June 2025 (UTC)

Yes, for me it also is working now; that is, I see "unknown" for the day part of Gregorian calendar date. (Note, however, for the record we are getting occasional "Something went wrong" messages from Natural number and Rational number display functions, as noted in the latest newsletter. I don't think that's a problem with their implementations though.)

Regarding known day but unknown month – thanks for mentioning. I've no idea if that ever occurs in Wikidata, but I think we might as well allow for it. How about if we make the English display function say "day n of an unknown month"? If there's no objection I'll make that change.

Yes, I agree we should modify the converters. Right now I'm planning to focus on the affected read/display functions, and then try to arrange for read/display functions for the new Wikidata-based types for time, quantity, and geo-coordinates. Other folks, please feel free to update the affected converter functions. DMartin (WMF) (talk) 00:45, 22 June 2025 (UTC)

Hmm, I notice there are about 24 functions that take Z20342/Day of Roman year as an input.  If we use void to indicate "unknown" for Z20342K1/month (the new behavior of Wikidata fetch functions; see above), all of those 24 functions' implementations should be updated, to do the right thing with the void value.  (There are also about 40 functions that take Gregorian month as an input; some of these might need updating to accept void, depending on how they are used.)

Is this number of updates acceptable?  If not, we could still consider this alternative:

• When an instance of Z20342 coming from Wikidata has an unknown month, just don't create that instance.  These instances are always inside Z6061/Wikidata datetime objects, so we could use void as the value of Z6061K1, to indicate "unknown" at that level.

I didn't realize the use of void in Z20342K1 would impact so many functions. Also, I thought it could be useful to have a convention for unknown month in Z20342.  Also, even with this alternative we would still get 0 in Z20342K2, to indicate an unknown day, and that could also call for changes to some of the 24 functions.  These things argued for going ahead on the current path, but now I'm somewhat less sure.

Note: With the above alternative, if Wikidata has any values with unknown month and known day of month, those values would get discarded - but that seems unlikely.  

@Dv103, @DVrandecic (WMF), @99of9, and all, any preferences here?  Continue to use void for Z20342K1, or adopt the above alternative? DMartin (WMF) (talk) 06:31, 22 June 2025 (UTC)

Another option is to create a simple new type called, say, Wikidata calendar date (probably just 3 natural numbers for year/month/day, with zero indicating unknown), which would be instantiated by the Wikidata fetch functions, and provide a conversion function from Wikidata calendar date to Gregorian calendar date, which could be used as desired by function writers. The conversion function would not handle "unknown" values for month or day; it would only be called when month and day have valid values. Advantage: nothing related to Gregorian calendar date or Day of Roman year would have to be updated. Disadvantage: To use content of Wikidata calendar date we'd have to create a new set of functions that handle it (but which in happy cases could take advantage of conversion to Gregorian calendar date). I think this mostly depends on whether the creators of Day of Roman year like the idea of supporting a convention for unknown month/day values. DMartin (WMF) (talk) 20:39, 22 June 2025 (UTC)

Personally, I prefer the first option (to introduce optional parameters directly into Day of Roman year (Z20342)).

The second option seems highly inconsistent (with optional days but without optional months).

The third option would create a new type with near-identical semantics to an existing type, which I think is against the current phylosophy behind Wikifunctions types.

The first option, while requiring an update to many existing functions, wouldn't create too much destruction - all the functions would continue to work with completely known dates, and it shouldn't be too difficult to systematically change the existing functions to make them able to handle also unknown dates.

That said, I would like to see what others think about this problem.

Final note: If the first option is chosen, I think the best way to update the converters to code would be to encode both unknown days and unknown months as undefined in JS and as None in Python. In particular, in JS this would make it possible to exploit the ?? operator. Dv103 (talk) 21:02, 22 June 2025 (UTC)

Thanks! I generally also lean towards the first option, so long as folks are on board with updating the affected functions. And yes, I'd also like for others to have a chance to comment on this. Regarding unknown month, another way to support that would be to add an "unknown" value to Gregorian calendar month. (Just mentioning; not arguing for). DMartin (WMF) (talk) 15:40, 23 June 2025 (UTC)

For interested subscribers, further discussion is at:

• #Indicating unknown day/month values in Day of Roman Year
• #New Z20342 converters

--GrounderUK (talk) 19:27, 17 July 2025 (UTC)