Wikifunctions:Project chat

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

Other places to find help:

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

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

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

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)

Proposed JavaScript conversion functions for Wikidata geo-coordinate

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

• Convert from Wikidata geo-coordinate, JavaScript (Z25954)
• Convert to Wikidata geo-coordinate, JavaScript (Z25955)

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, JavaScript (Z25954) therefore checks for those possible void values. If there's a void value, it's converted into JavaScript null. Accordingly, Convert to Wikidata geo-coordinate, JavaScript (Z25955) checks for those possible null 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.

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)

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)

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)

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)

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)

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 6. 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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

FYI: hiding messages in playing cards

https://asherfalcon.com/blog/posts/3 ―Justin (koavf)❤T☮C☺M☯ 00:55, 22 July 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)

Read and display functions for Natural language (Z60)

language to language code (Z14329) and Language code 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)

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)

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)

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. Article-less instantiating fragment (Z26039) uses String (Z6) as the output type, whilst Article-ful instantiating fragment (Z26095) outputs Monolingual text (Z11), despite depending on a String (Z6) outputting function, English article-ful instantiating 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)