Wikifunctions:Project chat/Archive/2025/08

Correction for Z25177

The code converter Z25177 has an error: it lacks a } at the end. Could someone with the needed rights add it? Dv103 (talk) 09:48, 8 August 2025 (UTC)

@DMartin (WMF) maybe? 99of9 (talk) 11:25, 9 August 2025 (UTC)

Thanks for noticing and mentioning! I took care of that. DMartin (WMF) (talk) 19:54, 11 August 2025 (UTC)

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

"You don't have permission to connect an Implementation to its Function so it can be run."

Hi I created a small function for variance and wanted to add some tests for it.

(!) list variance - Wikifunctions

I don't have the permissions to do this. Is there something I need to do (other than ask here)? GrimRob (talk) 09:55, 22 August 2025 (UTC)

You should have the right to add testcases. You instead need to be a functioneer to connect implementations and testcases. Dv103 (talk) 10:00, 22 August 2025 (UTC)

Thanks. I didn't realise I could run it indirectly via Tests, so have added a couple. GrimRob (talk) 10:07, 22 August 2025 (UTC)

Now I've connected everything. Dv103 (talk) 10:09, 22 August 2025 (UTC)

This section was archived on a request by: Dv103 (talk) 17:59, 26 August 2025 (UTC)

Equality function for Z89

@DMartin (WMF) Should HTML fragment equality (Z877) be connected as the equality function for HTML fragment (Z89)? Dv103 (talk) 09:50, 29 August 2025 (UTC)

@Dv103: I've connected these; in future, you don't need to ping members of the team, just post in here. :-) Jdforrester (WMF) (talk) 15:52, 29 August 2025 (UTC)

This section was archived on a request by: Dv103 (talk) 19:37, 30 August 2025 (UTC)

Types for vectors/matrices

I'm considering making a few functions for least squares methods, and am unsure what types to be using for the input and output. These methods take as input an nx1 vector and nxk matrix, and output a kx1 vector (coefficients) and nx1 vector (residuals). Vermont (talk) 14:51, 7 August 2025 (UTC)

For representing vectors I've always used Z881(Z19677), while for matrixes I've used Z881(Z881(Z19677)) (see Wikifunctions:Catalogue/List_operations#Linear_Algebra). I'm instead not shure on how to return 2 values (list of length 2? Two different functions?).

By the way, working with lists and in particular with lists of lists can be very painful. Dv103 (talk) 15:00, 7 August 2025 (UTC)

Heads-up regarding changes to Wikidata statement (Z6003)

The biggest remaining gaps in what we import from Wikidata are qualifiers, references, and no value / some value statements. We are currently working on adding these things, in a way that closely mirrors Wikidata's data structures. This involves the following additional keys in Wikidata statement (Z6003): Z6003K5/qualifiers, Z6003K6/references, and Z6003K7/claim type.

The rest of this post is about Z6003K7/claim type, which will have these 3 possible values: value (Z6021), no value (Z6022), some value (Z6023). When Z6003K7 is either no value (Z6022) or some value (Z6023), Z6003K3/value will have void (Z24) rather than an ordinary value. Therefore, a function that returns statement values could sometimes return void (Z24), which, depending on the function, might not be an appropriate return. I've been looking at functions that might be affected by this and, so far, I only see a few functions that might need to be changed.

Here's an example of a function that I think does not need to be changed: value of Wikidata statement (Z19308). Since it's just a simple accessor that pulls out the value of Z6003K3, I think it's appropriate for it to return void (Z24) sometimes. Similarly, value type of statement (Z23516) would legitimately return Unit (Z21) for those cases.

On the other hand, grammatical features of lexeme (Z22559) clearly should not return any void values; it's only meant to return a list of Wikidata item reference (Z6091), from person/number/gender statements. I doubt if there are any person/number/gender statements with type no value (Z6022) or some value (Z6023), but I'm not certain so I'm inclined to modify this function, and a few similar ones, so they couldn't possibly make the mistake of returning a void (Z24).

I'm still looking, but so far I've only found these functions that should possibly be modified in this way: grammatical features of lexeme (Z22559), filtered grammatical statement values (Z22561), grammatical features inherited from lexeme (Z22556), grammatical features of lexeme form (Z22487), all grammatical features of lexeme form (Z22638), values (unqualified) from Wikidata item statements (Z22978), first value of property from wikidata item (Z21449).

I will continue looking. If anyone is aware of other functions that might need attention, please mention them in a reply. --DMartin (WMF) (talk) 04:31, 8 August 2025 (UTC)

Another consequence of these changes to Wikidata statement (Z6003): Tests which check a list of values extracted from statements, or the first value extracted from a group of statements, could start failing, simply because there will be more statements imported. (The new statements are not only those of types no value (Z6022) and some value (Z6023), but also all statements with qualifiers.) Example: monolingual text values of WD statements (Z23168). DMartin (WMF) (talk) 05:35, 9 August 2025 (UTC)

Yes, we'll be on the lookout for that. But that's not a big change, because we already expect Tests based on live Wikidata results to be susceptible to the underlying data changing. --99of9 (talk) 11:28, 9 August 2025 (UTC)

API unusable outside UserJS (and desktop apps ofc)

When I try to fetch a ZObject with a script on another site, the response doesn't set the Access-Control-Allow-Origin header, so Firefox (or any compliant browser) refuses to let the script read the body. Is this intentional? Do I need to provision an API key or something? I'm hesitant to sink time into a debugging tool if the end product would need you to fiddle with UserJS to use it. YoshiRulz (talk) 12:43, 9 August 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. --DMartin (WMF) (talk) 18:36, 10 August 2025 (UTC)

Heads up regarding labels containing "claim"

In order to support qualifiers and references, we're going to deploy a new type that directly corresponds to Wikidata snak. We don't want to use "snak" in its label, so we've decided to call it Wikidata claim. We think it's the best available choice, but it's not perfect: "claim" hasn't been used consistently in Wikidata practice over the years, so different folks may have different understandings of it. In particular, it's possible to think that it's synonymous with statement, because we've been using "claims" properties in Z6001/2/4/5/6 to hold a list of statements. (That choice was based on its usage in Wikidata JSON files, which I think would better be called "statements".)

To help avoid confusion, I'm planning to change those "claims" property labels to "statements". Also, there are about 36 functions with "claim" or "claims" in their English label, and I'd like to (carefully) change those, wherever appropriate, to statement/statements. We have a Glossary page where I can also make it clear once and for all what we mean by" claim". I'm interested to know if folks feel comfortable with these proposed changes; please feel free to comment! --DMartin (WMF) (talk) 05:22, 6 August 2025 (UTC)

Fair enough. I'm probably responsible for a fair chunk of those "claim" labels, because my vague mental definition of that word that includes both statements and snaks. But I'd much prefer you define it more precisely than to expect everyone to learn a made up word "snak". So I support this change. --99of9 (talk) 01:26, 7 August 2025 (UTC)

Thanks, @DMartin (WMF). It doesn’t help that there are different kinds of Snaks, does it!

As I understand it, these Snaks are just ways of expressing predicates. What we’re calling a “Wikidata statement” (or “claim”, for short) is basically a predicate attached to a Wikidata item as subject.

This new Wikidata property claim (Z6007) (whatever we decide to call it) looks like it’s a proposition with such a predicate as its subject. Arguably it’s just a kind of qualifier applying to the predicate (or some part of it: its Z6003K3/value).

I’m not sure what our broader plans are for Wikidata qualifiers, but I think I’d rather go with a label aligned with that general idea: something like Wikidata statement qualifier (as long as we’re clear it’s never the subject that’s being qualified) or Wikidata value qualifier, perhaps? GrounderUK (talk) 10:25, 7 August 2025 (UTC)

That makes sense. However, Wikidata property claim (Z6007) will be used both for qualifiers and for references, just as snaks are used for both -- so there's no need to have a distinct type with qualifier in the name. Each qualifier will be an instance of Wikidata property claim (Z6007), and each Wikidata reference (Z6008) will contain a list of such instances. DMartin (WMF) (talk) 00:08, 8 August 2025 (UTC)

But does that mean we'll be mixing up which "snaks" are actually qualifiers and which are actually references? How will we be able to tell whether it is one or the other? 99of9 (talk) 01:46, 8 August 2025 (UTC)

That will be known by where they appear, either in Z6003K5/qualifiers or Z6003K6/references (new properties mentioned in the next post below). DMartin (WMF) (talk) 04:33, 8 August 2025 (UTC)

Ah, thanks for your clarification, @User:DMartin (WMF).

As I see it, the problem is that “Wikidata property claim” is generally confusing and technically incorrect. In simple terms, given a triple where the first element is the subject, the second and third elements considered together are traditionally described as the “predicate” (述語). The subject and predicate taken together constitute the proposition or claim. Understanding the subject from the context is fine (as a kind of zero anaphora), but it will always be confusing to call a predicate a claim.

References are a little different because they apply to the entirety of the Wikidata statement. Given that, it’s not clear why they are anything more than a list of Wikidata items. Sticking with what we’ve got, a list of “Wikidata predicates” seems less confusing than a list of “Wikidata property claims”, but perhaps “Wikidata statement predicate” might be preferable.

Adopting this traditional sense of predicate does create a clash with the current label for Z6003K2, but re-labelling that to something like “property type” would be likely to enhance clarity (occurs 29 times in the main namespace). Conversely, suggesting that “claim” (78 occurrences) and “statement” (98) are anything other than interchangeable risks causing more confusion, especially where they have already been translated. GrounderUK (talk) 12:15, 8 August 2025 (UTC)

Thanks, @GrounderUK. I've also had reservations about using "claim", but I've just taken a look at the Wikidata Glossary page, and it's actually describing "claim" the way we've started to use it. For example, it says A claim consists of a property (such as location) and either a value (e.g., Germany) or one of the special cases "no value" and "unknown value". (In fairness, the glossary page muddies the waters in some other places where it mentions "claim" -- but the quote just above is from the definition of "claim" and provides a strong validation of the way we are starting to use it.)

Note: I'm inclined to drop the word "property" from Wikidata property claim (Z6007), as it seems like another potential source of confusion.

You make good points about "predicate", and I'm sympathetic to them, but that's not perfect either because in the semantic web and RDF world it's commonly used pretty much interchangeably with "property" – and it's also used that way in the Wikidata glossary page; e.g. it says a claim uses a property to express the predicate of a triple and a value to express the object of a triple.

Wikidata reference (Z6008) was motivated by ReferenceRecord in Wikidata, which is a list of Snaks. DMartin (WMF) (talk) 05:55, 11 August 2025 (UTC)

Ah, thanks for the reference @DMartin (WMF). As I understand it, « ReferenceRecord(Snak {Snak} » defines a structure where the first Snak relates the source to the Statement, whereas all the Snaks in the list have this first Snak as their subject, representing propositions about the source-as-reference. I’m not sure it’s a good idea to flatten this structure, even though the original nesting should always be recoverable from it.

Thanks also for your further thoughts on the English label for Z6007. I certainly agree that removing “property” would be a step forward. However, “Wikidata claim”, on its own, reads as a proposition asserted by or on Wikidata. Although there is such a proposition, the fact that the subject is elided deserves a mention. I can see that “predicate” may also be a source of confusion but I can find no other English word that has its traditional meaning. I have used qualifiers such as “headless” or “anaphoric” to emphasise the fact that the subject is implicit, but I’m wondering whether we might use something like “contextual” here, in order to clarify that the subject is indicated by the position of the headless claim?

In any event, I think we need to look again at “Wikidata claim type”, since this seems to relate only to the object in the triple (Z6003K3 and Z6007K3). Given the instances, “Wikidata value type” should work, although “type” is a bit weak here and liable to be confused with the data type. How do you feel about “Wikidata value status”? GrounderUK (talk) 09:25, 11 August 2025 (UTC)

Thanks @GrounderUK for pointing out the semantics of the snaks in a ReferenceRecord; I hadn't seen that documented anywhere but yes, it makes sense. However, we are not doing any flattening – at least, not with respect to what we get in JSON from Wikidata. What's in the JSON is essentially just a list of snaks. It's represented in a slightly complicated way, but it does not distinguish structurally between the first snak and the other snaks. Given that, and given that we generally are trying to mirror what comes from Wikidata (with minimal adjustments as needed for Wikifunctions), I thinking we don't need to introduce structure that's not present to begin with (and not clearly documented to my knowledge). In other words, I'm thinking it's sufficient to carefully maintain the order of the snacks, and document what's going on in an appropriate place (I still have some documentation work ahead of me.).

Regarding "Wikidata claim", we are using "claim" as our replacement for the term "snak", which I'm "claiming" is pretty well warranted by what the Wikidata glossary says about "claim", and we are using the prefix "Wikidata" just to indicate that the content and the representation are taken from Wikidata, in the same way that we have labeled "Wikidata statement", "Wikidata lexeme", etc.

"Contextual claim" is a nice idea, but I'm not convinced the longer label is necessary if we just cleanly define "claim" as synonymous with "snak". To my mind, although there is an association of "claim" with "proposition", I don't think the association is that strong for most people, so it's okay to use it in our own way here. Does anyone else want to weigh in on this?

Regarding "Wikidata claim type", that's motivated because it's imported from "snak type" and we're just replacing "snak" with "claim". I agree that "claim" isn't a perfect choice, but once we've documented what we mean by it (partly by reference to the Wikidata glossary), I think it will work out to do that terminology substitution consistently. Also, I'd say the notion of "snak type" doesn't just characterize the object of a triple; it characterizes the snak as a whole. For example, a snak of type "no value" says: for the (implicit, contextual) subject, there is no value for the given property, whereas a snak of type "value" says : for the (implicit, contextual) subject, there is this value for the given property. DMartin (WMF) (talk) 00:02, 14 August 2025 (UTC)

Thanks, @DMartin (WMF). Forgive my multiple replies. I agree that Wikifunctions should follow what Wikidata actually does, rather than what I think its documentation says. As I almost said, the special interpretation of the first Snak in the list should not be a problem. GrounderUK (talk) 08:08, 14 August 2025 (UTC)

I agree that by characterising the state of a proposition’s predicate, we are indirectly characterising the proposition as a whole (without considering the representation). But considering any proposition represented as R(a,b), it is only b that is characterised by the “Snak type”. This corresponds to a finite state machine where the initial state of the proposition is “some value” and the possible transitions are triggered by the provision of a value (making the state “value”) or the assertion that there is no such value (making the state “no value”). In more formal terms the pattern conflates existential quantification with variable binding, which makes it harder to find a meaningful name. The FSM framing avoids that, and since we’re calling b a “value”, “value state” is neutral terminology. GrounderUK (talk) 09:32, 14 August 2025 (UTC)

When it comes to using the word “claim” without explicit qualification, it seems we may just have to agree to differ. I’m happy to avoid the word altogether (except when the truth of a proposition is doubted), but this will prove difficult if the word is co-opted to serve as a synonym for “predicate” (in the normal sense of the word).

Looking at translations of functions currently using the word “claim”, it seems that it has been consistently translated as if it said “statement”, so avoiding the word should only affect English labels. It will be interesting to see how Wikidata property claim (Z6007) might be translated, but so far we only have Italian “Affermazione Wikidata” (contrasting with “Dichiarazione Wikidata”), which, I feel (@Dv103), suffers from the same difficulty as the English in distinguishing the case where the subject is explicit from the case where it is not. GrounderUK (talk) 12:30, 14 August 2025 (UTC)

"Affermazione" in Italian is basically sinonym with "dichiarazione" (similar on how in English "declaration" and "claim" are basically the same word with different etymologies). I've actually never seen "affermazione" used on Wikidata, because there only "dichiarazione" is used meaning both "declaration" and "claim". "Affermazione" is just my first attempt to distinguish the two concepts (that I agree need to be separated here on Wikifunctions somehow). Dv103 (talk) 12:37, 14 August 2025 (UTC)

Thanks for these comments! Yes, most snaks are a property plus a value, and the subject is not made explicit, because that's given by what the snak is attached to. And the same for Wikidata property claim (Z6007), which is meant to capture exactly what's captured by PropertySnak (which, at least for now, is documented to be no different than Snak). And yes, the different types of snaks complicate things. I'm planning to say more about this on this page, probably a little later today. DMartin (WMF) (talk) 21:17, 7 August 2025 (UTC)

Content error

Why is display day of the week (Z24041) failing for Sunday (Z17409) when embedded, for "", "Z1002" and "en"

Sunday

Sunday

Sunday

(but Monday and Sunday might succeed)? GrounderUK (talk) 21:16, 30 August 2025 (UTC)

This section was archived on a request by: GrounderUK (talk) 16:00, 15 September 2025 (UTC)

gadget to copy label to mul?

Many of our test labels should basically be the same in all languages. For example Z27549. I wonder if someone could write a gadget to one-click-copy the label from an existing language into the label for the user's interface language (or mul). That would speed up the labelling of new items. --99of9 (talk) 01:32, 19 August 2025 (UTC)

Z20420 with unknown values

@99of9@GrounderUK@DMartin (WMF) I represent this question, given @DMartin (WMF)'s last edits. Should we allow Gregorian calendar date (Z20420) to have unknown values, or should Gregorian calendar date (Z20420) only accept completely known dates, and Wikidata time (Z6064) use a different type that encodes for possibly unknown dates? Dv103 (talk) 08:25, 12 August 2025 (UTC)

I think it depends on what we plan to do with non-Gregorian dates. Please see my comment at Wikifunctions:Type proposals/Julian calendar date#Discussion. Ultimately, I favour a pure proleptic Gregorian calendar date type. We may also want an imprecise version that can support the Wikidata concept of precision. This would mainly be to support conversions between calendars. GrounderUK (talk) 09:09, 12 August 2025 (UTC)

Just to be clear – when you say "pure ..." type, does that mean that unknown values would not be supported? And if so, what would be the arguments for disallowing unknown values? To my mind, it's very natural to allow for unknown values in dates – particularly unknown day and/or month, and I'm not currently aware of strong reasons to forbid them in Gregorian calendar date (Z20420). (On the other hand, if we have an imprecise date type, as you've mentioned, then I suppose we could require that type to be used for unknown values.) DMartin (WMF) (talk) 18:10, 19 August 2025 (UTC)

Yes, a pure type would forbid unknown values. I agree that it is a natural requirement to support imprecise or uncertain dates, which is why I say it depends. But it is also clear that the Gregorian calendar date type was never intended to support these (“A Gregorian calendar date identifies a specific day using the Gregorian calendar system introduced in 1582”). It also doesn’t support decades, centuries or millennia, so I think it makes more sense to create a new type that supports these rather than complicate the existing type. This new type could include Wikidata calendar model (Z6063) and the appropriate subset of Wikidata time precision (Z6062). GrounderUK (talk) 09:55, 20 August 2025 (UTC)

Wikifunctions & Abstract Wikipedia Newsletter #215 is out: Accessing Wikidata items now possible from embedded function calls; Wikifunctions available on 65 Wikitionaries

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

In this issue, we announce that it is now possible to access Wikidata items from embedded function calls, we also inform that Wikifunctions is now available on 60 more Wiktionaries, 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) 14:57, 29 August 2025 (UTC)

This section was archived on a request by: Sannita (WMF) (talk) 21:25, 21 September 2025 (UTC)

Detect/flag when inputs have identical names?

For example, Describe the class of a class (Z27173) has two class parameters in English at time of writing. YoshiRulz (talk) 18:13, 25 August 2025 (UTC)

About Vector 2022 skin in this wiki

Hi. I have something that needs to be clear. How does this wiki is the only wiki that have the Vector 2022 skin optimized for mobile view? In other wikis, it's not optimized for mobile view and we have to zoom the page to see the content, but in Wikifunctions we don't have to do that. Although I have already enabled the responsive mode in global preferences page, but Wikifunctions is still the only wiki that has the Vector 2022 skin for mobile optimized, it does no effects in other wikis. I have checked this wiki and it seems there's no related configuration in MediaWiki:Vector-2022.css or MediaWiki:Common.css, so it might be related to some deep configurations. I also mentioned about this in here but there's no response. Nvdtn19 (talk) 09:51, 22 August 2025 (UTC)

@Nvdtn19: It's an experimental mode built by the Web team, of which we are the first (and so far, only) wiki to take advantage. I believe that the long-term plan is (or was?) to convert all wikis over to it eventually, but I am not involved, sorry. Jdforrester (WMF) (talk) 13:51, 26 August 2025 (UTC)

@Jdforrester (WMF): Oh... So is there any way to contact them? I wanna ask when will this feature be available in remaining wikis. Nvdtn19 (talk) 05:57, 7 September 2025 (UTC)