Wikifunctions:Project chat/Archive/2025/04

Made a small mess

I think I broke Z21862. Has anyone seen this before/know how to fix? —‍Mdaniels5757 (talk • contribs) 20:15, 3 April 2025 (UTC)

It's not your fault. Currently most of Wikifunction is broken: Wikifunctions:Status. For now simply wait until this problem is solved, without editing implementations or tests. Dv103 (talk) 20:19, 3 April 2025 (UTC)

Now it should have been solved. Tests in Z21862 are still in error because of caching. Dv103 (talk) 20:47, 3 April 2025 (UTC)

@Dv103: Yes; I edited the label of the Function which (for now) empties the cache, and the tests re-ran and worked. Jdforrester (WMF) (talk) 20:52, 3 April 2025 (UTC)

Oops, missed that. Thanks everyone! —‍Mdaniels5757 (talk • contribs) 03:05, 4 April 2025 (UTC)

This section was archived on a request by: 99of9 (talk) 11:20, 19 April 2025 (UTC)

Joining empty string?

Hi, it's very late for me so I might just be incredibly tired. I just created a function to return the century a given year is in here. I added a couple tests that seem to be failing. However, the expected and actual strings look the same to me so I think there might be something wrong with concatenating empty strings? At least, that's my first instinct since I have no clue what's actually happening internally. I could be missing something obvious because I'm very sleep deprived. Moon motif (talk) 09:16, 24 April 2025 (UTC)

It's because you are joining strings with space as a separator. In AD years, it adds an empty space at the end Dv103 (talk) 09:23, 24 April 2025 (UTC)

Oh my god, I have no idea why I didn't notice the extra white space. I wish my motivation to write functions didn't happen so late haha. Thank you so much! Moon motif (talk) 15:14, 24 April 2025 (UTC)

This section was archived on a request by: Dv103 (talk) 15:24, 24 April 2025 (UTC)

Wikifunctions & Abstract Wikipedia Newsletter #196 is out: Quarterly Planning for April–June 2025; We are looking for a Senior Product Manager

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

In this issue, we present our work plan for the upcoming quarter (April-June 2025), we publish a new job opening for joining the team, 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 April 7, at 17:30 UTC (link to the meeting).

Enjoy the reading! -- User:Sannita (WMF) (talk) 14:22, 6 April 2025 (UTC)

The recording of yesterday's Volunteers' Corner is now available on Commons. Enjoy! Sannita (WMF) (talk) 11:15, 8 April 2025 (UTC)

This section was archived on a request by: Sannita (WMF) (talk) 10:38, 5 May 2025 (UTC)

Wikifunctions & Abstract Wikipedia Newsletter #197 is out: Quarter in review, and lots of material to watch

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

In this issue, we evaluate our work done for the recently closed quarter (January-March 2025), we present you a number of video and blogpost about us to watch and read, and we take a look at the latest software developments.

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

Also we remind you that the next Natural Language Generation Special Interest Group meeting will be held on April 15, at 16:00 UTC (link to the meeting).

Enjoy the reading! -- User:Sannita (WMF) (talk) 11:20, 11 April 2025 (UTC)

This section was archived on a request by: Sannita (WMF) (talk) 10:38, 5 May 2025 (UTC)

Wikifunctions & Abstract Wikipedia Newsletter #198 is out: Wikifunctions integrated in Dagbani - and Wikifunctions; and the date of Easter

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

In this issue, we announce that this week we switched on the ability to call Wikifunctions functions from within Dagbani Wikipedia (our first wiki to do so!), we discuss the functions related to calculating the dates of Easter, 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:29, 17 April 2025 (UTC)

This section was archived on a request by: Sannita (WMF) (talk) 10:38, 5 May 2025 (UTC)

Wikifunctions & Abstract Wikipedia Newsletter #199 is out: Welcome, Gregory!

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

In this issue, we present a new member of the team, 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) 13:16, 28 April 2025 (UTC)

This section was archived on a request by: Sannita (WMF) (talk) 10:38, 5 May 2025 (UTC)

Having problems

Hi!

I submitted three-dimensional perlin noise, with an implementation. However, it says "Status: Disconnected". It's not at all clear what this means. After some searching, I discovered that only "functioneers" can "connect" an implementation. (Maybe we should make this easier to find?) After looking at the page history for the function, I saw that the implementation was "added" and then quickly "removed", with no reasoning or explanation.

I thought maybe the reason it was removed is because the function has no tests. So I created a test. It failed with an "unspecified error", and the error contains (along with a wall of impenetrable Z-ids) "cannot convert to bigint". I don't know why (or what) it's trying to convert to a "bigint" because the output is supposed to be a float64.

Can anyone help me? Sillypantscoder (talk) 23:54, 5 April 2025 (UTC)

It is probably because you tried to sum regular js Numbers with BigInts inside the code (js doesn't permit you to do this). Note also that input parameters, of type Z16683, are automatically converted to BigInts before being passed to your function.

As the error infobox suggests, you can always use Wikifunctions.Debug to print debug logs.

I hope I this is helpful. Dv103 (talk) 06:41, 6 April 2025 (UTC)

I tried adding Wikifunctions.Debug. When I was saving the function, it warned me to not use this function, which is odd because I seem to be unable to run the function without saving it first.

After this change, the test gave me an "Invalid executor response" with no other information. Sillypantscoder (talk) 21:40, 6 April 2025 (UTC)

I've fixed the debugs, so they are now showing up in the output. (BigInts needed to be converted to strings, because Debug only prints strings). Now the error is "cannot convert to bigint". This is because all of the inputs are bigints, but all of the numbers in the code are regular integers. --99of9 (talk) 00:35, 7 April 2025 (UTC)

I figured out the problem with the function, thank you!

One other thing, though-- When I was editing the function, it tried to show me whether the test had passed. But it always reported "failed", and when I clicked the "details" button it said "Unable to run tests. Please reload." This message persisted after reloading. Do you know why this could happen? Sillypantscoder (talk) 03:06, 7 April 2025 (UTC)

Yes, this is reasonably common when the tests are all being rerun. If you wait long enough (~10sec * number_of_tests * number_of_implementations) before refreshing, it will almost always be done by then. --99of9 (talk) 05:14, 7 April 2025 (UTC)

For the function, can I suggest that you add the size of the system as a parameter. The way you have it, it must always use the hardcoded default size of 35. 99of9 (talk) 05:15, 7 April 2025 (UTC)

MonoBook search

Are there any plans to implement the new search functionality in the MonoBook skin? I'm aware that the status update explicitly stated that this cannot be done:

Note that this search tool is only available in the Vector-2022 skin; in the legacy experiences, you will have the old search experience, as those unfortunately can't be extended but only replaced.

However, I notice that Wikidata has custom search functionality on the MonoBook skin that I so far haven't had any major issues with. Could a similar approach be applied to getting better object search working on MonoBook for this wiki? If Wikidata could, I don't see how Wikifunctions couldn't (potential difficulty notwithstanding). — rae^5e <talk> 16:14, 9 April 2025 (UTC)

@Theki: I fear you're being rather optimistic about how much work this would. We for Wikifunctions aren't providing a search tool (which has been subject to huge amounts of design, development, testing, and validation). We just plug in a search API into that. The search tool is provided by the skin. As I understand it, the "new" (2020) search system used by Vector 2022 and other skins can't integrate with legacy skins like MonoBook or Vector 2010 without breaking lots of existing gadgets/etc., and the consensus in community conversations was that people didn't want that. Consequently, people using those legacy, unsupported experiences can't get the new search system. (By way of context, remember that legacy skins like Vector 2010 and MonoBook haven't been supported with new features for many years now.)

Wikidata does indeed have a hack that over-writes the legacy search system. It is also unsupported, and breaks several things; I believe that there have been conversations between the Wikidata and Web teams about building a system that could support their needs for a few years, but so far nothing solid has happened. If that were to happen, we could possibly integrate with it too, but we certainly aren't going to break things for Wikifunctions by bodging in a replacement, especially not for the MonoBook skin. If you want to write a user script to hack your experience, you can, but I don't think we can at all justify spending effort to support a handful of people who don't use the current tools. Jdforrester (WMF) (talk) 20:02, 16 April 2025 (UTC)

That is perfectly understandable. I had assumed that I am one of only a small portion of editors using the legacy appearances and as such any effort put into supporting those would be disproportionate to the amount of use that it could potentially have for its now small userbase. A userscript could work for this, but Special:Search has always been effective for me regardless of its occasional impracticality. If I had to do anything to get improved search to work on MonoBook I'd likely just write a custom userstyle that makes Vector 2022 look as close to MonoBook as possible (if one doesn't exist already). I do hope that the Wikidata folk come to a solution eventually but this and other compatibility issues don't irk me to the point where I'd want to switch. Thank you for the explanation and I apologize for any hassle. — rae^5e <talk> 20:17, 16 April 2025 (UTC)

@Theki: No hassle at all, and thank you for being understanding. I hope we can soon give you a great experience even in MonoBook, in this and everything else. Jdforrester (WMF) (talk) 20:20, 16 April 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)

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)

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)

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 was archived on a request by: Sannita (WMF) (talk) 13:57, 23 May 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 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: 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 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)

This section was archived on a request by: 99of9 (talk) 02:03, 11 June 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 (28950),
• {{NUMBEROFFUNCTIONS}}, the number of Functions (4793),
• {{NUMBEROFIMPLEMENTATIONS}}, the number of Implementations (8321),
• {{NUMBEROFTESTCASES}}, the number of Test cases (14168),
• {{NUMBEROFTYPES}}, the number of Types (75), and
• {{NUMBEROFLANGUAGES}}, the number of (natural) languages (1048).

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

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

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

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

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

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

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

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

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

proposed Display function for Gregorian calendar month Type

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

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

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

Tracked in Phabricator:
Task T394769

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

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

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

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

This section was archived on a request by: 99of9 (talk) 06:39, 25 June 2025 (UTC)