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)

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 (15752),
• {{NUMBEROFFUNCTIONS}}, the number of Functions (2526),
• {{NUMBEROFIMPLEMENTATIONS}}, the number of Implementations (4336),
• {{NUMBEROFTESTCASES}}, the number of Test cases (7580),
• {{NUMBEROFTYPES}}, the number of Types (60), and
• {{NUMBEROFLANGUAGES}}, the number of (natural) languages (966).

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 functions for Day of the week Type

I suggest we use the following functions as a display function for the Day of the week Type:

• display day of the week (Z24041): returns a string representing the day of the week (a Wikidata label) in the selected language or a sensible fallback

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) 12:35, 19 April 2025 (UTC)

Support That function works pretty well, thanks for your contributions 99of9! ~/Bunnypranav:<ping> 12:43, 19 April 2025 (UTC)

You're welcome. Though most of the credit for the hard work done on this one goes to GrounderUK (talk · contribs). --99of9 (talk) 12:53, 19 April 2025 (UTC)

I have no problem with the function, but I do have reservations about setting an unfortunate precedent by relying on labels. I think the “officially correct” approach would be to go from the Wikifunctions object to the corresponding Wikidata item and from there to the item’s lexeme and the appropriate form/representation. Failures are possible, of course, and we have two fallback routes to consider, according to the language.

First, for language varieties with a lot of overlap, like Australian English and (en) English, we should fall back to the more common variety. (Note that the function currently returns a blank for Australian English. I imagine that the general fallback for Australian English would be to British English before (en) English, with US-English as a last resort, but even this simple example leads us into treacherous waters.)

Secondly, (also by language), whether we prefer labels to lexemes or a specific function, or (assuming defaults are excluded or handled when a specific function is the option) lexeme/label first then label/lexeme in specified language, or lexeme/label in any fallback language then label/lexeme in any fallback language… and then our default (fall-through) option.

How might this work in practice? We could have a Z14294 that would handle the second cases first. For example, English might be set to prefer labels whereas Italian might prefer lexemes (because « domenica » is feminine whereas other days are masculine, so we’d have « domenica prossima » (“next Sunday”) but « lunedì prossimo » (“next Monday”), per esempio). I guess we’d have separate functions for label then lexeme, lexeme only, lexeme then label, label only; the default function here might also be configured by language for a “native Wikifunctions” experience.

However, configuration by language doesn’t allow the specified language to be switched (from “en-au” to “en”, for example). This suggests that language-switching should be handled separately in the configured functions. It might be a common function, but the sequence may differ according to whether you're looking for labels or lexemes. In any event, I suspect that "language" is better specified as a list, with an empty list defaulting to "mul" (say) and falling through to the default specified in the configuration (or a "mul"-specific alternative). (And when I say “list”, I suppose it would have to be a string representation, for integration, so we might see something like “[Z60, "dag", "en", "mul"]”. I guess we can’t use a read or display function for a generic type, though, and perhaps that challenge is better considered under a separate heading.) GrounderUK (talk) 11:46, 20 April 2025 (UTC)

Good thoughts. I think your proposed "officially correct" function would be worth writing (as would some of the variants you mention), and may indeed work even better for some languages. For language fallbacks, I think we can get separate functions to handle that without changing the input type of a display function. It will take some building, and will be more than a configuration by language, but I don't think it will be too much worse. Just as you were posting this, I was writing a crude language fallback map: general language from language variant (Z24097) as a start! --99of9 (talk) 12:10, 20 April 2025 (UTC)

Update: I've now adjusted the implementations to use the general language fallback if variants (like en-au) come up empty. And the test Saturday in Australian English is en:"Saturday" (Z24105) now passes (with a long runtime). --99of9 (talk) 12:42, 20 April 2025 (UTC)

Perhaps “crude” is a little harsh… but switching between “nn” and “no” then falling back to “sv” or “en” (according to personal preference) is the sort of scenario we might contemplate. One step at at time, though… so long as we don’t trip over one another’s feet! (You have a free run today, as far as I’m concerned! When I get started, I’m more interested in pursuing the lexeme route, but I want graceful fallback from Z6830 outwards, and that means the option to switch languages if no lexeme is found, and (logically) a list of properties to work through too. Although such searches may have less of a performance overhead than item labels, I guess we’d only be able to manage a couple if we want to be able to default to labels afterwards.) GrounderUK (talk) 13:16, 20 April 2025 (UTC)

I'm not aiming for personal preference, because in my understanding display functions will generally apply to all users of a uselang. So I'm just aiming for the best (configurable) outcome for every language. For now I'll stick within the label space rather than the lexemes, but I agree it would be good to have a robust lexeme path available too. --99of9 (talk) 13:27, 20 April 2025 (UTC)

You’re probably right, but I’m speculating that a personal preference and a project default could/should/would look the same at the function level. GrounderUK (talk) 14:25, 20 April 2025 (UTC)

Althouh we obviously want as much progress on lexemes as possible, I've realised that I don't agree it is "officially correct" for display functions. These are rendered output of single day values in a language, not lexically correct parts of a sentence. I think the intent is almost exactly coincident with the intent of a Wikidata label. 99of9 (talk) 01:03, 21 April 2025 (UTC)

I take your point. Without phab:T366459, the display function cannot display the Wikifunctions object label, and even assuming the counterfactual, I can see the sense in defaulting to the label for the corresponding Wikidata item. Presumably, this is how “light-weight enumerations” (T390558) will operate, since there will be no persistent instances to which to attach labels. In any event, as I said before, “I have no problem with the function” and I am happy to withdraw my remark about the lexeme route being « “officially correct” ». (@DMartin (WMF) Any thoughts about displaying the string for a light-weight enumeration? Does the generic type get read and display functions?)

That having been said, the performance is a concern and I am getting a time-outs for Thursday in a language-fallback scenario like Z24106. I suggest we defer language-fallback until we can return multiple selected labels from a single visit to an item. I just used Z13436 in Z24109 to support Z24110 but I think “label-list from item for language-list” will require a code implementation, in the absence of a variadic filter function (T390226). I’ll get started on that. GrounderUK (talk) 08:38, 21 April 2025 (UTC)

Update: I’ve created Z24118, which seems to do the job. I’ve left it disconnected for now as I accidentally passed all the tests with my interim fallback. I think we can just plug in an additional function call for a single “general” language (like “en”) but we’d need to flatten the list if a function returns a list of languages (like my Scandinavian example). It all looks doable but it looks as though a simple variadic filter would not have done the job, downstream, because we need the results in language order (so that’s something else to think about). GrounderUK (talk) 12:15, 21 April 2025 (UTC)

Nice. I've made a harder test Tuesday in Formal German is de:"Dienstag" (Z24143), but also squeezed general language from language variant (Z24097) into your list, so now your new composition passes and is fast enough. Scandinavian hierarchies still to come. --99of9 (talk) 01:29, 22 April 2025 (UTC)

I've added display day of the week, fallback composition (Z24329), which I'm confident does everything we need, because it ultimately relies on the complete flexibility of hardcoding fallback chains for every language in fallback languages, compose hardcoded helper (Z24310). --99of9 (talk) 01:06, 30 April 2025 (UTC)

@User:DVrandecic (WMF) I think this is ready to go. --99of9 (talk) 06:10, 8 May 2025 (UTC)

@99of9 thank you for your patience and your ping, I added display day of the week (Z24041) as a display function to Day of the week (Z17402). Thanks to @GrounderUK for the work! --DVrandecic (WMF) (talk) 07:37, 18 May 2025 (UTC)

Renderlang and parselang

From the documentation it's said that you can set the render and the parse language in function calls from Wikipedia, but they don't seem to work. Are they actually supported? Dv103 (talk) 16:38, 19 April 2025 (UTC)

@Dv103: No, that's not supported yet, we're waiting on upstream fixes first. We intentionally did not document it in the announcements. Jdforrester (WMF) (talk) 13:19, 23 April 2025 (UTC)

@Dv103: See Embedded Wikifunctions calls sandbox and testing notes below — I've created a page documenting what works and doesn't. Jdforrester (WMF) (talk) 21:38, 23 April 2025 (UTC)

Language fallback

We’re beginning to explore implementing language fallback, as discussed in #proposed Display functions for Day of the week Type and Telegram. Please add comments here as we explore this topic together. GrounderUK (talk) 11:45, 22 April 2025 (UTC)

Call for input: Please can those of you who know languages or dialects other than English add tests at fallback languages (Z24144) that reflect your understanding of how your dialect should fetch labels in order if the dialect itself does not have a label (think Wikidata labels). So, for example, I think Z24145 and Z24146 are right, I've added Z24148 but it's debatable whether en should be included at the end (in desparation if mul is not filled).

from @99of9 on Telegram GrounderUK (talk) 11:53, 22 April 2025 (UTC)

Just gathering my thoughts…

• The same approach should work for lexemes from items too, but there are additional challenges there. As a start:
  • Lexemes from Wikidata item reference (Z23616)
    • Wikidata lexeme references for multiple languages (Z24110)
    • Wikidata lexemes by item, property and language (Z24107)
      • Currently only with the item for this sense (P5137) property. This is based on the Cartesian product of languages x items, which means semantic fallback (or equivalence) takes precedence over language fallback. When properties are supported, I expect these to take precedence, so we get the Cartesian product for each property (in theory): properties x languages x items.
• A simple function to convert a babel string to a language-list
  • We should aim to integrate with m:User language somehow, rather than pasting in the string.
• The last resort, when nothing is found for any of the languages listed, could still be structured in some way (and this is deliberately vague).
  • For example, if French (Z1004) is specified and English (Z1002) is a fallback but Spanish (Z1003) is not, a Spanish result might be preferred over Arabic (Z1001), Russian (Z1005) and Chinese (Z1006).
• When none of the available labels are suitable for fallback, they can be strung together as a “shrug”.
  • For example, "(en) one → (fr) un → (sv) en" (Z24161), testing Z24159.
    • The separators can be anything or nothing and the parenthetical language codes (like « (en) ») are just those provided by display Monolingual text (Z21583).
  • We could work with some specified or default size limit or an absolute numerical limit, and/or we could truncate the result to some size before the previous separator (perhaps with some indication of more).
  • We could have the “shrug” itself specified as a “fuzzy tail”: a list of languages that is specified as secondary fallbacks or derived from the primary language(s), for example) 🤷‍♂️🐿️
    • We’d still fall through to anything that’s available, by default, but we could consider a negative filter to exclude languages or alphabets that are specified or assumed to be meaningless in a given context.

GrounderUK (talk) 14:14, 22 April 2025 (UTC)

• A similar approach has been implemented for representations within lexeme forms: select representations from forms by language (Z24240).

GrounderUK (talk) 23:07, 24 April 2025 (UTC)

English and the great divide

• Simple English (Z1124) should probably fall back directly to English (Z1002) and then (equally) to “Englishes other than US (influenced) Englishes” and American English (Z1689) (US English). US English should probably fall back directly to English and then to “Englishes other than US (influenced) Englishes”. Other Englishes should probably fall back to one another (perhaps with Canadian last and British first), then Z1002 and then Z1689 or “Englishes other than US (influenced) Englishes”, according to which group they’re in. In practice, I think that’s the same as “variety”, “group for variety”, “all English varieties” (whose first language is Z1002).
• Do we have enough Englishes? Do we need a persistent Z60 for every variant, or can we map transient natural language objects to existing persistent Z60s (like “en-NZ” to “en-au”, for example, d:Q44661#P144 notwithstanding)?
  • “en-nz” is probably an omission we should correct, since it is allowed as a lexeme language (unlike Scottish English or Hiberno-English, for example).
• Scots (Z1861) is one language that might fall back directly to British English (Z1199). Certainly most British speakers (the majority) will have been educated in one of the British English varieties.

GrounderUK (talk) 16:29, 22 April 2025 (UTC)

IMO once we have gone up the tree to "en", we shouldn't bother going back down to trawl through the other variants. That will almost always be a waste of time, because if one of them has a value, then the generic should already have a value. --99of9 (talk) 00:14, 24 April 2025 (UTC)

Should it? I prefer the pattern in d:Lexeme:L1347, where there is no “en” representation. But perhaps you’re just thinking about labels? I agree that there will be precious few English lexemes where both “en” and “en-gb” are missing (or both “en” and “en-us”). But there’s no harm, I think, (in the lexeme case) to returning forms other than “en”, given that the “trawl” is limited to the Lexeme and we’ll be reviewing its forms in any event. Even for labels, assuming the first language given is absent, we will have looked at all the labels before we begin fallback. That’s why Z24189 constructs a dictionary in a single pass and returns the selected Z11s from there. (There’s no optimisation for the case where a single language is requested because I doubt we’d notice the difference unless we return on first match, which is not the function’s purpose. There is some overhead associated with returning a list for each specified language, even if empty, but I’m wary of flattening the list at this stage.) GrounderUK (talk) 11:44, 24 April 2025 (UTC)

Update: We now have select representations from forms by language (Z24240): for each specified language (variant), returns monolingual text representations from the selected forms (extending “select lexeme forms from lexeme”) . I think I fixed monolingual text equality (Z14392) with a Python implementation but I’ve left Z14399 connected for now as it’s been demoted and it’s a valid implementation. GrounderUK (talk) 22:55, 24 April 2025 (UTC)

Yes I was Just speaking about Wikidata labels. I agree lexemes may want it. I'll ponder the performance and code complexity overhead. 99of9 (talk) 01:59, 25 April 2025 (UTC)

Embedded Wikifunctions calls sandbox and testing notes

As you know, we launched embedded Wikifunctions calls here and on Dagbani Wikipedia last week. We asked that you test the system out here, as we want to find bugs but also hear from you as to what you think. However, we didn't give much guidance, and we've since then had several Phabricator tasks and queries, including people trying to edit Test Wikipedia (which won't work for non-expert users, and shouldn't be used). Consequently, I felt that we should create a sandbox page for people to try it out, so I created this page.

As part of that, I felt we needed to collate all the different bits of advice, especially for this expert audience, so I created Wikifunctions:Embedded function calls with some details of what does and doesn't work right now (include some things that are far off, or will never happen).

I'd love your thoughts and comments! Jdforrester (WMF) (talk) 21:37, 23 April 2025 (UTC)

Character limit in function labels?

Hi, new contributor to Wikifunctions here!

I’m translating function labels and descriptions into French, but I’m hitting a wall. In this function, I’m trying to set the label to “distance entre deux points sur Terre en kilomètres (Haversine)”, but it get’s cut off at 50 chars (i.e.: “distance entre deux points sur Terre en kilomètres”). Is this normal? Is there a way to get past this limit?

Thanks! — Danÿa (talk) 22:31, 28 April 2025 (UTC)

It’s now a hard limit applying to all objects, I’m afraid. You can have a longer alias, however. This displays oddly but shows up in searches using words that have been abbreviated or left out of the main label. For example, select representations from forms by language (Z24240) has “filter representations from selected lexeme forms by specified languages” as its alias. GrounderUK (talk) 23:33, 28 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)

Abstract Wikipedia is a MacArthur Foundation’s 100&Change finalist

Hi all! We have some good news to share. The MacArthur Foundation has chosen Abstract Wikipedia as one of the five finalists for its 100&Change competition.

The contest, which received 869 submissions, is aimed at funding a project that can make real, measurable progress on a critical problem of our time. In our case, the MacArthur Foundation has recognized the urgency of the problem we're trying to solve together as a community—that knowledge is not readily available, or able to be equitably built, in underrepresented languages.

Being in the top 5 contestants means that Abstract Wikipedia will receive a US $1 million grant. If chosen as a winner of this year’s contest, the project will receive a US $100 million grant over the course of the next five years. Winning the grant would allow us to further prioritize together the improvements needed for Abstract Wikipedia.

The final result of the contest will be announced by the MacArthur Foundation towards the end of the year. Until then, we want to thank you for your work and your continued support of Abstract Wikipedia, because this result was reached thanks to your dedication to the project!

You can read more about this news on Diff. Sannita (WMF) (talk) 17:47, 30 April 2025 (UTC)

This section is resolved and can be archived. If you disagree, replace this template with your comment. Sannita (WMF) (talk) 13:57, 23 May 2025 (UTC)

Wikifunctions & Abstract Wikipedia Newsletter #200 is out: Abstract Wikipedia is a MacArthur 100&Change finalist

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

In this issue, we announce that we reached the final stage of a grant competition, we introduce our next big conversation about where the content of Abstract Wikipedia will be located, 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 May 5, at 17:30 UTC (link to the meeting).

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

This section is resolved and can be archived. If you disagree, replace this template with your comment. Sannita (WMF) (talk) 13:57, 23 May 2025 (UTC)

Problems with a js implementation

Tracked in Phabricator:
Task T394663

The implementation Z24188 doesn't work (it fails a testcase), and I have no idea why. Is it a Wikifunctions bug or am I doing something wrong? Dv103 (talk) 10:44, 2 May 2025 (UTC)

I didn't see anything immediately wrong, and my attempt at Z24414 also fails. There are a lot of issues with lists and timeout/errors at the moment, but it appears that my changes have triggered it to go into infinite running mode https://phabricator.wikimedia.org/T392905. --99of9 (talk) 13:13, 2 May 2025 (UTC)

@Dv103 reported as phab:T394663 for investigation. --Denny (talk) 13:04, 19 May 2025 (UTC)

Error in "is Jalali leap year"

Hi!

The correct implementation for this function should consider 4 as a leap year not 5. Otherwise the algorithm is correct. So it should be:

def Z11011(Z11011K1):
	year = int(Z11011K1)
	if(year <= 5):
		  mod = year % 4;
		  return (mod == 0);
	is_leap_year = (year % 33) in [1, 5, 9, 13, 17, 22, 26, 30]
	return is_leap_year

I didn't have permission to edit. How can I edit functions? Do I also need permission for function creation? Niyumard (talk) 12:02, 3 May 2025 (UTC)

I've just disconnected the Python implementation, so that you van edit it. An advice: create a testcase that the current implementation fails, so it's evident that there is a bug that should be corrected. Dv103 (talk) 12:05, 3 May 2025 (UTC)

I fixed the python code and added the test case that fails the JavaScript code. Can I disconnect the javascript code myself, or connect my own test cases or not, is there any guide for newbies? Niyumard (talk) 12:20, 3 May 2025 (UTC)

I've disconnected the js implementation.

Only Functioneers can connect and disconnect implementations and testcases, but everyone can create functions, testcases and implementations. This is described in the page Wikifunctions:Functioneers. Dv103 (talk) 12:26, 3 May 2025 (UTC)

I find it odd given the open nature of other wikis.

Done! And thanks a lot for your prompt reaction. Is this the correct place for asking Functioneers to connect and disconnect, or should I take my requests to some other place next time? Niyumard (talk) 12:32, 3 May 2025 (UTC)

It's mainly for security concerns (it's not wise to freely execute code uploaded by anyone). For now there is not a place specifically for requesting connections or disconnections (at least not that I am aware of), the closest page is Wikifunctions:Community portal. Dv103 (talk) 12:41, 3 May 2025 (UTC)

Makes sense. Thanks! Niyumard (talk) 12:49, 3 May 2025 (UTC)

Internal server error in running a composition

I'm getting internal server errors in all testcases for chr(Nth element of codepoint list) (Z24456). Any idea why?
Also, is there some way to translate those oblique long Z-jsons you get as actual output into a way more human-readable form, like how normal objects are viewed on Wikifunctions? Aaron Liu (talk) 15:00, 3 May 2025 (UTC)

It's a problem that arises in get the nth element of a list (Z13397) (see testcase 3rd Code point of "Hello world!" (Z24458)). I don't know why. Dv103 (talk) 15:50, 3 May 2025 (UTC)

I filed a bug phab:T394664 for further investigation. --Denny (talk) 13:10, 19 May 2025 (UTC)

Smaller natural numbers

I want to use some number codes to represent an enum of 17 possible values. I find converting to and fro BigInt—the JS representation of the natural number type—bothersome, especially when 17 is the maximum number I need. Is there a representation of numbers that's analogous to an int8 or uint8?

Speaking of which, is there a list of types somewhere? Aaron Liu (talk) 17:06, 3 May 2025 (UTC)

Diving into things more: Is really every single number on Wikifunctions represented by a String? Parsing everything from and to ints seems quite inefficient and precluding some optimization. Aaron Liu (talk) 20:32, 3 May 2025 (UTC)

The simple answer is yes, since every type expands to values of other types, with only strings and references being the terminal types. The more complete answer in at Wikifunctions:Function model. Dv103 (talk) 21:34, 3 May 2025 (UTC)

That indeed explains how it is—that there are no canonical numbers. I've tried searching for why it is, though, and haven't found anything. Aaron Liu (talk) 22:11, 3 May 2025 (UTC)

It was done for simplification. If there are no built-in numbers, there are no built-in mathematics, and it can reduce the number of built-ins considerably. --Denny (talk) 13:11, 19 May 2025 (UTC)

You don't need to introduce built-in mathematics when introducing numbers either. There's like 2 built-in implementations for String functions. Aaron Liu (talk) 17:03, 19 May 2025 (UTC)

Yes, good point. I really wanted to keep the number of built-in types low, that's the main reason. And even for numbers we had quite a few decisions to make, so I think it is good we did that in the open and together through a type proposal. --Denny (talk) 12:57, 22 May 2025 (UTC)

There is no int8 type. The complete list of types is at . Dv103 (talk) 21:37, 3 May 2025 (UTC)

Ooh, lovely! Is there a way to bump the "Wikifunctions pages" section to the top of Special:SpecialPages? I decided to look under "Lists of pages" and couldn't find that. Aaron Liu (talk) 22:06, 3 May 2025 (UTC)

There's Byte (Z80) for u8. YoshiRulz (talk) 23:19, 3 May 2025 (UTC)

Thanks. I've checked that before, though. It is exactly the same as natural number and using it here would be semantically confusing. Aaron Liu (talk) 01:32, 4 May 2025 (UTC)

Enums should be represented as enums (e.g. such as Z16098) and not as numbers, ideally. Let me know what's blocking that. --Denny (talk) 13:28, 19 May 2025 (UTC)

I don't have the permissions to create types, so that's gonna take a long time if the (absence of) responses to Wikifunctions:Type proposals/Grapheme are anything to go by. Do you think I have a shot at getting functioneer? Aaron Liu (talk) 17:03, 19 May 2025 (UTC)

Enums usually go pretty fast (unless we are waiting for the light-weight enumerations, some of the current proposals are blocked on that). Even as a functioneer, one doesn't have type creation rights, these are currently limited to staff (type creation is currently not a user-friendly process, we want to improve that before opening that up). Yes, I would assume you have a good chance at becoming functioneer. --Denny (talk) 12:59, 22 May 2025 (UTC)

Ah, makes sense. Thanks! Aaron Liu (talk) 13:32, 22 May 2025 (UTC)

Problems with evaluations: fixes are coming

Hi all, a quick update on the situation about evaluations not properly working in all cases, raised in the Telegram group. We identified the problem, and have been working in the last couple of weeks to solve it.

More specifically, you can find more info at phab:T393130 (some fixes already merged that should come up today, others will come in the next weeks), at phab:T392905 (fix already merged, should be up today), and at phab:T393152 (fix already merged, should be already up). We're also following phab:T391435 and phab:T392905.

If you have more malfunctions to report, please let me know here. Also, you can freely comment the Phab tickets to discuss directly with the engineers. Thanks for your attention! Sannita (WMF) (talk) 14:18, 7 May 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)

Fold and reduce swapped

Per my comments on Talk:Z876#Naming and WF:Catalogue/List operations#In-built functions with list outputs, I believe these functions' names are reversed from the conventional ones. Are there any FP greybeards who can confirm? YoshiRulz (talk) 05:22, 11 May 2025 (UTC)

I was involved in the construction of some of these, following suggestions from others. I have no particular expertise in the nomenclature, so may well have transmitted naming errors. Feel free to rename if others confirm your suggestion. --99of9 (talk) 12:44, 11 May 2025 (UTC)

Change to translatewiki.net-like/Miraheze-Meta-like page translation target languages

Currently, the page translation target language configuration on Wikifunctions were inherited from the "language converter page translation model".

However, this actually created several problems including the broken main page with malfunctioned language converter tags ( zh-Hans , zh-Hant , zh-Hant-HK ). More breakages could be found on phab:T328838.

As Wikifunctions haven't build up the large "tech debt", I would like to propose to use the "translatewiki page translation model"/"Miraheze Meta page translation model" instead on Wikifunctions.

This would also make the page translation target languages align with the ZObjects translation target languages.

-- Winston Sung (talk) 06:58, 13 May 2025 (UTC)

@Winston Sung: This sounds reasonable as an approach, thank you for flagging. Are there any community members here doing wikitext translation into multi-script languages who might have a view? Jdforrester (WMF) (talk) 18:46, 14 May 2025 (UTC)

Pinging @0xDeadbeef, @LowensteinYang, @MilkyDefer, @S8321414, @Stevenliuyi, @Supaplex, @星海子, @魔琴. -- Winston Sung (talk) 02:58, 15 May 2025 (UTC)

Cannot understand the technical configs and details. Just to say fixing it would be nice. 魔琴 (talk) 03:08, 15 May 2025 (UTC)

Please explain in detail about these translation models and their differences. I only see some configurations in your links and cannot grasp their differences. MilkyDefer 03:39, 15 May 2025 (UTC)

@MilkyDefer:

Below are examples of the proposed translation model.

• https://translatewiki.net/wiki/Special:Translate?group=page-Project%3AAbout&action=page&language=zh-hans&filter=
• https://translatewiki.net/wiki/Special:Translate?group=page-Project%3AAbout&action=page&language=zh-hant&filter=
• https://meta.miraheze.org/wiki/Special:Translate?group=page-Miraheze+Meta&action=page&language=zh-hans&filter=
• https://meta.miraheze.org/wiki/Special:Translate?group=page-Miraheze+Meta&action=page&language=zh-hant&filter=

Note: "translatewiki page translation model"/"Miraheze Meta page translation model" refer to the same translation model.

-- Winston Sung (talk) 03:44, 15 May 2025 (UTC)

Correct me if I am misunderstanding sth. The old configuration only has a blanket zh. The new configuration has zh-hans (for cn, my, sg), zh-hant (for tw) and zh-hk (for mo, hk). Is that right? MilkyDefer 11:49, 16 May 2025 (UTC)

That's correct for the zh/zh-* part. -- Winston Sung (talk) 11:54, 16 May 2025 (UTC)

If this issue can be fixed by changing translation model, I will  Support--S8321414 (talk) 03:53, 15 May 2025 (UTC)

Taxon rank function(s)

I understand that function suggestions usually go in Wikifunctions:Suggest a function, but I could use some feedback on this, especially since I'm unsure of what Wikifunctions is capable of currently...

I think it would be useful to have a function that, given a Wikidata item that is an instance of taxonomic rank (Q427626) (hereafter a taxon rank), e.g. species (Q7432), genus (Q34740), family (Q35409), etc., returns whether or not that taxon rank is situated at or below the rank of genus. That is, it would return true for genus, subgenus, species, subspecies, variety, and botany's series, subseries, section, and subsection, among a handful of other infraspecific ranks (or infrageneric ranks that I may be forgetting about). For efficiency, it may be worth it to hard-code a partial list of taxon ranks that are considered to be at the generic level or below, and as a fallback traverse the taxon rank hierarchy by looking at the values of part of (P361). Here's a pseudocode example.

function genericRankOrLower(taxonRank) {
    const hardcodedGen = [
        'Qxxxxx', //species
        'Qxxxxx', //subgenus
        'Qxxxxx'  //genus
    ];
    const hardcodedNonGen = [
        'Qxxxxx', //family
        'Qxxxxx', //order
        'Qxxxxx', //class
        'Qxxxxx', //phylum
        'Qxxxxx'  //kingdom
    ];
    if (hardcodedGen.contains(taxonRank)) return true;
    if (hardcodedNonGen.contains(taxonRank)) return false; // want to avoid expensive long traversals

    let nextRank = WikidataLookup.GetFirst(item: taxonRank, property: P361);
    if (nextRank != null) return genericRankOrLower(nextRank);
    return false;
}

This would be useful because the names of taxa at the genus rank and lower should be italicized, but the names of taxa above the genus rank should not; e.g. the taxon name Eristalis stipator (Q13612717) may be written as Eristalis stipator or Eristalis (Eoseristalis) stipator (the subgenus, in parentheses, is optional), while the family name Syrphidae (Q217905) is written as Syrphidae. Wikispecies and the English Wikipedia have something that can help somewhat with this, species:Template:Taxon italics/en:Template:Taxon italics, which will correctly italicize a taxon name (including cases where there are unitalicized portions, such as "var."). However, I don't believe they have a Wikidata-enabled template or module for determining if a taxon should be italicized.

In the actual use of this proposed function, there may need to be exceptions or special cases for e.g. viruses - I am unfamiliar with the italicization rules for virus names. --WrenFalcon (talk) 20:02, 15 May 2025 (UTC)

Sounds like a good function suggestion to me. --99of9 (talk) 04:34, 16 May 2025 (UTC)

Thanks. I've added a suggestion at Wikifunctions:Suggest a function#Taxon functions - feel free to move it if necessary, as I'm not entirely sure where it fits best. --WrenFalcon (talk) 23:30, 16 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)

Just wonder, that fair use is allowed here or not?

Of course it doesn't seem allowed for files, as special:upload is disabled here, but how about functions or other text-like contents? Those may also be fair use-allowed on some certain projects (e.g. several Wikiquotes), m:Non-free_content#Other_projects only suggests "A new developing project, lack of discussions on this matter yet". Any inputs? --Liuxinyu970226 (talk) 01:12, 18 May 2025 (UTC)

Code contributions are licensed under Apache 2.0, and any contributions must be compatible with that license. Fair use and code are a complicated combination, that can be crucial in some cases (for example for header declarations), but I don't think that would cover whole function implementations copied from sources that are not Apache 2.0 compatible. I am not a lawyer, and if we want a proper answer involving lawyers, we can work towards that. Why are you asking, what's the idea you're mulling over? --Denny (talk) 13:44, 19 May 2025 (UTC)

@Liuxinyu970226: I see that you are the one who added that claim to the page on meta, nearly two years ago. I don't think it's correct; non-free content has never been allowed. Jdforrester (WMF) (talk) 16:18, 19 May 2025 (UTC)

Somewhat modified, but looks still vague even for me... Liuxinyu970226 (talk) 21:46, 19 May 2025 (UTC)

Thanks for your edit! Jdforrester (WMF) (talk) 21:11, 21 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)