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

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)

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)

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)

Solvers (and color spectrum reconstruction.)

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

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

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

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

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

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

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

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

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

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

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

A guide to easily implement a lenient Gregorian calendar date reader

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

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

proposed Read and Display functions for Day of Roman Year

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

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

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

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

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

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

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)

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)

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

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

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

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

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)

equality function for Wikidata quantity

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

In this issue, we announce the closing of the discussion about where to store abstract content, we remind you about our current discussions about types and our next NLG SIG meeting, and we take a look at the latest software developments.

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

Enjoy the reading! -- User:Sannita (WMF) (talk) 12:56, 16 June 2025 (UTC)

Import citation related templates

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

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

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

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