Wikifunctions:Project chat/Archive/2025/10

Wikifunctions & Abstract Wikipedia Newsletter #220 is out: Rich text now available in embedded function calls on 148 Wiktionaries and Incubator

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

In this issue, we update you on the latest functions and types you can create, we announce that functions are now available to call on 152 projects, we talk about our presentations at Wikimedia meetings, 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 October 6, at 17:30 UTC (link to the meeting).

Enjoy the reading! -- User:Sannita (WMF) (talk) 08:55, 4 October 2025 (UTC)

This section was archived on a request by: Jdforrester (WMF) (talk) 19:13, 14 October 2025 (UTC)

Have your say: vote for the 2025 Board of Trustees

Hello all,

The voting period for the 2025 Board of Trustees election is now open. Candidates are running for two (2) seats on the Board.

To check your voter eligibility, please visit the voter eligibility page.

Learn more about them by reading their application statements and watch their candidacy videos.

When you are ready, go to the SecurePoll voting page to vote.

The vote is open from October 8 at 00:00 UTC to October 22 at 23:59 UTC.

Best regards,

Abhishek Suryawanshi
Chair, Elections Committee

MediaWiki message delivery (talk) 04:47, 9 October 2025 (UTC)

This section was archived on a request by: Sannita (WMF) (talk) 13:50, 30 October 2025 (UTC)

Wikifunctions & Abstract Wikipedia Newsletter #221 is out: Decision on location for abstract content and Quarterly Planning for October–December

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

In this issue, we introduce our naming contest for Abstract Wikipedia, we discuss our plans and work for the upcoming quarter (October-December 2025), we report on the next events we'll be part of, 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) 17:47, 9 October 2025 (UTC)

This section was archived on a request by: Sannita (WMF) (talk) 13:50, 30 October 2025 (UTC)

Wikifunctions & Abstract Wikipedia Newsletter #222 is out: Kicking Off the Naming Contest for Abstract Wikipedia; Visualizing functions

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

In this issue, we kickstart our naming contest for Abstract Wikipedia, we present a beautiful representation of functions by a community member, we report on the next events we'll be part of, 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) 17:04, 15 October 2025 (UTC)

This section was archived on a request by: Sannita (WMF) (talk) 13:50, 30 October 2025 (UTC)

Help us decide the name of the new Abstract Wikipedia project

Hello. Please help pick a name for the new Abstract Wikipedia wiki project. This project will be a wiki that will enable users to combine functions from Wikifunctions and data from Wikidata in order to generate natural language sentences in any supported languages. These sentences can then be used by any Wikipedia (or elsewhere).

There will be two rounds of voting, each followed by legal review of candidates, with votes beginning on 20 October and 17 November 2025. Our goal is to have a final project name selected on mid-December 2025. If you would like to participate, then please learn more and vote now at meta-wiki. Thank you!

-- User:Sannita (WMF) (talk) 11:42, 20 October 2025 (UTC)

This section was archived on a request by: Sannita (WMF) (talk) 13:50, 30 October 2025 (UTC)

Wikifunctions & Abstract Wikipedia Newsletter #223 is out: Welcome Zaree and Laura! Naming contest round 1 kicked off

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

In this issue, we welcome two new additions to the team, we update you on our naming contest for Abstract Wikipedia, we report on the next events we'll be part of, 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) 21:10, 23 October 2025 (UTC)

This section was archived on a request by: Sannita (WMF) (talk) 13:50, 30 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)

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)

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)

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 config for article-less instantiating sentences (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 config for displaying 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)

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 label texts for 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)

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)

Nice work 🤩 So9q (talk) 05:16, 14 November 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)

支持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)