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/10 2023/11 2023/12 2024/01 2024/02 2024/03 2024/04 2024/05 2024/06 2024/07 2024/08 2024/09 2024/10 2024/11 2024/12 2025/01 2025/02 2025/03 2025/04 2025/05 2025/06 2025/07 2025/08 2025/09 2025/10

Wikilinks in HTML fragments

In Wikitext, Wikilinks are automatically generated, and the parser automatically checks whether the link is valid, and colors the link accordingly. Considering that Wikifunctions functions have to directly output HTML fragments, how should they output Wikilinks? Dv103 (talk) 12:05, 8 September 2025 (UTC)

A question for @Jdforrester (WMF), I think. GrounderUK (talk) 09:24, 4 October 2025 (UTC)

@Dv103: You should output an <a href="…">…</a> contents in the HTML fragment and it should Just Work™, with some (strong) restrictions. Jdforrester (WMF) (talk) 19:44, 7 October 2025 (UTC)

Technical issues: Community process

Here are some initial thoughts about how Wikifunctions community members might best respond in the event of a technical issue. It is intended to supplement the guidance to be found at Wikifunctions:Report a technical problem.

If anything appears not to be working, please tell someone!

• For the quickest response, try the main chat on Telegram or IRC #wikipedia-abstract^connect(bridged together).
• Alternatively, add a task to Tasks listed by users and a community member will take it from there.
• You can file a new task on Phabricator, but we encourage you to discuss it first or, at least, to indicate that you intend to file it.

[whether and how to alert WMF staff?] GrounderUK (talk) 17:56, 17 September 2025 (UTC)

@Sannita (WMF) I avoided pinging you earlier, but do we need to discuss the bracketed question « [whether and how to alert WMF staff?] » ? GrounderUK (talk) 09:15, 4 October 2025 (UTC)

@GrounderUK Sure, do we want to have a quick chat at the Volunteers' Corner later today? Or do we want to keep it here? Sannita (WMF) (talk) 11:06, 6 October 2025 (UTC)

Sorry, @Sannita (WMF), Monday evenings are never a good time for me. Comments here would be welcome, particularly if you are happy to put yourself forward as the person to contact when we think the issue warrants it. GrounderUK (talk) 09:56, 9 October 2025 (UTC)

@GrounderUK: Is it worth distinguishing between "something is urgently wrong" issues (like the above) vs. "I think this feature should work differently/exist"? The "we encourage you to discuss it first" wording seems aimed at the latter, to try to ensure that people have general community agreement before lots of work is done, I think? Jdforrester (WMF) (talk) 22:51, 8 October 2025 (UTC)

It’s a thought, @Jdforrester (WMF), but it’s not a distinction I’m inclined to make. Discussion may well be limited in the case of an apparently serious issue but the “at least” alternative is intended to cover the case where there is no constructive response. The intention is to avoid duplicate or incomplete tickets in the case where the problem becomes apparent in different ways to “many” users at the same time, or when the problem is already well understood. GrounderUK (talk) 10:08, 9 October 2025 (UTC)

@GrounderUK: Understood. I'd worry more about delays in highlighting issues than duplicate/confusing tickets, but it's a minor concern. Generally, I think this is good guidance, yes. Jdforrester (WMF) (talk) 15:20, 9 October 2025 (UTC)

Understandable. Forty minutes after my reply, we had an alert on Telegram. Twenty minutes later, I pinged @Sannita (WMF). The first mention on Phabricator was less than fifteen minutes after the first alert and the eventual ticket was raised within forty minutes. I would say this was reasonable, but I don’t know what we should do when Europe is asleep or, more generally, when Sannita is unavailable. GrounderUK (talk) 14:59, 14 October 2025 (UTC)

Language specific decimal separator

At the main page the decimal separator for the number of functions is,. In Germany usually a . is used as the decimal separator if something is grouped in thousands. It depends on the topic and the region. Is it possible to change the function to get another decimal separator depending on the language the page is displayed in. Hogü-456 (talk) 21:00, 6 October 2025 (UTC)

It's displayed with the formatnum magic word. YoshiRulz (talk) 05:02, 7 October 2025 (UTC)

But for some reason it doesn't work. Dv103 (talk) 07:02, 7 October 2025 (UTC)

@Hogü-456: If I go to Template:Main page/de I see:

Die freie Bibliothek von 3.147 Funktionen, die jeder bearbeiten kann.

However, if I go to Wikifunctions:Main_Page?uselang=de indeed it does not seem to work:

Die freie Bibliothek von 3,140 Funktionen, die jeder bearbeiten kann.

Most odd! Perhaps the Lua redirect code is breaking the language setting? Jdforrester (WMF) (talk) 18:15, 7 October 2025 (UTC)

JavaScript converter functions for Wikidata time (Z6064)

I recently created JavaScript converter functions for Wikidata time, but will do more testing before connecting. I aim to get them connected by early next week. In the meantime, please feel free to have a look and give feedback. I don't think there's anything risky or controversial in these functions.

• Convert from Wikidata time, JavaScript (Z28686)
• Convert to Wikidata time, JavaScript (Z28687)

Notes:

• I copied JavaScript converter code from Gregorian calendar date, Time of day, Natural number, and Integer. Of course, we have a maintenance burden resulting from multiple copies of converter code snippets. There are some ideas afoot about allowing for one converter function to call another converter function, but we aren't there yet.
• When we have a distinct type for Julian calendar date, it will make sense to revisit these converters to make sure Julian dates are handled correctly. DMartin (WMF) (talk) 00:41, 9 October 2025 (UTC)

Okay, these JavaScript converter functions are connected now, and I've used them successfully in implementing a new function Later Wikidata time (Z28846). DMartin (WMF) (talk) 18:21, 15 October 2025 (UTC)

Where do I test?

I'm working on fixing this duplicate script and I would like to test on a beta or test wiki to avoid creating garbage entities here. Is one available? So9q (talk) 18:05, 9 October 2025 (UTC)

I am afraid there is currently no test or beta WikiLambda instance running, I am afraid. --DVrandecic (WMF) (talk) 17:06, 13 October 2025 (UTC)

Statistics for usage of functions from Wikifunctions

I would like to know how the usage pattern for embedded function calls looks in Wikifunctions (from any connected wiki). Are there any plans to make data available about that? So9q (talk) 20:23, 9 October 2025 (UTC)

Rules for other languages (inside or outside functions)

I have written a function name and lifespan from Wikidata item (Z28748) which returns the name and lifetime dates of a Wikidata person, for a specific language. Looking at the Wikipedia disambiguation pages (which is an obvious use case of such a function), the output corresponds at least to European languages I can read.

English - Albert Einstein (1879–1955)
French - Albert Einstein (1879–1955)
German - Albert Einstein (1879–1955)

For people who are still alive, each Wikipedia has its own conventions. I presume this is a mixture of Wikipedia rules and language-specifc conventions?

English - Elon Musk (born 1971)
French - Elon Musk (né en 1971)
German - Elon Musk (* 1971)
Spanish - Elon Musk (1971)

The function as it stands, inserts the word "born" following the English rule. My question is: how far should the language-specific features go? Can we call a function to translate the word "born"? Should we use the German rule which has no words? Or should the function just output "Elon Musk (1971-)" which is more language-neutral? Or have a gigantic switch statement for every form?

I am not sure how a wiki project like Wikipedia will use our functions, as clearly they would need to add their own features, or accept our output "as is"? GrimRob (talk) 11:45, 11 October 2025 (UTC)

These are good and fairly tricky questions. We are only just beginning to formulate guidance at Wikifunctions talk:Abstract Wikipedia/2025 fragment experiments. The general practice is that fragments should map from a top-level all-language function to language-specific ones, but there are exceptions like Z26039 composition via config to entity and class (Z26045), where a “language-neutral” option is available (and might reasonably be a preferable default to the English-language function currently specified in article-less instantiating sentences per language (Z26043)).

Your final question has been troubling me for some time but the current answer is “yes”. I believe it is only a matter of time before explicit configuration options are made available, but these are currently baked into the selected function, varying only by language. GrounderUK (talk) 13:33, 11 October 2025 (UTC)

+1 to everything GrounderUK said. I tried my hand at figuring out a pattern myself, following the advice on the discussions for fragment experiments. I tried it with short descriptions for albums:

• here is the top-level all language function: short description for album (Z28803)
• this is then being dispatched based on language, e.g. to English or German, where each language can do as much configuration as they want (e.g. I was considering dropping the year from the German one, because in German Wikidata short descriptions for albums they rarely use them)
• finally, there is a language-independent default trying its best (which is indeed calling a function to get the word for "album" in this case): default short description for albums (Z28797)

The dispatch in the implementation of the top-level function using a configuration is basically the huge switch statement you mentioned.

So, if a language edition wants a different output, they have at least two places to do so: by adding their language-specific function (as we have now for English and German in the given example), or by overriding it locally in their own Wikipedia language edition.

These are just thoughts. --Denny (talk) 17:30, 13 October 2025 (UTC)

Thanks. That works well. It helps that "album" is a noun and also an item with a wikidata entry. In my case (which is just my own poc) I am using the word "born" which is the past tense of a verb, and doesn't have a wikidata item (although I suppose it could). Is there a function that can translate a word like "born", I did have a look, but couldn't see one?

I guess you could also have multiple versions of the function. You could get around it by just using a version without words as the Elon Musk (1971-) which would work in most languages (I presume). There are options as you say but the number of functions could soon grow to be vast if there is a lot of customisation. GrimRob (talk) 18:05, 13 October 2025 (UTC)

To represent born you would need a specific all-level function and customized language specific functions below it and that seems a bit excessive when there is a reasonably wide understood syntax as you mentioned which probably doesn't need to be translated. And if it does, it requires a lot less work. So9q (talk) 19:50, 13 October 2025 (UTC)

Yes, with "album" it was lucky. But I think you are asking the right question: how would we get "born"?

So, looking at Wikidata, we find a verb born and an adjective born, which both might be off (or maybe not? Is the adjective maybe correct?)? I think, what we are looking for is the past participle of the verb bear, i.e. L1172-F5. Unfortunately, none of the senses of this Lexeme (nor of the other two mentioned) are in any way connected to the item for birth. I would expect probably a predicate for or maybe a item for this sense connecting the sense with birth. If I look for Lexemes connected to that item, I find them in Chinese, Japanese, Malay, Dagbani, and Seejiq Truku. It could be that these could be used, but I have no idea about these languages.

I think that in some Indoeuropean languages it could work to take the past participle of the verb that is a predicate for birth. If we had more comprehensive data, we could write and test that function right away. We would need to figure out what the right approach in other languages is. I hope that this should be possible right now, though, working language through language. Alternatively we can just "hardcode it" per language, but I think it is worthwhile to find someone in the given languages, as this is likely a problem that we will keep encountering, and it could be worthwhile to start to build out patterns to solve such issues.

I do agree with So9q that it is less work for the alternative representation that seems widely understood. But I also think you opened an interesting question here :) --Denny (talk) 10:34, 14 October 2025 (UTC)

Thanks all for the comments. I wanted to see if Wikifunctions could produce something that looked exactly like the disambiguation pages so it could seemlessly slot in place. Quite often information is duplicated like dates is duplicated within a single Wikipedia in different forms, and people only change one. I guess compromises are going to have to made in cases like this just to reduce the burden of writing extra code. If I think of something similar I'll try and see how it would work again. GrimRob (talk) 11:17, 14 October 2025 (UTC)

In this context, “born” is a participle, like “published”, “released”, “founded” etc. Linguistically, it could equally well be “born in” or “who was born in”. Conceptually, what we’re looking for here is “property for this sense” or, more generally, “concept for this property” (an item value in a statement for the Wikidata property) targeted by item for this sense (P5137) GrounderUK (talk) 12:35, 14 October 2025 (UTC)

Drop the AD from years after 1000

Since the individual talk pages don't get much traffic, I wanted to point to a question for the English display function for years: I suggest to drop the AD from years after 1000, which seems to correspond more to common usage. --Denny (talk) 17:38, 13 October 2025 (UTC)

I'm fine with switching the English display. But let's retain the full current one as a separate function and just call the one we want. 99of9 (talk) 01:08, 14 October 2025 (UTC)

Oh, that's a great point! Totally agree, and really in the spirit of how Wikifunctions is supposed to work. Thanks for the suggestion! --Denny (talk) 05:45, 14 October 2025 (UTC)

Created display year in English without AD after 99 AD (Z28824) as the new English display function for Gregorian year. --Denny (talk) 07:13, 14 October 2025 (UTC)

I thought you were suggesting 1000 as the cutoff? I don't mind too much, but small three digit numbers don't feel like dates to me without the era. --99of9 (talk) 12:51, 14 October 2025 (UTC)

I was initially, but @GrounderUK in discussion on the talk page pointed to the enwiki Manual of Style, which suggests 100 AD as the cut off. I am happy either way, but I thought it is a good idea to follow the MoS. --Denny (talk) 14:53, 14 October 2025 (UTC)

Just to clarify, that guidance is in the absence of context. We can handle ranges in a separate function, but a standalone date would be expected to follow the convention established for the article, including the choice between BC/AD and BCE/CE and (only by inference) the placement of AD before or after a year. I think the same range of options exist in many other languages.

Thinking within existing constraints, I think we would have to have two separate embedded function calls to deliver the correct convention for a particular context, but that would require that the Gregorian year display function suppress the era in all cases.

(There’s no such issue on Wikifunctions, because we can wrap the function call in any appropriate display function, but a standard Gregorian year result will look odd in collapsed form if it simply omits the era.) GrounderUK (talk) 15:34, 14 October 2025 (UTC)

Thanks, @Denny. I'm now using the new function in Year-specific sentence from statement (Z28436) ; Like it much better. DMartin (WMF) (talk) 00:48, 21 October 2025 (UTC)

In fact, @GrimRob's work above is just another case in point: I am sure they used natural number to digit string (Z13713) and Gregorian year to year number (Z20160) instead of Gregorian year as string (English) (Z20192) for exactly that reason. I had similar issues for short description for album (Z28803) and @DMartin (WMF) with Year-specific sentence from statement (Z28436) --Denny (talk) 05:45, 14 October 2025 (UTC)

I had the same problem in drop era for later dates, Composition (Z28815). It goes back to #Rules for other languages (inside or outside functions). A year can be displayed with or without the era in most or all languages, so Gregorian year (Z20159) needs a choice of display functions.

For now, only one function can be the primary display function (declared in the type), so this should just implement the switch. We may expect a large number of languages to follow the default path, as the function switched to should be a proper display function, with its own separate Configuration of functions for given languages (Z14294).

In practice, this probably means that display Gregorian year (Z20241) should be demoted to the default display for a new primary display function. Alternatively, we could configure the new display function to switch to the current one for languages present in display functions for Gregorian year (Z20240), except where they have a “conditionally era-less” rule implemented (like English).

There’s another migration pathway linked to re-using the existing configuration, but I’m confused enough already!

In any event, I think we need a configured function for displaying an era-less year, so that languages can display year numbers differently from the corresponding Natural number (Z13518). This function would replace display natural number (Z14280) in display simplified Gregorian year, Composition (Z28822), unless we come up with a better plan. GrounderUK (talk) 09:51, 14 October 2025 (UTC)

Chinese translation for project name

[en] English:

The Chinese-speaking community hasn't decided on the translation of "Wikifunctions." It's about time we translate this. I propose the name "维基函数"(zh-Hans)/"維基函數"(zh-hant).

Note that Taiwan seems to prefer "函式/函式" when it comes to programming functions, but considering

1. It will be disastrous to convert regional terms in our project names,
2. Taiwanese also use "函数/函數," and
3. Math functions are universally called "函数/函數,"

I'd choose not to split the translation.

I hope other Sinitic languages (Chinese topolects) choose to follow this translation, except for those conventionally preserve the original foreign names. Also, Classical Chinese might consider another name.

---

[zh-Hans] 中文（简体）:

中文社群尚未决定“Wikifunctions”的翻译，是时候译了。我提议“维基函数”(zh-Hans)/“維基函數”(zh-hant)。

需要注意，台湾似乎更倾向用“函式/函式”来翻译程序/程式的function，但考虑到

1. 项目/专案名称中使用地区词很糟糕
2. 台湾也使用“函数/函數”
3. 数学上的function普遍译为“函数/函數”

我倾向于不去分裂这个译名。

我希望其他汉语族语言（汉语方言）也能采用这个译名，除了一贯保留原文者。此外，文言文可能会考虑另行翻译。

---

[zh-Hant] 中文（繁體）：

中文社羣尚未決定「Wikifunctions」的翻譯，是時候譯了。我提議「维基函数」(zh-Hans)/「維基函數」(zh-hant)。

需要注意，臺灣似乎更傾向用「函式/函式」來翻譯程序/程式的function，但考慮到

1. 項目/專案名稱中使用地區詞很糟糕
2. 臺灣也使用「函数/函數」
3. 數學function普遍譯爲「函数/函數」

我傾向於不去分裂這個譯名。

我希望其他漢語族語言（漢語方言）也能採用這個譯名，除了一貫保留原文者。此外，文言文可能會考慮另行翻譯。

---

-- 魔琴 (talk) 13:14, 14 October 2025 (UTC)

"維基函數" shall be fine. Have you notify other zh wikis and translatewiki.net about this? Ericliu1912 (talk) 21:59, 14 October 2025 (UTC)

已通知：zhwiki, zh_classicalwiki (lzhwiki), ganwiki, wuuwiki, hakwiki, zh_min_nanwiki (nanwiki), cdowiki, zh_yuewiki (yuewiki), zhwikibooks, zhwikinews, zhwikiquote, zhwikisource, zhwikiversity, zhwikivoyage, zhwiktionary, yuewiktionary, zh_min_nanwiktionary (nanwiktionary), zh_min_nanwikisource (nanwikisource)。

已通知 translatewiki.net portal：zh, lzh, nan, yue。

-- 魔琴 (talk) 00:04, 18 October 2025 (UTC)

Winston mentioned in Telegram @wikifunctions_zh that the current zh-Hant translation pages use "维基函式库," probably since Wikifunctions is a library and "functions" is plural. Winston在Telegram@wikifunctions_zh說，現行繁體翻譯是「維基函式庫」，可能因爲Wikifunctions是庫，而且「functions」是複數。--魔琴 (talk) 03:51, 15 October 2025 (UTC)

Sounds as if someone is saying that because Wikidata is a database, we should add the character "库" when translating its Chinese name. In my view, that would be superfluous—like drawing a snake and then adding feet. PexEric (talk) 08:47, 16 October 2025 (UTC)

翻譯：聽起來像是說維基數據是數據庫，所以我們翻譯的時候應該加「庫」字。我認爲這是畫蛇添足。--譯者：魔琴 (talk) 00:08, 18 October 2025 (UTC)

「维基功能库」行吗（大家都不常用，而且语言的陌生化）🤔 --For Each ... Next (talk) 11:03, 20 October 2025 (UTC)

功能怪怪的，而且感覺偏離了wikifunctions的用途了。 SunAfterRain 05:15, 21 October 2025 (UTC)

Support. A unified and clear translation. PexEric (talk) 08:42, 16 October 2025 (UTC)

我仍然認為zh-Hant應翻譯為維基函式，對我來說，維基函數在這個狀況只算是退而求其次的選擇。--S8321414 (talk) 00:40, 18 October 2025 (UTC)

Translating Wikifunctions as 「維基函數」 is not accurate. en:Wikifunctions says: "Wikifunctions is a collaboratively edited catalog of computer functions to enable the creation, modification, and reuse of source code." Here, "functions" refers to en:Function (computer programming), which Chinese Wikipedia translates as 「子程序」 and Cantonese Wikipedia translates as 「子程式」, and not to en:Function (mathematics). Therefore, it is recommended that Wikifunctions should use the Chinese name 「維基子程序」 and the Cantonese name 「維基子程式」. Kwgulden (talk) 02:47, 18 October 2025 (UTC)

「子程序」or「子程式」means "subroutine, subprogram or callable unit" and a function is just a type of it. PexEric (talk) 02:55, 18 October 2025 (UTC)

Thanks for your explanation. That means the sitelinks in d:Q190686 may not be accurate. But I am still not sure whether it is appropriate to refer 「函數」 to en:Function (computer programming) as 「函數」 usually refers to en:Function (mathematics). Kwgulden (talk) 03:09, 18 October 2025 (UTC)

計算機的function應該得名自數學的function吧，感覺除非大家跟着臺灣用「函式」，不然沒招。 魔琴 (talk) 13:05, 20 October 2025 (UTC)

FYI: @WhitePhosphorus多年之前的留言 m:Talk:Abstract_Wikipedia/zh#译名. 维基函数这个名字可以的。Stang 08:12, 19 October 2025 (UTC)

I vaguely remember an earlier decision to not translate it.. MilkyDefer 11:11, 19 October 2025 (UTC)

维基百科的姊妹项目没有一个不翻译的，保留原文不太符合社群习惯。我猜很多中文用户在当年的定名票选中反对Wikilambda这个名字。 魔琴 (talk) 20:31, 24 October 2025 (UTC)

另外，這裏建議在新名稱確定之前，將「Abstract Wikipedia」暫譯爲「抽象維基百科」。-- 魔琴 (talk) 13:02, 20 October 2025 (UTC)

Agree. Ericliu1912 (talk) 16:05, 22 October 2025 (UTC)

Agree. ~ Sheminghui.WU (talk) 23:55, 23 October 2025 (UTC)

I think Literary Chinese could be translated into '維基函數'. --WAN233 (talk) 01:54, 22 October 2025 (UTC)

As a user who is actively involved in editing the Mindong (Eastern Min) edition of Wikipedia, I believe the term "函數" (hàng-só) is sufficient to convey the meaning of "function."

At the same time, as a Chinese speaker, I want to remind everyone that for many people, just seeing the word "函數" isn't enough to understand what this feature or website is for. They might mistake it for something related to teaching math, as if the Wikimedia Foundation is planning to enter the educational/tutoring industry.

Names like "維基百科" (Wikipedia) and "維基辭典" (Wiktionary) are excellent translations; you immediately know what they do when you hear them, and these products have had a profound impact on the internet over the last two decades.

I suggest that, rather than getting bogged down in the technical accuracy of computer terminology or issues of linguistic identity and regional preferences, we should rethink this from a product and branding perspective. We need to find a translation that makes its purpose clear to people. The goal should be to settle on a name that is easily understood by the contemporary Chinese-speaking world (中文語境 / 華人世界 or at least 華語圈). Davidzdh (talk) 09:44, 26 October 2025 (UTC)

Function to get the Dropdownselection

I want to write an additional composition to derive the correct article of a noun in German. It is a composition Z28949. There is already one composition with many If-Functions and one what takes the information from Wikidata . As an alternative I want to make a function based on a decision table where all options are present. I got an answer in the Telegramchannel how to do it and it did not work. As it seems to me it was because of the user interface. I was not able to enter the concatenate function again after removing the functions I entered so far. I entered the ZID and the function name and both did not work. The function has not been found. Can you please help me by editing the composition so it gives a string as an output. The string should contain all four function arguments concatenated as a string. Have you also experienced errors with the search. Hogü-456 (talk) 20:47, 21 October 2025 (UTC)

an implementation not of this function, sorry (Z28949): # as requested in Project chat I don’t know how you plan to implement the decision table, so I’m flagging this as an implementation of a different function.

You have revealed an odd usability issue. I couldn’t find a way to get back to a normal structure without resetting the implementation. I think it’s a known issue but I haven’t tracked down the ticket yet.

The search is context-sensitive. I don’t know what behaviour you experienced, but a persistent failure to find a function is generally because its Z8K2/return type is not compatible with the context. For example, if you’re using a string concatenation function like join list of strings with delimiter (Z12899) and you choose to specify an element as a function call, the search will not include Get Wikidata reference from enum instance (Z6895), because that function does not return a string. GrounderUK (talk) 22:42, 21 October 2025 (UTC)

Thank you for the function. It helps me to understand better how to write a function. Paying attention to types can be difficult. In Spreadsheets where I write a lot of function I experience usually an error by different types and afterwards I change the function input by converting it. So maybe it is possible to implement some kind of automatically type conversion in Wikifunctions. At least for how I am used to from implementing Functions in Spreadsheets it makes it easier to use. Hogü-456 (talk) 19:46, 23 October 2025 (UTC)

Content attribution

I want to use existing implementations in Java Script and combine them in one new function to have an alternative to a composition. At the moment I think this can help people to reuse the functions offline. How do I have to make the attribution when copying the parts of functions and combine them together to a new one. In some cases there is propably not enough to have a copyright on it and in other cases it is necessary as code is under the Apache License 2.0. Hogü-456 (talk) 19:11, 24 October 2025 (UTC)

If you're saying it could go either way depending on what you're doing, then it seems to me that only you can make that call in each individual case. What kind of an answer are you looking for here? - dcljr (talk) 06:30, 25 October 2025 (UTC)

I want to understand where I have to write down where the code comes from. Is it enough to write it in the edit summary or do I have to add a comment in the function. Hogü-456 (talk) 15:22, 26 October 2025 (UTC)

The Apache 2.0 license stipulates:

“4. Redistribution. You may reproduce and distribute copies of the Work or Derivative Works thereof in any medium, with or without modifications, and in Source or Object form, provided that You meet the following conditions:

a. You must give any other recipients of the Work or Derivative Works a copy of this License; and

b. You must cause any modified files to carry prominent notices stating that You changed the files; and

c. You must retain, in the Source form of any Derivative Works that You distribute, all copyright, patent, trademark, and attribution notices from the Source form of the Work, excluding those notices that do not pertain to any part of the Derivative Works; and

d. If the Work includes a "NOTICE" text file as part of its distribution, then any Derivative Works that You distribute must include a readable copy of the attribution notices contained within such NOTICE file, excluding those notices that do not pertain to any part of the Derivative Works, in at least one of the following places: within a NOTICE text file distributed as part of the Derivative Works; within the Source form or documentation, if provided along with the Derivative Works; or, within a display generated by the Derivative Works, if and wherever such third-party notices normally appear. The contents of the NOTICE file are for informational purposes only and do not modify the License. You may add Your own attribution notices within Derivative Works that You distribute, alongside or as an addendum to the NOTICE text from the Work, provided that such additional attribution notices cannot be construed as modifying the License.”

From c, I infer that you have to retain in your source code whatever notices are within the licensed source code. Beyond that, I’m not inclined to speculate in general terms, but please note the APPENDIX at the end of the license

Please remember that licence compliance remains each contributor’s personal responsibility. GrounderUK (talk) 17:29, 26 October 2025 (UTC)

Producing comma-delimited list of Wikidata labels

I am trying to produce am comma-delimited list Z12899 of labels for the child items which belong to a wikidata item (e.g. authors of a book).

I am using Z22978 to get some Wikidata item statements and I want to basically take the label for them for a language and concatentate the labels in a string. The first part is easy and the last part is easy. The bit in the middle is hard. I can concatenate the QIDs using the Map function Z873 but I need to pass a second argument of language so going from a QID to a Label inside an iterator I am struggling with.

No code to show I have been using UI but here's a screenshot as it's the easiest way to explain:

File:20251029170615!chunkedupload 8e11b7aeb317.png

GrimRob (talk) 17:08, 29 October 2025 (UTC)

https://i.ibb.co/LhrDHQTh/Z13318.png GrimRob (talk) 17:11, 29 October 2025 (UTC)

I think you might be looking for something like labels for some Wikidata items (in one language) (Z26929). The list of QIDs as the first argument had better be short until we get phab:T382921; until then you will be fetching the whole Wikidata item for each of the authors, so timeouts are a risk. GrounderUK (talk) 19:28, 29 October 2025 (UTC)

Thanks, that looks like it will work. It's a lot less calls than what I was trying so hopefully should be quick as most books have 1 author and few have more than 2. GrimRob (talk) 19:56, 29 October 2025 (UTC)

Yes, I’ve since tried a few prolific authors in the same list and the performance is still acceptable. GrounderUK (talk) 20:27, 29 October 2025 (UTC)

Wikifunctions & Abstract Wikipedia Newsletter #224 is out: Round 1 of “abstract content wiki” naming vote ending Monday; An example of short descriptions

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

In this issue, we update you on our naming contest for Abstract Wikipedia, we announce our first experimentation with short descriptions on Wikidata, we talk about our presentations at the upcoming WikidataCon 2025, and we take a look at the latest Type and 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 November 3, at 18:30 UTC (link to the meeting).

Enjoy the reading! -- User:Sannita (WMF) (talk) 13:48, 30 October 2025 (UTC)

Seeking volunteers to join several of the movement’s committees

Each year, typically from October through December, several of the movement’s committees seek new volunteers.

Read more about the committees on their Meta-wiki pages:

• Affiliations Committee (AffCom)
• Ombuds commission (OC)
• Case Review Committee (CRC)

Applications for the committees open on October 30, 2025. Applications for the Affiliations Committee, Ombuds commission and the Case Review Committee close on December 11, 2025. Learn how to apply by visiting the appointment page on Meta-wiki. Post to the talk page or email cstwikimedia.org with any questions you may have.

For the Committee Support team,

- MKaur (WMF) 14:12, 30 October 2025 (UTC)

Wiktionaries client use

I heard wiktionaries at this moment seldom use wikifunctions and ome of the reason is that using a hardcoded Qid or Zid/Lid is a problem for them. In Rome cases it's easy to hile behind a template call, in some not. Could there be a way to get, say a lua/passer fonction for client wikis that get a list of lexemes from their string lemma (and language?) This would make easier to get lexemes from clients, without magic numbers in the source. TomT0m (talk) 18:05, 30 October 2025 (UTC)

This problem was being discussed at Wikifunctions talk:WikiProject Wiktionary functions but the Feature request has not yet been prepared. Whether there would be a parser function, I don’t know, but I think the use case is understood well enough. GrounderUK (talk) 19:55, 30 October 2025 (UTC)

If function, then part fails

I have produced a test to replicate this: Z29145

Normally in programming languages you don't run the then part if the condition fails. However our If function does. Not sure if this is intentional? Do we have alternative If function, if so? GrimRob (talk) 18:41, 31 October 2025 (UTC)

Ignore this for now, I didn't scroll far enough to the right to see that the built in version succeeded. GrimRob (talk) 18:54, 31 October 2025 (UTC)

Make function/implementation/test pages more distinguishable

Hi,

It seems to be a common problem, especially but not only for beginners, to know what type of pages are looking at. Mainly because the identifier look the same (you can't deduce from the id alone Z16438 or Z16439 what it is). There is some visual clues that allow to know if a page is a function, an implementation or a test (in particular, it's written under the identifier) but I'm wondering if we couldn't/shouldn't make the distinction more obvious, for instance adding some kind of icon before the name, writing the type more prominently, and/or changing the color a bit (other ideas are welcome obviously).

What do y'all think?

Cheers, VIGNERON (talk) 13:09, 1 November 2025 (UTC)

I agree. I don't know exactly what the design elements should be, but making it a little bit clearer so that one, at a glance, sees what type of page one is currently on would be very helpful. Especially since in a normal workflow one start with a function, creates a test, goes back to the function creates the implementation and then to the function again. These switches and having to know what type the page you're looking at is, is a cognitive burden in an already complex task. Ainali (talk) 13:46, 1 November 2025 (UTC)

Makes sense. I’d like to pitch in phab:T373735 here, too. Also, we already distinguish functions with a different icon in the object selector, but it would be better to limit the results to the required type of object (as already happens in some contexts). GrounderUK (talk) 14:12, 1 November 2025 (UTC)

Functions using this function

Inspired by Vigneron's observation above and a note I made in the chat at the talk at WikidataCon today. We are now at a place that it is possible to compose function of other functions, which in turn may be part of other compositions. Following the latest newsletter I could figure out how to add Swedish to the album short description function. But it is a bit confusing, and it was noticeable in this instance, to keep track on what "level" one is working on or looking at. I think it would be helpful to have on the page (not having to go the WhatLinkshere and having to figure out which links may be relevant) something like "This function is used by: [list of functions]" Or do you have any other good tricks for this? Ainali (talk) 13:59, 1 November 2025 (UTC)

I don’t know whether it’s a “good” trick, but you can try something like this:

Special:Search/: z14K2 "z7k1 Z13708" !"z14K1: Z13708".

This should find implementations that call a given function (Z13708, in this case) but which are not themselves implementations of that function. This is more focused than “What links here”, also eliminating test cases and pages outside of the main namespace. As phab:T373735 suggests, being able to see which function the listed implementations implement would be an advantage (and this also applies to the results in “What links here”).

This approach cannot handle nested function calls or the kind of indirection introduced by function application (as with functions configured by language). In the second case, an alternative like

Special:Search/: Z28811 !"z14K1: Z28811" !Z20

will exclude the function’s own implementations and all test cases, but still find the configuration that selects the target function. GrounderUK (talk) 15:00, 1 November 2025 (UTC)

I like your question and think having something for this is helpful. What do you think about creating Wikidataitems for each function in Wikifunction and adding a property to each item to show which functions a function is using. I am not sure if it is a good solutions. It seems to be more usable than the special search syntax. SPARQL-Queries are also not easy to modify and so I am not sure if it is a good idea and if there will be enough user. A bot can be used to update the items every time a function is modified. Hogü-456 (talk) 17:36, 3 November 2025 (UTC)

I suspect that the data is already in some database tables, so it would probably be redundant storing it on Wikidata as well. Ainali (talk) 19:02, 3 November 2025 (UTC)

Do you know where the information is stored. I looked at the tables of the Wikilambda extension. There is the wikilambda_zobject_join_table and wikilambda zobject function join table. It seems to me like these are the most related tables for the request you have. I tried to write queries in Quarry to get the content and have not found out if there is the information inclueded what functions are used in a function. Hogü-456 (talk) 21:22, 4 November 2025 (UTC)

I don’t believe the information already exists. Functions are not physically used by functions; they are used by implementations and test cases. This is why “What links here” for a function lists no functions (apart from itself). GrounderUK (talk) 21:54, 4 November 2025 (UTC)

Categorisation and extended documentation for functions

This has come up before, but going forward I think it would be worth setting up a template like d:Template:Property documentation where related functions and categories could be listed in a standard way, rather than asking people to put links on talk pages ad hoc. Stuff like "equivalent functions on other data types:", "is specialisation / partial application of:", or "is subroutine of:". And then long-form documentation for humans could follow that if necessary, maybe stored on a different page and transcluded so that it's translatable. YoshiRulz (talk) 17:32, 4 November 2025 (UTC)