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 2025/11 2025/12 2026/01

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)

支持zh-cn=维基函数，zh-hk=維基函數，zh-tw=維基函式。遵循各地用語习慣才是最自然的。維基數據本來也應該譯為維基資料，不知道為什麼沒有這樣。 Midleading (talk) 04:48, 26 November 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)

@Kwgulden, @魔琴, currently Wikifunctions is not OOP (ruling out OOP methods) and each subroutine returns a value and no internal state changes are preserved (ruling out procedures). This means it indeed focuses on 函数/函式 but not the more general 子程序/子程式. MilkyDefer 15:22, 28 December 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)

現決定在m:Special:MyLanguage/Abstract Wikipedia/Abstract Wikipedia naming contest完成前，在中文社羣內部討論中暫將「Abstract Wikipedia」稱爲「抽象維基百科」。

(DeepSeek translation) It has been decided that, prior to the completion of the m:Special:MyLanguage/Abstract Wikipedia/Abstract Wikipedia naming contest, "Abstract Wikipedia" will provisionally be referred to as "抽象維基百科" in discussions within the Chinese community.

-- 魔琴 (talk) 05:53, 14 November 2025 (UTC)

zh-hant: 抽象維基百科; zh-hans: 抽象维基百科. -- 魔琴 (talk) 06:07, 14 November 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)

@Davidzdh: 这聽起来像另择翻译。programming function 是一個技術性的術语，我觉得可能很难找到合適的替换词。如果要天马行空造出一個有联繫的词，这应该是命名比赛的範围，我不清楚维基媒体是否允许我们这樣另择翻译，虽然我们確实有Wikisource=>维基文库。 魔琴 (talk) 16:11, 9 November 2025 (UTC)

Also consider the technical term "functional programming". dringsim 01:45, 16 November 2025 (UTC)

@沈澄心:你的意思是？叫「维基程序函数」？「维基函数编程」？ 魔琴 (talk) 19:16, 1 December 2025 (UTC)

我主要是想说考虑到现有的一些专业术语Wikifunctions的译名可能不太适合脱离“函数”这个词…… dringsim 19:24, 1 December 2025 (UTC)

@沈澄心: 願聞其詳。--魔琴 (talk) 03:03, 11 December 2025 (UTC)

@魔琴：我的理解是Wikifunctions是在做一种函数式编程（？），如果把“函数”替换成“程序”或者别的什么就不太对了。 dringsim 03:23, 11 December 2025 (UTC)

🤔️……感谢解释，不过这就超乎我的知识范围了（--魔琴 (talk) 03:50, 11 December 2025 (UTC)

@沈澄心: Nope, functional programming (I mean, I can write some Haskell) does not look like that. Maybe the function composition implementation bears some similarity but they are still wildly different. MilkyDefer 15:16, 28 December 2025 (UTC)

I am proposing: 維基程式 / 維基程序. These translations do not reflect "Wikifunctions", but I think it reflect what Wikifunctions is doing. I am not saying it is necessarily the best choice, but I guess it can definitely be considered? 程式 seems more accurate (and it is also used in Hong Kong and Macau (unlike 函式 which is mainly just used in Taiwan)), while 程序 seems a bit ambiguous. Would 程式 be used in mainland China / Singapore / Malaysia? Sun8908 (talk) 17:12, 10 December 2025 (UTC)

@Sun8908: zh-CN單獨搜索「程式」的結果大多數是「一定的格式」、「事情进行的先后次序」*的含義，但是說不定聽者可以理解？新、馬大概沒有這個問題。

這個名字，我主要擔心會和「the computer program of the wiki software」混淆。（參見zhwiki搜索結果）雖然function也有歧義，能指數學函數，但是「危害性」似乎更小。

* 現代漢語詞典第7版p.170

--魔琴 (talk) 03:03, 11 December 2025 (UTC)

Now we can use AI like Google Gemini or ChatGPT. No one will use it. I predict will close soon. 維基小霸王 (talk) 00:13, 29 December 2025 (UTC)

Break

根据先前的讨论，我们有以下几种选择：

根據先前的討論，我們有以下幾種選擇：

Based on the previous discussion, we have the following options:

1. 维基函数/維基函數；维基函式/維基函式
2. 维基函数库/維基函數庫；维基函式库/維基函式庫
3. 维基程序/維基程序；维基程式/維基程式
4. 维基子程序/維基子程序；维基子程式/維基子程式
5. 维基功能库/維基功能庫
6. [+] 维基程序集/維基程序集；维基程式集/維基程式集
7. [+] 维基法式/維基法式
8. [不翻译;不翻譯;DNT]

请各位再就以上几种选择发表看法，当然也可以提出新的选项。另外，鉴于也有几位同仁认为应该转换地区词，也请各位就此问题再探讨一下。感谢。

請各位再就以上幾種選擇發表看法，當然也可以提出新的選項。另外，鑑於也有幾位同仁認爲應該轉換地區詞，也請各位就此問題再探討一下。感謝。

Please share your thoughts on the options mentioned above, and feel free to suggest new options as well. Additionally, since some colleagues believe that we should convert the regional terms, please discuss this issue further. Thank you.

--魔琴 (talk) 19:20, 27 December 2025 (UTC)

@Ericliu1912, PexEric, For Each ... Next, SunAfterRain, Midleading, S8321414, Kwgulden, Stang, MilkyDefer, Sheminghui.WU, WAN233, Davidzdh, 沈澄心, Sun8908。 魔琴 (talk) 19:26, 27 December 2025 (UTC)

@Zyx20101210, Didaictor, TimT0316, Liuxinyu970226；@HenryLi；@維基小霸王。 魔琴 (talk) 19:32, 27 December 2025 (UTC)

I suggest it is 維基程式集. It looks like a programming library. 程式 is the name for programming in Chinese. It is easier for reader to comprehend. 函數, 程序, 子程序 and 功能 does not reflect well on Wikifunctions's nature in Chinese.

建議命名為「維基程式集」，似集合種種程式，讀者一望程式，就知同寫程式有關。函數、程序、子程序、功能，令聯想到其他意思，並非一望就知。

- HenryLi (talk) 19:49, 27 December 2025 (UTC)

Added. --魔琴 (talk) 15:39, 28 December 2025 (UTC)

I'd like 维基函数,because 维基函数 can explain the main of this program , and it is the translation of wikifouction in chinese

我更喜欢维基函数，因为维基函数可以更好的解释这项功能的用途，并且由英语直译而来，更简单 Zyx20101210 (talk) 11:16, 28 December 2025 (UTC)

I still prefer 维基函数, at least on zh-cn. 函式/程式 are not widely used words in mainland China.--WAN233 (talk) 13:07, 28 December 2025 (UTC)

If you were standing in other people's shoes your argument can also be used against your preferred choice as well. MilkyDefer 15:05, 28 December 2025 (UTC)

Is regional variant naming allowed? If it is I support 维基函数库/維基函式庫 pair, followed by do-not-translate. If not, I firmly go by do-not-translate, followed by 维基功能库/維基功能庫 pair as a compromise. MilkyDefer 15:03, 28 December 2025 (UTC)

No rules against it. I prefer not to because it would be less elegant, but, well, it won't break anything. --魔琴 (talk) 15:53, 28 December 2025 (UTC)

I prefer 维基函数(库)/維基函式(庫) as regional variants.--S8321414 (talk) 01:43, 29 December 2025 (UTC)

Davidzdh asked me on my talk page to help him/her post his/her comment:

As I have suggested, we should reconsider the translation from a branding perspective. While "函数" or "函式" are technically accurate, they often carry a dry, academic tone associated with mathematics textbooks.

I propose "維基法式" because "法" (logic/rules) and "式" (formula/pattern) perfectly capture the essence of a function—transforming input into output through predefined logic—without being limited by school-level connotations. This name maintains the four-character rhythm consistent with major sister projects like 維基百科 and 維基數據. Much like the successful translation of "維基文庫" (Wikisource), this creative approach establishes the project as a unique knowledge platform rather than a mere technical repository, effectively bypassing regional terminology disputes.

I deeply admire the technology and philosophy behind Wikifunctions and Abstract Wikipedia; I hope this name does justice to their vision and that the project brings renewed vitality and prosperity to the entire Wikimedia movement.

@Davidzdh--魔琴 (talk) 14:42, 6 January 2026 (UTC)

希望諸位能夠論述自己支持、反對的原因，論述各個選項的優劣，而非僅僅表達意向，否則很難總結出共識。謝謝。--魔琴 (talk) 15:34, 6 January 2026 (UTC)

提議訂名維基程式集，原因如後：

要從本處定義去想。

• A "function" is a sequence of programming instructions that makes a calculation based on data you provide.

此處性質說明，說明要寫程式。訂名應從此方面入手，使人一望明瞭，全無歧義。

函数、函式，教人聯想到數學，畢竟大部份受過教學數育，而且物理學函数、函式眾多，人家會以為寫數學物理。歧義太多，不好反映性質。功能更之離題萬丈，教人不知所云。不能純由字面翻譯。

此處是寫程式，故名程式，一望即知。由於無尾字會有歧義，所以要加個集在尾。個人不建議庫字，庫字好像日本帶來。集字會字，方是中文應有名字，以示集合，如詩集、三才圖會。但會字又有歧義，聯想到社團。況且，集字更好反映本處願景，願向世界各地人收集程式。故此建議命名維基程式集，望文生義。

I propose the name 維基程式集 for the following reasons.

The project definition of “function” is: a function is a sequence of programming instructions that performs a calculation based on the data provided. This definition makes the nature of the project very clear: it is concerned with writing programs. The name should therefore be chosen from this perspective and should allow people to understand its purpose at a glance.

For those with a Chinese language background, the terms 函数/函式 tend to evoke mathematics. Most people have received formal education, and these terms are used extensively in mathematics and physics, so the project may easily be mistaken for something related to those fields. This level of ambiguity is too great and does not reflect the true nature of the project. The term 功能 is even further removed from the intended meaning and may leave people confused. For these reasons, the name should not be determined by a purely literal translation.

As the project focuses on writing programs, the term 程式 is appropriate. It naturally brings programming to mind and makes the purpose immediately clear. Personally, I do not recommend using the suffix 庫, as it feels like a borrowing from Japanese. The character 集 better reflects traditional Chinese naming conventions, indicating a compiled collection, such as 詩集 or 三才圖會. However, the character 會 can also be ambiguous, as it may refer to an organisation. By contrast, 集 more clearly conveys the idea of gathering contributions from people around the world.

For these reasons, I suggest the name 維基程式集, which communicates its meaning clearly through the words themselves. HenryLi (talk) 16:57, 6 January 2026 (UTC)

這也不是不行，但是不是一樣有地區詞的問題？--S8321414 (talk) 01:48, 7 January 2026 (UTC)

不難解決。同義尚有程序、編程。程序用廣，歧義很多，故不建議。編程，稱維基編程集亦可。 HenryLi (talk) 10:05, 7 January 2026 (UTC)

這個我就不支持了，寧願用地區詞轉換……--S8321414 (talk) 12:38, 7 January 2026 (UTC)

支持翻譯爲「維基函數」，並仿照維基數據不轉換地區詞。其他選擇或是使用了function以外詞彙的常用翻譯，或是在原名上增添、生造而效果卻沒有多好，節外生枝。——枰 09:11, 7 January 2026 (UTC)

我要再強調一遍，在programming領域中function這個詞語就是有地區差異。 MilkyDefer 11:22, 10 January 2026 (UTC)

I'm currently agree with Ericliu1912's opinion.
Besides, before I noticed this discussion, I saw that the Traditional Chinese“About”page (i.e., the main page) had already translated Wikifunctions as“維基函式庫”, so I followed that and translated it as “维基函数库” in Simplified Chinese as well. After I became aware of this discussion, I reverted my edits and restored Wikifunctions to remain untranslated. 浅村しき (talk) 02:40, 15 January 2026 (UTC)

Hi, @優枰, I’ve seen your changes—thanks for adjusting the formatting. However, the link I placed there was intended to point to that specific comment by Ericliu1912 on this page(#c-Ericliu1912-20251014215900-魔琴-20251014131400), not to his user page; I’m noting this here for clarification. 浅村しき (talk) 07:24, 16 January 2026 (UTC)

Wikifunctions and the Abstract Language / functions helping

I think I have a bit of a crazy idea. I watched the video of the volunteer corner, Denny talking and demonstrating how to develop the basic wikifunctions for language generator.

One thing I could feel is that's it's hard keeping track of what is happening into the different layers of functions, switching back and forth to the different pages and tests.

Then I thought about the idea of a "Wikifunction Spreadsheet" and I think it could be a great help actually in that task !

Instead of the "One function per page" you put one function call per cell, and a sequence of composition into the adjacent cells. On another cell you can try another function connecting the results of the previous cells to try and compare all on the same page.

You put the tests (maybe even imported from the function tests itself) in different columns and copy the "composition formula" into the columns as we can copy formulas in a traditional spreadsheet to see the intermediate results into the rows, see at which step it breaks if you split the composition into smaller formula that uses the results of the previous step on the previous line …

It might not be that much work to implement into Wikifunctions as the formula editor and the views for the datatypes are already implemented ?

@DVrandecic (WMF) @Jdforrester (WMF) @VIGNERON what do you think ? (ping the people who participated) TomT0m (talk) 19:29, 6 December 2025 (UTC)

Oh, I like a lot the idea of tracking what is happening inside a composed function, seing the result of each sub-functions. I'm not sure to fully understand the spreadsheet formating and/or analogy, but I'm definitely in agreement with the underlying idea. Cheer, VIGNERON (talk) 09:23, 7 December 2025 (UTC)

My idea was to use an actual Spreadsheet. But instead of the usual string inputs in the cells for data, you'd use typed Wikifunctions datatypes inputs, and instead of traditional spreadsheet functions you can compose to create formulas, you can use any wikifunctions. You could use usual cell reference for functions inputs.

To decompose a function for debugging, you can replace a function with its composition implementation in the UI, or something like that. And you highlight a part of the composition and the UI let you replace it with a cell reference in the formula, and move that part of the composition to that cell. That way the extracted cell with this subformula will show the intermediate result.

In the same spirit you want to see if you can replace a function with another in a composition ? You do the previous operation to extract that function in a cell. You copy everything like in a traditional Spredsheet, down in the next row. You get another cell for another intermediate result. Change the function in the copy of the extracted cell in the new row with the new function. Compare the results.

Want to test with a bunch of test lexemes input for exploratory work ? Enter them in a column, In the next column adjascent to the first one, with the cell in the left referenced as an input parameter, enter your composition as a formula. Copy it down …

Just ideas. It seems that it would be a cool UI principle for testing different things, as a lot of people knows a bit about spreadsheets, it's flexible, and we can push the concepts further with more advanced datatypes on Wikidata than usual, and their input and views are already coded in the software. TomT0m (talk) 09:48, 7 December 2025 (UTC)

I really like your idea and I am interested in using it as I am using spreadsheets a lot. In the past I experimented with converting spreadsheet functions into source code in a programming language. I wrote a program to convert some common Spreadsheetfunctions into source code in R. With the program you can read a file in the Flat ods-Format a text version of the .ods-Format a Spreadsheet file format. As an output you get the source code in R what will calculate the same result. So far it works not every time as the program is in an experimental state. You can find the source code of this program here at the Wikimedia Gitlab Instance. If you are interested in testing it I can try to help with the installation. There is an overview page with mappings of Spreadsheetfunctions to Wikifunctions functions at Wikifunctions:Excel functions and Wikifunctions:OpenFunctions. I think mapping the already existing spreadsheet functions to the Wikifunctions functions can help making it easier to convert an function implementation in a Spreadsheet into a Wikifunctions function. Hogü-456 (talk) 18:33, 7 December 2025 (UTC)

@TomT0m Are you interested in working on it further. I hope it can help more people to contribute to Wikifunctions. It seems difficult to me writing functions at the moment in Wikifunctions. Hogü-456 (talk) 22:18, 27 December 2025 (UTC)

Unfortunately I'm focused on something else right now, I won't really work on it in the near future. TomT0m (talk) 14:57, 17 January 2026 (UTC)

Wikifunctions & Abstract Wikipedia Newsletter #232 is out: 25 years of Wikipedia

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

In the first issue of 2026, we celebrate our incredible milestone of 25 years of Wikipedia 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:04, 16 January 2026 (UTC)

Content Assesment

I propose a content assessment system, for the prioritization of work and generally highlighting good functions. This I propose these levels:

• Exemplary, Fully complete. Requires all of:
  • A complete and helpful title and description
  • All inputs with descriptive labels
  • The above in at least 3 languages
  • An implementation in as many languages as is possible, and multiple approaches taken in implementation
  • At least 5 tests, and enough to reasonably cover edge cases
• Good, Functionally complete. Requires all of:
  • A title that conveys enough information about the function clearly and completely
  • All inputs are labeled unambiguously
  • An implementation that succeeds all test cases
  • At least 3 tests, with obvious edge cases covered
• Needs Work, Functional, but requires more work. Requires all of:
  • A title
  • A working implementation
  • At least one test
• Concept, not ready for use. May include:
  • Missing title
  • broken implementation
  • No tests

Much like Wikipedia's system, it would only be for monitoring quality, and for directing to better functions. Feeglgeef (talk) 01:41, 18 January 2026 (UTC)

If nobody objects, I will begin to create templates and classify functions. Feeglgeef (talk) 00:38, 19 January 2026 (UTC)

Sounds good! Will it be more akin to Template:Module rating or to WP:GRADE? YoshiRulz (talk) 04:09, 20 January 2026 (UTC)

I'd say a bit of a mix, as functions are both content (for users, and for use on Wikipedias) and utilities (for other functions) Feeglgeef (talk) 14:03, 20 January 2026 (UTC)

External API integration

Is it currently possible to integrate external APIs into functions? If not, are there any plans to support this functionality in the future, and are there known limitations or considerations influencing that decision? JhowieNitnek (talk) 12:27, 18 January 2026 (UTC)

I don't believe that will ever be possible, beyond accessing Wikidata, as it is out of the scope of the project. Feeglgeef (talk) 00:41, 19 January 2026 (UTC)

Help with function

I just created my first function, Z31188, but I’m having trouble testing it and can’t figure out what the problem is. Is there anyone here who could help me? JhowieNitnek (talk) 19:38, 18 January 2026 (UTC)

I’ve changed the function’s return type to Natural number (Z13518) but the calculated number of days differs by one from your expected result. GrounderUK (talk) 20:06, 18 January 2026 (UTC)

Your test was including both days, which is improper for use of days until (Z20744) Feeglgeef (talk) 00:46, 19 January 2026 (UTC)

The natural number output alters the semantics to “days until or since”. GrounderUK (talk) 01:07, 19 January 2026 (UTC)

Thank you! JhowieNitnek (talk) 12:01, 19 January 2026 (UTC)

Annual review of the Universal Code of Conduct and Enforcement Guidelines

I am writing to you to let you know the annual review period for the Universal Code of Conduct and Enforcement Guidelines is open now. You can make suggestions for changes through 9 February 2026. This is the first step of several to be taken for the annual review. Read more information and find a conversation to join on the UCoC page on Meta.

The Universal Code of Conduct Coordinating Committee (U4C) is a global group dedicated to providing an equitable and consistent implementation of the UCoC. This annual review was planned and implemented by the U4C. For more information and the responsibilities of the U4C, you may review the U4C Charter.

Please share this information with other members in your community wherever else might be appropriate.

-- In cooperation with the U4C, Keegan (WMF) (talk) 21:01, 19 January 2026 (UTC)

Wikifunctions & Abstract Wikipedia Newsletter #233 is out: Quarterly plan for January–March 2026

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

In this issue, we share our work plans for the quarter that goes from January to March 2026, and we take a look at the latest software developments.

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

Enjoy the reading! -- User:Sannita (WMF) (talk) 12:01, 22 January 2026 (UTC)

Will you be updating WF:Status? YoshiRulz (talk) 19:59, 22 January 2026 (UTC)

Typed list starts with

It would be useful to have a function to check whether a list starts with another list (of the same type). But it seems like the closest equivalent is by calling Z28715 and checking if the result is equal to 1. Am I missing something? Is "Typed list" not the correct type to use? Should I create this function? sillypantscoder (talk) 20:14, 23 January 2026 (UTC)

I spent a while looking for a "has prefix" function and couldn't find one, so yes I think you should create it. YoshiRulz (talk) 17:09, 24 January 2026 (UTC)

I've created the function, but my composition implementation doesn't work for some reason. Does anyone have any idea why? (Someone else added a working implementation, but I still want to know what's wrong here.) (Additionally, this implementation should probably be disconnected until we can get it working.) sillypantscoder (talk) 23:41, 24 January 2026 (UTC)

You passed a list containing the needle list to Z28715. YoshiRulz (talk) 01:09, 25 January 2026 (UTC)

Oh that's my bad. (It's so hard to tell!) Thanks for the help! sillypantscoder (talk) 01:11, 25 January 2026 (UTC)

Weird test failures for Z30043

I've given an English label to the implementation of name of language in language (Z30043), and English labels and descriptions to all three test cases, but for some reason two of the tests have stopped working. TTWIDEE (talk) 14:48, 25 January 2026 (UTC)

The error is actually being raised by flatten untyped list (Z12676), and I think the cause might be my attempt to optimise apply a two-parameter function pairwise to elements of two lists of the same length (Z14779). The cache should expire eventually. YoshiRulz (talk) 12:35, 27 January 2026 (UTC)

Wikifunctions & Abstract Wikipedia Newsletter #234 is out: Integrating Abstract Wikipedia

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

In this issue, we share our ideas about the integration of Abstract Wikipedia with the existing Wikimedia projects, 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) 09:51, 30 January 2026 (UTC)

List typing still annoying

Do we think that maybe I shouldn't have to insert 6 calls to untype a list (Z17895) in my composition, ~doubling its size, just so it can work with any type?

Since JS/Python can't be used to implement generic list operations, they have to be compositions. Naturally these are all built from more primitive operations, down to remove first N elements of list (Z13369) etc. which don't play nice with Z1-typed lists.
(A while back I added some disconnected tests to document this: Z29805, Z29808, Z29811)
YoshiRulz (talk) 20:31, 2 February 2026 (UTC)

phab:T407932 is the root issue, as if it were implemented functions would be able to work better with Z1 typed-lists and objects. Feeglgeef (talk) 20:57, 2 February 2026 (UTC)

I don't have an opinion on that ticket, but I'm sure we could fix those low-level functions (or create new ones) without needing any changes to Wikifunctions itself. YoshiRulz (talk) 21:36, 2 February 2026 (UTC)

Yes, I agree it’s a pain. In general, though, I think we can just write generic functions in Python or JavaScript. We need to ensure that these expect and return Z1-typed lists, however. In practice, that may mean also providing a wrapper function that converts properly typed lists into Z1-typed and wraps any Z1 arguments as a singleton Z1-list or Quote.

I think your implementation in JavaScript would succeed for test ins([ 1/1, 2/1 ], 2, [ 5/4, 3/2, 7/4 ]) (Z31354) if the list arguments were Z1-typed. I would expect it to return a list typed for Rational numbers, which is currently unavoidable when a homogeneous list is returned from code. GrounderUK (talk) 14:29, 3 February 2026 (UTC)

You were right, but that's just putting the onus on the caller to wrap in untype a list (Z17895), or as you say, requiring we make wrapper Functions which is inelegant IMO. YoshiRulz (talk) 19:40, 3 February 2026 (UTC)

True, and that’s the motivation behind phab:T407932. It’s good to see the problem being thought about, but we are constrained by the existing conversion machinery, and the unconverted-object route is not designed as a general solution. GrounderUK (talk) 10:30, 4 February 2026 (UTC)

Next Wikifunctions & Abstract Wikipedia Volunteers' Corner will be on February 9

Hi, we remind you that, if you have questions or ideas to discuss about Wikifunctions & Abstract Wikipedia, you can participate to the next Volunteers' Corner, that will be held on February 9, at 18:30 UTC (link to the meeting).

We hope to see you there! -- User:Sannita (WMF) (talk) 06:23, 6 February 2026 (UTC)

Wikifunctions & Abstract Wikipedia Newsletter #235 is out: Finishing each other sentences: Starting things; Offsite in Istanbul

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

In this issue, we share the results of our recent team offsite (meeting in person) in Istanbul, Türkiye, especially on creating sentence fragments in several languages.

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

Enjoy the reading! -- User:Sannita (WMF) (talk) 16:31, 13 February 2026 (UTC)

Projektin nimi suomeksi

Hei @Samoasambia ja kaikki muut! Tämä on mielenkiintoinen projekti. Loin tänne funktion Z31661, näyttäisi toimivan hyvin.

Ehdotan, että Wikifunctions olisi suomeksi ”Wikifunktiot” (wikifunktiot.org). Tällä hetkellä projektin nimi on jätetty kääntämättä keskellä suomenkielisiä sanoja useissa paikoissa etusivulla ja muualla. Jatkossa funktioita voisi toivon mukaan käyttää projektin nimen ja myös muiden sanojen taivutuksessa, jotta sanan voi vaihtaa yhdessä paikassa ja se vaihtuu automaattisesti useassa paikassa. Suomen kielen funktioiden toteuttaminen vaikuttaa tosin todella vaikealta, mutta siitä olisi hyvin paljon hyötyä täällä ja myös muualla. –Onioniton (talk) 13:10, 15 February 2026 (UTC)

(mul) Wikifunctions should be the project’s label in Finnish (Z1051) from Wikidata (Q2013) or a fallback label if (as appears to be the case) there is no label in that language. GrounderUK (talk) 15:12, 15 February 2026 (UTC)