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

proposed Reader and Display functions for Byte Type

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

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

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

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

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

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

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

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

@DVrandecic (WMF) @Denny ping again. The bot wants to archive this section. --99of9 (talk) 04:46, 16 May 2025 (UTC)

@99of9 Thank you so much for your patience! The read and write function have been now set on Byte as per your proposal. Everyone, feel free to test it, I tried it a bit and it works like a charm! Thank you for all the work. --DVrandecic (WMF) (talk) 09:33, 16 May 2025 (UTC)

Thanks for clearing some important backlog. It's great to have you back. If you have more capacity, I sent a reminder of a few trickier backlogs for you via @Sannita (WMF) at . --99of9 (talk) 23:56, 21 May 2025 (UTC)

Hi @99of9! I checked with Sannita, and I am trying to find the other topics you listed. One is about connecting tests to built-ins, and the other two seem about the converter for floating point numbers. I haven't caught up on the chat yet, is there a place I can read up on the floating point issues (besides going through the chat, which I will do some day)? --DVrandecic (WMF) (talk) 14:46, 26 May 2025 (UTC)

April 7th “I've just been investigating Z21923 and am now confident that the float64 converters to code are not dealing with the special case of subnormal numbers. When the exponent is -1023 (just this specific value), the mantissa should not get the 1+ in line 47 of Z20875. Similar omission in the JS converter.

“Then in Z20885 it looks like like 83 should not subtract the 0.5 for the specific case of the exp being -1023 (or actually -1022 at that stage, since it is decremented in the following line)” GrounderUK (talk) 16:30, 26 May 2025 (UTC)

Hi @DVrandecic (WMF), yes, thanks @GrounderUK that's all I wrote about #3. If you need more info let me know, but I learned most of what I know from wiki. Most relevant here is w:Double-precision_floating-point_format#Exponent_encoding. --99of9 (talk) 23:12, 26 May 2025 (UTC)

February 2nd is #4: "I've realised that the question at the end of the FOTW section I wrote is now more urgent. The question was "Should special values return with their other (usually disregarded) keys matching the values of the sign, mantissa and exponent in the IEEE 754 binary representations?". It's now urgent because the type reader is now hardcoding the representation of the special values in every test that involves them (e.g. Z22081). Perhaps obviously by posing the question, I favour returning values for all keys that match how they appear in the binary representations." This received some concurrence, and I haven't seen anyone against it. --99of9 (talk) 23:15, 26 May 2025 (UTC)

Numeric type : Real number ?

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

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

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

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

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

Defining a color for referenche elsehwere either as :

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

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

One way it could work is to reprensent (comptable) real numbers by fonctions that take a precision and returns a rational number. <math>\pi<math> would be internally implementations of algorithms / formulas that computes it up to some arbutrary precision.

The arithmetic basic opération like addition would be higher order fonctions that takes real numbers as arguments and returns themselves a real number, so a function that takes a precision and returns a rational number that approximates the sum up to that precision. (A number of bits, or a number of decimals) TomT0m (talk) 12:35, 21 April 2025 (UTC)

I've started a little way down this track. A good example is pi approximation from Chudnovsky partial sum (f64) (Z23902), but with a rational return. --99of9 (talk) 23:47, 25 April 2025 (UTC)

@Dv103 made another very nice example of this at square root of rational with precision (Z24505), which I hope we can use as a general model. --99of9 (talk) 15:03, 5 May 2025 (UTC)

If I understand the proposal right, the proposal is not to create a type for real numbers, but rather functions that return a real number with an argument for the precision in one of the existing types. Is that right? That seems to take us pretty far.

To the best of my knowledge -- but I am not a mathematician -- the answer to the question of how to create a type for real numbers isn't obvious yet. See also this thread and this paper.

Having said that, and re-reading the thread and skimming the paper, it would involve two new types:

1. a number with a precision. Since we need that for the Wikidata quantity type anyway, we should probably have one such type that will also work for the Wikidata quantity type.
2. the type as described in the paper for even more goodness.

Just a thought. --Denny (talk) 10:39, 16 May 2025 (UTC)

Using functions on main page

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

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

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

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

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

@GrounderUK: If you want us to provide a MediaWiki magic word that reports the number of Functions on the site, we can definitely build that — equivalent to {{NUMBEROFARTICLES}}. Jdforrester (WMF) (talk) 13:36, 24 April 2025 (UTC)

Yes, please! Feeglgeef (talk) 16:07, 24 April 2025 (UTC)

@GrounderUK, @Feeglgeef: Patch written; will hopefully get it reviewed over the weekend and shipped next week, or maybe that thereafter. Jdforrester (WMF) (talk) 16:19, 25 April 2025 (UTC)

Ah, yes… and just those counts is also not a problem. No need to reply to my previous comment. Thank you for this (and everything you do). GrounderUK (talk) 16:45, 25 April 2025 (UTC)

@99of9, Feeglgeef, GrounderUK, and Hogü-456: With apologies for the delay, this is now live – you can see entries in Special:Statistics, and summon them in wikitext via:

• {{NUMBEROFOBJECTS}}, the total number of Objects (16226),
• {{NUMBEROFFUNCTIONS}}, the number of Functions (2592),
• {{NUMBEROFIMPLEMENTATIONS}}, the number of Implementations (4444),
• {{NUMBEROFTESTCASES}}, the number of Test cases (7861),
• {{NUMBEROFTYPES}}, the number of Types (65), and
• {{NUMBEROFLANGUAGES}}, the number of (natural) languages (969).

Do we want to add these to Template:Main page? (Should this particular part of the conversation move to Wikifunctions talk:Main Page?) Jdforrester (WMF) (talk) 21:20, 13 May 2025 (UTC)

Number of Functions in the current manual spot please. Feeglgeef (talk) 11:03, 14 May 2025 (UTC)

I have replaced our manual counter for the number of functions with {{NUMBEROFFUNCTIONS}}. --Ameisenigel (talk) 13:46, 14 May 2025 (UTC)

Thank you! --Denny (talk) 10:46, 16 May 2025 (UTC)

Should that be number of functions or number of functions excluding built-ins? The “…that anyone can edit” tag suggests the latter, but we could just deduct the (relatively stable) number of built-ins. Thanks for the offer… I think this is phab:T345477 (or related). GrounderUK (talk) 17:46, 24 April 2025 (UTC)

@GrounderUK: Excluding pre-defined Objects is a real chore (and currently meaningless //e.g.// for Types or (natural) Languages, so for now I'm not offering it, but if really needed we can bear this in mind next time we re-build the DB table so it stores this information. Sorry to disappoint! Jdforrester (WMF) (talk) 16:20, 25 April 2025 (UTC)

Not a problem. We were talking specifically about functions, though. A separate count per type is also not a problem, but a count of all objects on its own does not satisfy the specific use case. Thanks! GrounderUK (talk) 16:29, 25 April 2025 (UTC)

Yes please. Please also consider which other magic words can he used to supply us with contemporaneous data. Real data makes running functions much more interesting. --99of9 (talk) 02:04, 25 April 2025 (UTC)

@99of9: Perhaps something like "this wiki has been running for {…} years, since opening on 2023-08-01", using Z20756/age? Jdforrester (WMF) (talk) 16:22, 25 April 2025 (UTC)

proposed Display function for Gregorian calendar month Type

I suggest we use display Gregorian calendar month (Z24086) as a display function for the Gregorian calendar month (Z16098) Type. Similar to #proposed Display functions for Day of the week Type, this display function calls for a Wikidata label of the object, and has elaborate and flexible handling of fallback languages if the editing language variant does not have a corresponding Wikidata label.

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

@99of9: Thank you! Done so! Again, thank you for your patience and for shepherding this change. --DVrandecic (WMF) (talk) 15:06, 18 May 2025 (UTC)

Tracked in Phabricator:
Task T394769

For some reason now display Gregorian calendar month (Z24086) doesn't work Dv103 (talk) 16:45, 18 May 2025 (UTC)

Good pickup. I can't see anything wrong, and have tested the functions that the composition calls. Likely a bug? --99of9 (talk) 02:09, 19 May 2025 (UTC)

Weird. It worked yesterday when I was testing it out. I'll let the team know. --Denny (talk) 11:27, 19 May 2025 (UTC)

It looks like this is now working again. --99of9 (talk) 02:02, 11 June 2025 (UTC)

Quick prototyping possible?

Generally, to see the output of a piece of code I'd like to write for Wikifunctions, I have to first create the function for it, then create an implementation, then connect that implementation if I want to see its output, even if it's not done. With compositions I can simply go to Special:RunFunction and test it there, but with code implementations there's not much I can do (to my knowledge, at least).

I've a relatively ambitious idea and I'd like to experiment with it before I try making a full-fledged function + implementation + tests for it. Is there any way I could do this in a way that doesn't require too much extraneous effort and ZObject creation? It's something that will require specific steps and I'd like to lay it out and test it before I fully commit to implementing it, but there doesn't seem to be an easy way for me to do that. — rae^5e <talk> 16:59, 7 May 2025 (UTC)

No, I think you have laid out most ways to do it for now. There is one small way that can improve it: the way I do it is that I usually create a small number of tests first, and then I can run and rerun the tests while coding the implementation before I publish the implementation. And then, only once the tests are good, I click on publish. Would that help a bit? --Denny (talk) 13:15, 19 May 2025 (UTC)

Wikifunctions & Abstract Wikipedia Newsletter #201 is out: Abstract Wikipedia and the Wikimedia AI Strategy

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

In this issue, we discuss how Abstract Wikipedia ties in with the newly announced WMF's strategy for AI, we talk about the Wikimedia Hackathon and our community meetings, and we take a look at the latest software developments.

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

Enjoy the reading! -- User:Sannita (WMF) (talk) 10:27, 10 May 2025 (UTC)

This is an interesting update. I have thinked a bit about usage of AI for Abstract Wikipedia and I am not sure how well it will work for small language versions. As far as I unterstand it is necessary to have enough data to train a model. It is important to check a text if it makes sense and not just translate it or generating content in a language a person can not speak. Instead of having no article I also like boilerplate templates. So a text with gaps for variable content depending on the specific subject. For simple use cases it is possible to make suggestions without a huge LLM in the background and instead with simple decision trees. So I think it is necessary to improve the data in Wikidata and add more statements to items. Usually larger articles in Wikipedia have more contents at what is listed in statements in the related Wikidata item. For the definition and necessary for the translation of the boilerplate templates people who can speak the local language the an abstract text should be converted to are required. So far I miss interaction of people of small Wikipedia language versions in Wikifunctions and it seems to me like a theoretical discussion and I hope there is enough awareness about irregular cases. Languages are in parts not easy to generate automatically. Hogü-456 (talk) 20:25, 11 May 2025 (UTC)

Why shouldn't the language model also translate (render) from the middle pane (abstract content) to readable prose?

I uploaded a screenshot of the middle pane and fed it into Gemma 3, Google's latest open model, with the prompt:

Render the abstract knowledge representation displayed in the image into fluent expository Hebrew prose, suitable for an encyclopedia.

The result was:

.מרי קורי היא האדם היחיד שזכה בפרס נובל בשתי קטגוריות מדעיות שונות

Or, in English:

Marie Curie is the only person to have won the Nobel Prize in two different scientific categories.

This is achievable using open models today. It will only get better as LLMs are trained on richer corpora, expanding their reach to a wider variety of human languages. Where will these capabilities be in a year, and where will Wikifunction's natural language generation capabilities be? ATDT (talk) 01:39, 12 May 2025 (UTC)

Hi @ATDT, thanks for the question! There area a number of reasons:

• this doesn't work well for many of our small languages, such as Dagbani. For the large languages it often works OK, but they are the ones that need it least.
• there is no guarantee of the results being correct. This system could work with a "let's generate and then have humans check the results" approach, but the goal of Abstract Wikipedia is to be able to edit the abstract content and then publish immediately in all supported languages without having to check the output again.
• if a generation is wrong, it is unclear how to fix it (unless we do it manually, but in that case we are at the same point as with just using machine translation right now).

I would think that if we use a model for generating output, we'd always need a human in the loop who understands both the input and the output languages. And that's basically the 1:1 machine translation approach, not the Abstract Wikipedia approach, where we create with high fidelity the output in all participating languages without requiring a human in the loop in the generation step. --Denny (talk) 13:37, 19 May 2025 (UTC)

Wikifunctions & Abstract Wikipedia Newsletter #202 is out: Location of Abstract Content

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

In this issue, we invite you to a consultation about where should the content of Abstract Wikipedia be stored, we invite you to our next online presentation, 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) 10:56, 16 May 2025 (UTC)

Wikitext -> AST and vice versa

It may be useful to have functions for lexing/tokenizing and parsing Wikitext into an AST, and going from that AST back to Wikitext. It would vastly improve the power of functions in Wikifunctions:Catalogue/String operations#Wikitext and Mediawiki string operations. I think this also meshes neatly with Abstract Wikipedia. If it's planned to have rich/styled output, dealing with an AST is much preferable to performing operations on Wikitext directly.

The downside of this is that it would be complicated and a lot of work to implement, and likely require the creation of a couple new types, at least. However, there already exist several Wikitext parsers, so perhaps a parser (Parsoid?) could be provided as a built-in implementation? Though, this would still necessitate the creation of several types.

Would this be (a) feasible and (b) useful? --WrenFalcon (talk) 22:55, 19 May 2025 (UTC)

Ah, I just read Wikifunctions:Embedded function calls#Wikitext output. That would mean this wouldn't really be possible... though it may still be possible to implement an AST for HTML. --WrenFalcon (talk) 23:23, 19 May 2025 (UTC)

Wikifunctions & Abstract Wikipedia Newsletter #203 is out: Ongoing consultation about the Location for Abstract Content

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

In this issue, we invite you again to a consultation about where should the content of Abstract Wikipedia be stored, we present some updates about existing and new types, we remind you of our next online presentation, and we take a look at the latest software developments.

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

Enjoy the reading! -- User:Sannita (WMF) (talk) 13:54, 23 May 2025 (UTC)

Wikifunctions & Abstract Wikipedia Newsletter #204 is out: Rolling out to five Wiktionaries; Calculating with today's date

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

In this issue, we talk about our latest deployment on five Wiktionaries, we showcase a couple of functions about dates, we remind you of ongoing discussions and upcoming presentations, 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 June 2, at 17:30 UTC (link to the meeting).

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

Solvers (and color spectrum reconstruction.)

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

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

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

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

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

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

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

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

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

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

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

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

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

In this issue, we give you some updates on the discussion about where to store abstract content, we present you the recordings of our latest presentations and meetings, and we take a look at the latest software developments.

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

Enjoy the reading! -- User:Sannita (WMF) (talk) 13:38, 9 June 2025 (UTC)

A guide to easily implement a lenient Gregorian calendar date reader

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

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

proposed Read and Display functions for Day of Roman Year

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

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

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

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

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

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)

equality function for Time of day

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

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

code conversion for Time of day

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

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

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

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

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

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

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