Wikifunctions:Project chat/Archive/2025/07

Proposed Python conversion functions for Wikidata geo-coordinate

I've prepared the following Python conversion functions for Wikidata geo-coordinate:

• Convert from Wikidata geo-coordinate, Python (Z26186)
• Convert to Wikidata geo-coordinate, Python (Z26187)

Feedback is welcome! One note: because the built-in Fetch functions code allows for missing precision and globe values in the geo-coordinate JSON from Wikidata (in which case it inserts Z24/void in Z6011K3 or Z6011K4, respectively), Convert from Wikidata geo-coordinate, Python (Z26186) therefore checks for those possible void values. If there's a void value, it's converted into Python None. Accordingly, Convert to Wikidata geo-coordinate, Python (Z26187) checks for those possible None values. However, I don't know for certain whether we will ever have missing values for precision or globe. The Wikidata documentation sources are a bit vague on this point. In at least one place, the documentation seems to imply they could be missing, so we are allowing for that possibility.

 Support Thanks. I think the structure is what we're expecting. I'm happy for these all to be enabled so we can test them out. --99of9 (talk) 06:33, 13 July 2025 (UTC)

Okay, I've enabled them. Thanks for looking/commenting! DMartin (WMF) (talk) 06:36, 15 July 2025 (UTC)

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

Issue with Wikidata time precision, Wikidata calendar model, and (some calls to) Fetch Wikidata item

Currently there is a problem with processing instances of the new types Wikidata time precision, Wikidata calendar model, and Wikidata time. A couple examples:

• If you call Fetch Wikidata item on Q2028564, or any item that contains a value of datatype time, the result will be the error message Could not complete request due to server error.
• If you call same same Wikidata enum instance to compare any 2 instances of Wikidata time precision or Wikidata calendar model, you will see the same error.

This problem is occurring because the definitions of Wikidata time precision and Wikidata calendar model contain mistakes. It affects Wikidata time because instances of Wikidata time contain instances of Wikidata time precision and Wikidata calendar model. The problem will stop occurring as soon as updated definitions are deployed; we are working on getting that done ASAP.

Apologies for any inconvenience! — Preceding unsigned comment added by DMartin (WMF) (talk • contribs) 04:03, 28 June 2025 (UTC)

Update: unfortunately, because of some challenges with deployment schedules, this problem is still occurring. The fix will be deployed on Wednesday, July 9 at the latest, possibly a bit sooner. DMartin (WMF) (talk) 00:32, 5 July 2025 (UTC)

Okay, this issue has now been fixed on Wikifunctions.org. DMartin (WMF) (talk) 17:33, 8 July 2025 (UTC)

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

Equality function for Z6011

@DMartin (WMF) Please can you set same Wikidata geo-coordinate (Z25932) as the equality function for Wikidata geo-coordinate (Z6011)? --99of9 (talk) 05:13, 4 July 2025 (UTC)

Okay, I've just done that. Thank you! (Speaking of Z6011, I've written JavaScript converter functions for it. After testing, I will share them on this page, and then do the python converter functions.) DMartin (WMF) (talk) 00:28, 5 July 2025 (UTC)

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

Wikifunctions & Abstract Wikipedia Newsletter #209 is out: Coverage of 1298

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 how Wikipedias cover articles about years, 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 July 7, at 17:30 UTC (link to the meeting).

Enjoy the reading! -- User:Sannita (WMF) (talk) 14:39, 4 July 2025 (UTC)

Thx @Sannita (WMF), Just a small reminder, The "status updates" section on the main page needs to be updated. Thanks for your help with that --Mohanad (talk) 20:26, 8 July 2025 (UTC)

I will do so in the next hours, thanks for the reminder! Sannita (WMF) (talk) 11:55, 9 July 2025 (UTC)

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

Assistance creating a function

Hi there!

I just joined! I've just watched the video about Wikifunctions in 7 minutes and I would like to try to create a function to transform a given link into a different one.

When I went to Special:CreateObject and checked the types of inputs / outputs I didn't see anything like a "Link" type. This type would be useful to have for both hyperlinks and wikilinks -including interwiki links- inputs / outputs.

Thanks in advance! It's moon (talk) 14:27, 7 July 2025 (UTC)

You would use String (Z6). There's WF:Type proposals/Typed string for adding type aliases/refinement types. YoshiRulz (talk) 02:01, 8 July 2025 (UTC)

Filter recent changes by new tagged edits

Just a suggestion: I'm thinking of filtering edits and creations based on the most frequently used objects types, such as functions, implementations, test cases, etc. I mean creating "new tags" that label contributions based on the object type that was created or modified. This would make it easier to spot vandalism later on, especially as the community grows and impactful changes get harder to find, specifically for functions and implementations. Best regards. --Mohanad (talk) 18:46, 10 July 2025 (UTC)

@Mohanad: Do you mean that the software should tag edits based on the Type of the page being edited? Normally edit tags are meant to be about the nature of the edit, but this could potentially work (though the limits on edit tag scalability means we'd have to chose carefully what tag). Jdforrester (WMF) (talk) 19:19, 10 July 2025 (UTC)

@Jdforrester (WMF) If it were possible for a limited number of types at least, that might be sufficient --Mohanad (talk) 20:10, 10 July 2025 (UTC)

@Mohanad: Sure! I've created T399244: Tag edits to Objects to explain what kind of Object they are (Function, Implementation, etc.) so they can be filtered for this, and it will get assessed as part of our task intake process. Jdforrester (WMF) (talk) 21:00, 10 July 2025 (UTC)

Thx @Jdforrester (WMF), I hope it's practical. If not, maybe it'll spark other ideas, like using JavaScript tools to highlight changes, perhaps with specific colors, or something else entirely --Mohanad (talk) 21:29, 10 July 2025 (UTC)

Reading and diplay functions for Z20159

@DMartin (WMF) I propose to use read Gregorian year (Z22910) and display Gregorian year (Z20241) as the reading and display functions for Gregorian year (Z20159) respectively. Both functions are coustomizable by language. read Gregorian year (Z22910) is heavily inspired to read Gregorian Calendar Date (Z20808), using almost the same code.

Currently, display Gregorian year (Z20241) supports only English and Italian, while read Gregorian year (Z22910) supports English, Italian and Dagbani, so more localisations are welcome (in particular, I have written a guide to help localising the reading functions).

Thanks to @Feeglgeef and @99of9 for their contributions to both functions. Dv103 (talk) 08:56, 7 July 2025 (UTC)

Thank you, @Dv103 (and @Feeglgeef and @99of9)! I've just added these functions to the type definition. Sorry it took so long; for some reason I didn't notice this chat previously. DMartin (WMF) (talk) 20:08, 21 July 2025 (UTC)

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

Wikifunctions & Abstract Wikipedia Newsletter #210 is out: Length limits on labels and descriptions

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

In this issue, we introduce a measure to limit length of labels and descriptions, we show a video illustrating our work on front-end components, we share some news on new Types, 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 July 15, at 16:00 UTC (link to the meeting).

Enjoy the reading! -- User:Sannita (WMF) (talk) 09:46, 11 July 2025 (UTC)

I think the length limits on labels needs to be higher. I tried to shorten some and it seems sometimes possible and in other cases it is very difficult. I think the Limit for Testcases can be higher. Hogü-456 (talk) 19:56, 15 July 2025 (UTC)

Maybe it is possible to write the longer form into an Alias. Then it is still possible to find it when someone is searching and the main function name can be shortened. What is the character limit of Alias. Hogü-456 (talk) 20:06, 15 July 2025 (UTC)

Yes. We generally copy the existing label to an alias when re-labelling, especially if the original label is not our own. In cases where the “natural” label is too long and has needed a shorter form, I have also added the longer form as an alias. For example, “preferred representation from lexeme forms ranked by feature alignment” is an alias for lexeme form representations (first in ranked form) (Z24483): returns the first representation (given expressed preferences) from each of the lexeme’s forms, ordered by the form’s alignment with the requested grammatical features. I’m not aware of a limit applying to aliases. GrounderUK (talk) 09:10, 16 July 2025 (UTC)

Unless the other option satisfies you, what do you think a good length limit would be? --DVrandecic (WMF) (talk) 10:51, 18 July 2025 (UTC)

I think a limit of 70 characters would be a good length limit. It would be enough for more than 80 percent of the listed Z-Objects. This is based on an analysis based on the data from Wikifunctions:Long labels and descriptions. In this Spreadsheet I published in Wikimedia PAWS in my folder there is a list of Z-Objects by number of characters. Hogü-456 (talk) 19:54, 19 July 2025 (UTC)

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

proposed Read function for Wikidata geo-location

I suggest we use the following function as a read function for the Z6011 Type:

• read Wikidata geo-coordinate (Z26344)

At the moment it's just a shell for default reader of Wikidata geo-coordinate (Z25930) which now covers quite a few standard formats. Feel free to add more tests if you want another format covered. I haven't finished getting it to read natural language labels of other globes (e.g. "-34, 151 (Mars)" in English (Z25945)), but I have a plan for it, and at the moment you can use the QID (e.g. "-34, 151 (Q111)" in mul (Z26348)). --99of9 (talk) 01:21, 19 July 2025 (UTC)

Update: I've now completed and integrated QID from globe name (Z26214), so now I think that any output from the renderer (e.g. globe names in any language) should work as input for the reader. --99of9 (talk) 07:40, 21 July 2025 (UTC)

Thank you for all your excellent work on this! I’m trying to envisage a built-in label to Wikidata identifiers (list) function, but I think wrapping SPARQL query results as a dictionary is a good option for now (although it’s effectively a frozen cache). Did you define the list of globes or extract it from those actually in use? GrounderUK (talk) 10:20, 21 July 2025 (UTC)

The globe values at the top of the first query are also drawn from a query (https://w.wiki/EoR7). It's in a comment at the top of the first query. --99of9 (talk) 02:10, 22 July 2025 (UTC)

Ah, yes… Sorry, the query itself doesn’t appear to be accessible while my phone is in portrait mode. I see the comment now. GrounderUK (talk) 05:13, 23 July 2025 (UTC)

Okay, I've connected read Wikidata geo-coordinate (Z26344) as the read function. Thank you! I noticed the (disconnected) python implementation has mostly failing tests. Was there any particular reason noticed for those failures, or is this implementation just unfinished? DMartin (WMF) (talk) 03:41, 22 July 2025 (UTC)

Thanks. I made the python one when I was trying to figure out how to return a Wikidata geo-coordinate from code. I'm open to deleting it, but the one thing it can do is return the right format. So if anyone wants to implement something in Python, it's a starting point. It should certainly remain disconnected. --99of9 (talk) 04:01, 22 July 2025 (UTC)

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

Wikifunctions & Abstract Wikipedia Newsletter #211 is out: Wikidata-based enumerations are here

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

In this issue, we introduce a new kind of Type (Wikidata-based enumerations), we remind you of our current sprint in fixing labels and descriptions that are too long, 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:16, 19 July 2025 (UTC)

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

Wikifunctions & Abstract Wikipedia Newsletter #212 is out: “Wikipedia is an encyclopedia”; Two years of Wikifunctions

There is the second anniversary update for Abstract Wikipedia and Wikifunctions. Please, come and read it!

In this issue, we introduce our work on functions that generate sentences and fragments in several languages, we celebrate our second anniversary, 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) 16:33, 26 July 2025 (UTC)

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

Inflation calculator

There is an inflation calculator at Wikipedia and we need it at Wikisource and Commons. If an historical news article says that someone was payed $500 in 1880, we need to be able to show what that value is equal to in the current year. I tried to migrate the template over, but it was too complex with over a dozen subroutines. Can we have a universal version that can be used by every project? Richard Arthur Norton (1958- ) (talk) 15:54, 5 July 2025 (UTC)

(w:Template:Inflation)

I think that would have the same problem as the currency conversion functions proposed here, namely that it's not just arithmetic, you'd also need to pull from historical data. You could probably have a function which takes in that data as a parameter and maybe that would have some merit, as opposed to a currency conversion which is just multiplication. YoshiRulz (talk) 18:36, 5 July 2025 (UTC)

Or we could store the data in a persistent object, or directly in Wikidata (but I don't think there is a property to encode inflation levels yet). Dv103 (talk) 12:35, 6 July 2025 (UTC)

I tried to create one as a test: Z25970 (it’s my first time here). I don’t think it is the proper way to do it but I converted the inflation data to a very long if-statement in Z25966. Tvpuppy (talk) 21:57, 6 July 2025 (UTC)

Actually it's not such a bad idea (considering the current lack of support of the map type). I converted your functions to work with Rational number (Z19677) instead of float64 (Z20838), since it completely removes rounding errors (and here on Wikifunctions Rational number (Z19677) is becoming the standard type for representing real numbers, since it can represent way more values than float64 (Z20838)).

And I converted the years in the type Gregorian year (Z20159), since it is the type with the right semantics.

I think we could procede to implement a copy of w:Template:Inflation. (An advice: while we need a version of US CPI for year (Z25966) for each currency, we don't need a version of USD inflation calculator (Z25970) for each currency, since it is possible to create a more general version of it that also takes the currency in input) Dv103 (talk) 22:39, 6 July 2025 (UTC)

Thank you very much for the help! I agree the changes you made is more suitable for the function. Tvpuppy (talk) 22:51, 6 July 2025 (UTC)

I've created the function at Z26424. For now it only supports US, UK and EU, but it should be easy to add other currencies (just time-consuming). For now it returns the amount as a rational number (not rounded to the nearest valid currency value). Dv103 (talk) 16:37, 21 July 2025 (UTC)

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

Concerning user signalation: request for people who know Igbo

I just noticed the existence of User:Obedmakolo, that seems that in the past was active mainly in the translation of labels in Igbo and a couple of other languages. What concerns me is the fact that his translations in the function Z12448 were weird: they were not complete, and even the suffix "-is" was translated (which makes no sense, since the function literally adds the suffix to the word). My suspect is that his translations were done with an automatic translator and without supervision. Since I don't know Igbo, could someone that actually knows it check whether his other translations make sense? Dv103 (talk) 16:32, 14 July 2025 (UTC)

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

New Z20342 converters

@DMartin (WMF) I tried to modify the current converters of Z20342 to include also unknown months and days; here are the modified converters:

• Convert from Day of Roman Year, js, with null (Z26298)
• Convert to Day of Roman Year, js, with null (Z26299)
• Convert from Day of Roman calendar to Py with None (Z26300)
• Convert to Day of Roman Year, Python, with None (Z26301)

This is the first time I write type converters, so please check if they are right.

They should all behave like the old converters, except that they can handle also unknown months and days. Both unknown months and days are converted to null or None. Dv103 (talk) 09:42, 15 July 2025 (UTC)

Hi @Dv103, Thanks for getting this done! Your code changes look fine to me. I noticed your comment "loose or strict comparison?" regarding using == or === with null, in JavaScript. I believe === to be preferable. Also, I just checked our orchestrator code base and comparisons to null are always ===. I will hold off on connecting these converters in case you want to change that; also if anyone else wants to take a look. DMartin (WMF) (talk) 04:45, 17 July 2025 (UTC)

Thank you for your insight, but for now it's better to wait connecting them, given the ongoing discussion above. Dv103 (talk) 06:12, 17 July 2025 (UTC)

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

Guide for creation of Time of day readers

Similarly to Gregorian calendar day, I've created a guide for the creation of localisations of Z25118. While the language independent reader, originally written by @99of9, is already able to handle a variety of the most internationally used formats, it is not able to handle some tricky local formats, like the Chinese and the Japanese ones.

As always, don't hesitate to ask me if you have any problem. Dv103 (talk) 12:02, 21 July 2025 (UTC)

Wonderful work. Thank you. -99of9 (talk) 22:42, 21 July 2025 (UTC)

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

Function equality function

@DMartin (WMF) Is there a tecnical reason why Z14562 is not the Function equality function? Dv103 (talk) 21:53, 21 July 2025 (UTC)

Not to my knowledge. The main thing that comes to mind is that, ideally, we might want the designated equality function to be more forgiving of differences in representation, and focus on the essential defining characteristics of the 2 functions. But I don't know of any well-established rules about this. I will go ahead and connect it. Still open for discussion here though. DMartin (WMF) (talk) 21:48, 23 July 2025 (UTC)

Seems sensible to me. As far as I know that's the only function equality attempt we have so far. --99of9 (talk) 12:15, 24 July 2025 (UTC)

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

Floating point special value equality function

@DMartin (WMF) Could you please set Z21439 as the Floating point special value equality function? Dv103 (talk) 21:58, 21 July 2025 (UTC)

Agreed. Thanks for catching this, I'm not sure why I forgot to ask at the time. --99of9 (talk) 02:18, 23 July 2025 (UTC)

Okay, that's done. Thank you! DMartin (WMF) (talk) 05:58, 23 July 2025 (UTC)

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

FYI: hiding messages in playing cards

https://asherfalcon.com/blog/posts/3 ―Justin (koavf)❤T☮C☺M☯ 00:55, 22 July 2025 (UTC)

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

Wikifunctions presentation & tutorial at Wikimania: will you be there?

Hi all! You are all invited to our presentation+workshop at Wikimania, that will be in the Mombasa Room, on Friday August 8, at 14:00 local time (see your timezone).

Following the introduction from James, there will be a workshop, so if you are at Wikimania and want to help us doing it, let us know!

More info about streaming will follow in due time. See you there or online! Sannita (WMF) (talk) 13:31, 24 July 2025 (UTC)

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

proposed Display functions for Gregorian era

I suggest we use the following functions as a display function for the Gregorian era (Z17813) Type:

• display Gregorian era (Z24761)

This will allow embedded functions which return Gregorian era types.

It calls for labels from Wikidata in the required language or from fallback languages. If it's not working for your language, either add a Wikidata label, or add your langauges fallback sequence at hardcoded language fallback codes, python (Z24309). --99of9 (talk) 02:11, 23 July 2025 (UTC)

In Italian there is the weird situation on Wikidata that Post Christum Natum (Q3714072) and Anno Domini (Q159791) are two different items. AD in Italian is usually said as "dopo Cristo", that is the label of Post Christum Natum (Q3714072); the current output of display Gregorian era (Z24761) is now incorrect. Dv103 (talk) 06:17, 23 July 2025 (UTC)

I think the issue is that the Italian description (and maybe therefore the label) of Anno Domini (Q159791) "Latin expression" is not defining the same object as the English description "Western calendar era". If the description was changed to match the English, then it sounds like the natural label would change to "dopo Cristo"? --99of9 (talk) 06:32, 23 July 2025 (UTC)

Then on Post Christum Natum (Q3714072) it seems that every language description agrees that this is a Latin phrase/expression. In which case we probably don't need to translate it much and can set its label in all languages to remain true to the original "Post Christum Natum"? --99of9 (talk) 06:36, 23 July 2025 (UTC)

The matter is complicated by the fact that Anno Domini (Q159791) is connected with the Italian Wikipedia article w:it:Anno Domini, while Post Christum Natum (Q3714072) is connected with the Italian Wikipedia page w:it:Dopo Cristo. Both pages are about both the expression and the concept. Dv103 (talk) 06:42, 23 July 2025 (UTC)

Yes, that's harder to switch. I still don't see how we would solve this at the Wikifunctions end though, unless we have a special configuration function just for Italian! --99of9 (talk) 07:23, 23 July 2025 (UTC)

Now I've asked on Wikidata, hoping to have an insight there. Dv103 (talk) 07:38, 23 July 2025 (UTC)

Other languages may prefer Common Era (Q208141) (or, of course, anything else). GrounderUK (talk) 07:52, 23 July 2025 (UTC)

(And before common era (Q13432996), of course.) GrounderUK (talk) 07:57, 23 July 2025 (UTC)

Output Type for Sentence and Fragment Generation Functions

Hello. I had a look at the sentence and fragment generation functions of Wikifunctions:Abstract Wikipedia/2025 fragment experiments and was concerned about the output types. subject is instance of (string) (Z26039) uses String (Z6) as the output type, whilst subject is kind of (Monolingual text) (Z26095) outputs Monolingual text (Z11), despite depending on a String (Z6) outputting function, subject is a kind of, English sentence (Z23410) (the only language supported as of this message); the differing types cause a Return type mismatch (Z517) with the test, a snake is a reptile (Z26628). Shouldn't sentence and fragment generation functions only output Monolingual text (Z11)? Thanks, Red Sneak (talk) 21:09, 29 July 2025 (UTC)

@Red Sneak: Yes, we're moving over to Z11 outputs but it needs some server-side code that I need to get around to writing. Jdforrester (WMF) (talk) 14:15, 30 July 2025 (UTC)

Are you referring to Z861 that popped up today? Why does this need to be built-in? We already have Z26107 and it's easy enough to reverse the arguments. --99of9 (talk) 00:40, 7 August 2025 (UTC)

Using Days of Roman year with unknown month

I tried to implement the function month of Day of Roman year unknown (Z26166), but the simple implementation month of Day of Roman year unknown, composition (Z26171) doesn't work, suggesting that void (Z24) is treated like an error somewhere. Considering that we should start handling dates with unknown values, I hope that it is possible to solve this issue.

It is also necessary now to update the converters of Day of Roman year (Z20342) in order to handle unknown values. Dv103 (talk) 21:10, 10 July 2025 (UTC)

It looks like two of the test cases are faulty. I have disconnected those and added </nowiki>Z26189, which passes. It looks like it was a caching issue. All tests are passing so I have re-connected the implementation. GrounderUK (talk) 09:36, 12 July 2025 (UTC)

I’m not sure about updating the converters for Z20342 but I don’t have an alternative proposal. Before we do so, we should agree what to do about implementations that do not handle such dates. For example, should Z16137 return Z41 if both months are Z24 (the objects are the same but whether the “unknown” values represent different months is “unknowable”). GrounderUK (talk) 13:04, 12 July 2025 (UTC)

Why are you not sure about updating the converters? Are there downsides I am not aware of?

By the way, Z16098's converters should be updated too.

As of the already existing functions, we should go through them and decide for each one. As of Z16137, for example, I think two unknown months should be treated as the same (mostly for practical reasons, since it is the comparing function for Z16098). Dv103 (talk) 13:15, 12 July 2025 (UTC)

I wouldn’t change the converters at this stage because they support the underlying types as they were originally defined. As far as I know, changing the existing type definitions has not been proposed. We should consider the advantages and disadvantages of such a change when it is proposed. GrounderUK (talk) 10:39, 13 July 2025 (UTC)

Z6821 already returns dates with undefined values (try for example with World's Peace Jubilee and International Musical Festival (Q3769110)), and this has been discussed in the section "Indicating unknown day/month values in Day of Roman Year" of this page, so I would say that the introduction of unknown months and days are now official.

My idea was to modify the converters in order to pass null and None when there is an unknown value (mantaining the current behaviour in all the other cases). Dv103 (talk) 11:04, 13 July 2025 (UTC)

To my mind, there is a clear distinction between allowing voids in the Wikidata objects and allowing them in the underlying types. I’m afraid I missed the way the discussion drifted towards an assumption that the underlying types would also change, but I maintain that this is still only an assumption until there is a formal proposal to change them. The change you propose for the converters seems reasonable in itself, but I am very uncomfortable with the idea that we might expect all date functions (present and future) to handle an unspecified month.@DMartin (WMF) GrounderUK (talk) 13:18, 13 July 2025 (UTC)

Yes, I'm still concerned that most DORY functions don't have a well-defined output when the input has an unknown value in it. Take Day of Roman Year to Day number in year Z20357 as an example. Unless we end up propagating the uncertainty and (not desirable or possible yet) returning e.g. "unknown natural number", then those functions should return an error (which they currently would). So therefore we just leave them as they are? Then we can wrap compositions operating on Wikidata datetimes to only call those functions when the DORY within a Wikidata datetime Z6061 was certain (or ?equivalently, had a precision <= day). I imagine it won't harm us to have code converters that can deal with voids/nulls, so I personally don't want to block it, but I do expect troubles ahead no matter what we do. --99of9 (talk) 13:51, 14 July 2025 (UTC)

The link to precision is an interesting one. It sort of implies that era+year and era+year+month are valid, whereas era+year+[unknown month]+day might not be (its semantics happen to be problematical). What would the precision be for a yearless date? A yearless and dayless date is presumably just a Z16098, but what about a day (>0) with neither year nor date?

I’ve added a comment to Wikifunctions:Type proposals/Julian calendar date, suggesting a less narrowly defined type (essentially a supertype, with the option of also representing more or less precise Gregorian calendar dates. A further refinement to that could be to include a key for Z6062. -- GrounderUK (talk) 18:50, 17 July 2025 (UTC)

Thanks all for restarting this discussion. We've arrived at these challenges because of the decision to use DORY for import of dates from Wikidata, which in various discussions has seemed desirable and well justified, compared to creating a new date type for that purpose.

To my mind, that decision already implies the redefinition of DORY functions, including read/display/convert, to handle unknown month and day, because Wikidata fetches are creating DORY instances with the new unknown-value conventions, and function-writers are naturally going to use those instances with various functions that handle DORY.

I'm thinking we can satisfactorily figure out the problematic cases (like those above) on a case-by-case basis. Some of those cases probably should return errors, as mentioned above; I wonder if it would make sense to change some to return Kleenean values (e.g., Z16137).

Having said all that, I'm open to all other ideas and even revisiting previous decisions if needed. DMartin (WMF) (talk) 03:51, 15 July 2025 (UTC)

Following your suggestion, I've created kleenean compare months (Z26280) and kleenean compare days of Roman year (Z26271) (I think same month (Z16137) and same Day of Roman Year (Z20348) should not be changed, since they are the default comparing functions). Dv103 (talk) 08:15, 15 July 2025 (UTC)

Thanks for the reply @DMartin (WMF). I don’t think we need to revisit the decision to use DORY within the date object in Z6061K1 (although I am open to revisiting that if the impact on pre-existing types turns out to be significant).

I fundamentally disagree with your second paragraph. In most cases, the Z6061K1 will be a valid object of type: Gregorian calendar date, and in such cases it is perfectly reasonable to use the display functions for that type. We might also reasonably assume that the same display functions could be used for a prospective Julian calendar date type. The special case of unknowns might also be handled by the same functions, but that is not necessarily the best option. If we intend to create a new type for values like “July 2025”, then we might create that type’s display functions in advance, but these would all need to be re-defined once the new type became available.

When it comes to what function-writers are naturally going to do, I can’t be sure, of course! In the case where the Wikidata object contains a valid Gregorian calendar date or Day of Roman year, we shouldn’t expect any difficulties. Whether we’d convert a Julian date to Gregorian would, I guess, depend. But even allowing for a yearless Gregorian date would already imply dispatching by type, and allowing for monthless dates is no different, conceptually. When we come to consider more formal union types, we’ll need to consider something like Wikifunctions:Type proposals/configuration of functions for given types, but perhaps this can be generalised for use in conjunction with lightweight enumerations. In any event, wrapping existing functions with conditions is the default option, and if a new function is to be defined, it can reasonably accept the whole Z6061 (which might imply a need to define converters for that type).

I don’t believe that Z6061 requires a read function, so I don’t currently see any need to change any of the read functions for existing types, at this time. I am not implacably opposed to changing the DORY converters, but I believe that is inconsistent with a “case-by-case basis” and I am still struggling to see the advantages. I am inclined to defer changing the converters from code, in particular, since that would tend to propagate the unknowns into the Gregorian calendar date space, where there are around seventy functions to consider.

I’m happy to help out where I can, but let’s take this step by step and begin by agreeing where we’re headed. GrounderUK (talk) 11:50, 15 July 2025 (UTC)

I'm not shure I've understand well, but are you proposing to create different types for fully-defined Gregorian dates and partially-defined Gregorian dates? If this is the case, I'm not actually convinced with this proposal, since it would create a zoology of types with nearly identical semantics, and the need to duplicate many functions to do very similar operations with these two types.

As of your last paragraph, the main advantage of completely support unknown values it the current DORY would be the possibility to use all the normal DORY-related functions also with dates that come from Wikidata where reasonable. For functions that don't make sense to define with unknown values, instead, I see nothing wrong in raising an error for certain inputs (like for example the division functions that are not well-defined when the second parameter is equal to 0).

As of the number of current functions that whould need an update, currently there are 31 functions that require a DORY input: of those, at least 4 don't need to be updated and 11 are display functions, so only 16 functions need to be updated (considering that we must create some way to display partially-defined dated, no matter what). Considering that updating a function usually is not very time-consuming (it usually just requires to add an initial check), and considering that some functions don't need to be updated because unknown inputs just don't make any sense, this task should quite doable.

For Gregorian calendar dates, instead, there are 57 functions with Z20420 in input, 18 of which are display functions. Here we would still need to do a bit more work, but it is not too much yet (as always, a non-neglegible fraction of those function don't need to be updated because they already don't make sense with unknown inputs). Also consider that, with the creation of new types, considering that the functions that need to be updated to quite reasonable operations that people would expect to do also to partially unknown dates (for example: "add 1 year" is reasonable to do even if the month is unknown), these functions would instead need to be duplicated (and the creation of a new function requires a lot more work rather than just updating the existing ones). Also consider that creating new tipes, also functions that will be created in the future will need to be duplicated. Dv103 (talk) 13:23, 15 July 2025 (UTC)

Thank you for your reply, most of which I agree with. To be clear, I am not making a specific proposal. All I am saying is that “non-standard” dates could be restricted to Wikidata objects for the time being. We already have a proposal for Julian calendar date, and we need to decide how to proceed with that. But beyond displaying something sensible, I’m not seeing handling “non-standard” Wikidata dates as a high priority. Do we know what proportion of Wikidata dates are “non-standard”? GrounderUK (talk) 17:36, 15 July 2025 (UTC)

@Dv103 thanks for explaining your reasoning, I changed my mind based on your arguments. --DVrandecic (WMF) (talk) 11:09, 18 July 2025 (UTC)

Thanks, @GrounderUK. I take your points, and I agree that we should take this step by step and begin by agreeing where we’re headed.

I'm not aware of any estimates for what proportion of Wikidata dates contain unknown values. I get the impression it's fairly common, based on anecdotal observations. I have JSON files for 6 fairly typical entities on my machine and they contain 7 such instances: 4 with month & day unknown and 3 with day unknown, out of 87 instances of the time datatype. (These unknowns are in Hickory, NC and Douglas Adams.) In Wikidata documentation, the use of unknown values is included as a legitimate option. DMartin (WMF) (talk) 02:57, 16 July 2025 (UTC)

Thanks. I’m thinking of a function that casts the Z6061K1 to a valid object of the correct type, so if we just have the year, this would return a Z20159 or, if only the year is missing, a Z20342. I don’t know what it should do if only the month is unknown, but my instinct is to return the input object (a Z6061). Because validation against zero is not in place for existing days, I’m inclined to cast to the type that would be appropriate if the day were not zero, in a parallel function or controlled by a Boolean flag. Thoughts, anyone? GrounderUK (talk) 11:02, 16 July 2025 (UTC)

Thanks! We can also consider having this expanded use of Z6061K1 (to hold an instance of Z20159 or Z20342 sometimes) implemented by the fetch function code (built in code that could be easily updated in this way), and thus avoid the need for defining and using an explicit casting function.

I need to ask for clarification of your sentence beginning with "Because". Are you saying that for unknown days, we'd cast to Z20342 and allow Z20342K2/day to be 0 for unknown days (which is already the current direction)? If so, I don't understand the need for a parallel function or Boolean flag. I'm missing something; could you please clarify? DMartin (WMF) (talk) 20:12, 16 July 2025 (UTC)

Basically, it depends! The context either requires a known value for the day or it does not, and this would be indicated by setting the flag or calling the alternate function (as the case may be). For example, calling Z25907 requires a known day whereas calling Z25901 does not. (Z20367 is an example that produces a semantically incorrect result for a day equal to 0, if that value represents “unknown”.)

We could certainly consider implementing some of this logic in the fetch function code, but I don’t see that being able to handle the cases of unknown months or days, when this may or may not matter (depending on the context). In practice, it would mean we would generally have to interrogate the type, so I’d be inclined to defer any such change until we are introducing support for Julian dates. On that subject, my current thinking is that we might avoid a strict Julian calendar date type and also support, for example, Old Style dates and the en:Swedish calendar (with its infamous 30th February, 1712) with the same type. It’s only a small step from there to a more general type that also supports Gregorian calendar dates (as a subtype). GrounderUK (talk) 22:55, 16 July 2025 (UTC)

@DMartin (WMF) From test case Z26404, it appears that Z6064K5(“timezone”) can be set to Z16660 zero by Z6821, but this is not a valid value in the Z16683 type, where zero must be Z16661. I don’t think it’s causing any immediate problems but test case result validation will naturally read 0 as neutral, and the discrepancy is hard to spot. GrounderUK (talk) 19:02, 20 July 2025 (UTC)

Thanks! I will get this fixed and then report back here when the fix has been deployed. DMartin (WMF) (talk) 01:15, 21 July 2025 (UTC)

Just following up – this was deployed, about 5 days ago, and I have confirmed it's working. DMartin (WMF) (talk) 04:58, 11 August 2025 (UTC)

Read and display functions for Natural language (Z60)

language to language tag (Z14329) and language tag to language (Z860) might be set as the read and display functions for Natural language (Z60). I think this would make a fairly large number of functions available as embedded functions (including all the read and display functions for supported types). There are around a hundred functions with Z60 in their inputs but I reckon around half of these would remain unavailable if we decide to make this change (based on this search) GrounderUK (talk) 08:49, 24 July 2025 (UTC)

Interesting idea to just use the codes. Actual read and display functions need two arguments, so we'd need to wrap those functions, but they could indeed be reasonable defaults. I'm not sure what your search query is trying to show (many of those functions seem to have other argument types that are also readable and output types that are displayable). --99of9 (talk) 12:14, 24 July 2025 (UTC)

I’m not sure we’d need to wrap display functions for the types supported as inputs to embedded functions. The search is just what was left after I excluded various types that are not supported, so it should include all the functions that might be supported by enabling read and display functions for Z60 (so none of them should currently be available to embed). I reached the maximum size for the search terms, so I couldn’t exclude any more types. GrounderUK (talk) 14:25, 24 July 2025 (UTC)

Thanks for the suggestion! We have recently discussed adding Natural language (Z60) support to embedded function calls (only as inputs). As we've indeed seen that it would enable lots of new functions for embedding, we've added it to the scope for this quarter. Our intention is to add support by having a Natural languages lookup field that would allow editors to search through available Z60 objects by their labels and select one. The selected language would be inserted as a Zid, for example {{#function:Z23468|Q144|Z1003}}. We could very well add a read function to the type as well, but then we'd have to deal with double support of language codes and zids, which needs additional engineering work and might be prone to validation errors and confusion. We are tracking this work in phab:T400165 and I've included this suggestion as a possible solution. If there are strong reasons to also link a read function to the type, please follow-up in the task so that we can work out how to enable this double support. In such case, we should decide on a different function to be used as a read function, as read functions require a second argument (language) and Z860 doesn't have one. Otherwise, I believe our preferred solution is to go ahead with the custom selector and provide a nicer user experience. Geno (WMF) (talk) 17:11, 24 July 2025 (UTC)

Thanks @Geno (WMF). I wasn’t suggesting we might do this instead of what you are proposing, but we might do it sooner, even if we have to wrap Z860 to provide the second argument.

The Wikifunctions component also allows languages to be found by searching on their code or their ZID, so I hope that will also be an option for embedded function calls. I think what we ultimately require is quadruple support, so that the user can also specify the language as a Wikidata item reference.

I don’t know why displaying a language is not currently within scope, but I think it’s important to consider the solution options for that at the same time, even if implementation occurs later. The main challenge for community functions here is that we have no way for such a function to convert a language code to a ZID and no way to extract a label from a Z60 even if we have the ZID. This leaves us with nothing to display other than the text of the Z60K1/code itself. GrounderUK (talk) 22:16, 24 July 2025 (UTC)

@GrounderUK: To clarify, if we do what you ask and add a reader function for Z60s, it will break the code we are writing and we will have to write more. So we are saying we should be sure we can justify spending more time (and thus money). Adding a display function for Z60s does not break that code, but is not planned work. We could do it, but (as I said below) I don't think it's a good idea with that proposed function as its output is terrible. Jdforrester (WMF) (talk) 22:36, 24 July 2025 (UTC)

Thanks, James. For the avoidance of doubt, I haven’t asked anybody to do anything. Nor am I likely to do so in the absence of a community consensus. (But if you could just sort phab:T366459, that would be much appreciated.) I imagine the language code to ZID lookup would have to be a built-in function, so that would require a separate Feature request in any event. GrounderUK (talk) 23:11, 24 July 2025 (UTC)

@GrounderUK: In terms of the display function, I think Z14329 would give readers a very poor experience. Language codes as a plain piece of text aren't obviously telling the user something, and the codes aren't familiar to many users; even experts will be confused by some (think e.g. of Z1547, code es-419). Also, that function doesn't take into account the context language, which all display and reader functions are required to do. Maybe we should wait on that side until we have agreement on what a better function would be, and build it? I'd be happy to help create a candidate function, though maybe it should return HTML so we can link the language label to something or style it? Jdforrester (WMF) (talk) 17:18, 24 July 2025 (UTC)

Thanks, James. I’m afraid we haven’t really got a grip on how we give the end-user options so that the function result looks and behaves the way the contributing community wants it to. Consider this simple example:

Hanover (German: Hannover) is a German city. w:simple:Hanover

In this sentence, the first “German” is a link to the German language article (provided by a template call: {{lang-de|hannover}}). That’s the Simple Wikipedia article, of course, not Simple Wiktionary or English Wikipedia. The editorial rule here is already quite complicated: if the label for an item in the language of the function’s context differs from the label in some other language (specified or derived), also provide (in parentheses, say) the label in the other language (typically in italics) together with the name of the other language (positioned relative to the label and separated from it according to the style appropriate to the context) as a link to the article appropriate to the context. (Compare w:fr:Hanovre, where the French « en langue » template prefixes "en " and separates the link from the following colon with a space.) GrounderUK (talk) 11:50, 25 July 2025 (UTC)

@GrounderUK: Exactly, I think a conversation (here? on Talk:Z11?) about what ideally we'd want to be able to show to readers, and then maybe what compromises we'd accept (ahead of features/consensus/magic AGI/etc.) before rushing to connect a given Function as the display Function for the Type. Jdforrester (WMF) (talk) 15:03, 31 July 2025 (UTC)

It’s rather a question for the content contributors who will be using embedded functions, I think. Maybe we should have a separate forum for the wider community? @Sannita (WMF) GrounderUK (talk) 21:33, 30 August 2025 (UTC)

@GrounderUK Sorry for taking this much to answer. I don't have an answer as to where to store the discussion. Being something that involves at 99% community, I'd say community should decide where to host it. I guess a new page for the scope it's a good idea, but I'm not willing to make a decision on behalf of the community. Sannita (WMF) (talk) 10:07, 7 September 2025 (UTC)

Thanks, @Sannita (WMF). I think we need to think carefully about who “the community” is in this context and, more generally, how to engage the wider community (outside of Wikifunctions) in discussions of this type. Happy to file a task for this, if you like. GrounderUK (talk) 23:36, 15 September 2025 (UTC)