Wikifunctions:Project chat/Archive/2023/12

Wikifunctions & Abstract Wikipedia Newsletter #134 is out: Welcome, Grace and Miguel! Appointing Functioneers now by community

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

In this issue, we present two new members of the team, we discuss the latest changes in software, and we announce that Functioneer right will be now assigned by the community.

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 December 4, at 18:30 UTC (link to the meeting).

Enjoy the reading! -- User:Sannita (WMF) (talk) 12:01, 1 December 2023 (UTC)

This section was archived on a request by: Sannita (WMF) (talk) 13:15, 13 December 2023 (UTC)

Wikifunctions & Abstract Wikipedia Newsletter #135 is out: Announcing Wikifunctions on the Wikimedia Foundation blog. Looking for feedback on the Function page proposal

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

In this issue, we present the latest blogpost about us on WMF blog, and we invite you to share your feedback at the Wikifunctions' Project chat on the new proposed designs for the Function page.

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

Enjoy the reading! -- User:Sannita (WMF) (talk) 19:06, 7 December 2023 (UTC)

This section was archived on a request by: Sannita (WMF) (talk) 13:15, 13 December 2023 (UTC)

Future programming languages?

Are there plans to add more programming languages to Wikifunctions, e.g. Kotlin JS and maybe C++? I know Lua is planned, but what about anything else? Aaron Liu (talk) 00:57, 2 December 2023 (UTC)

There are not any timelines for adding new programming languages, but there are a variety of proposals in phab:T307171 (Lua), phab:T298633 (Vlojure), phab:T298635 (Grammatical Framework), and phab:T301418 (a graphical language such as Scratch or Snap!) which you could add to. I'll encourage the team to share details on the which/when/how aspects of selecting, implementing, and maintaining support for new programming languages. I hope that helps. Quiddity (WMF) (talk) 01:41, 2 December 2023 (UTC)

Hmm, thanks. I have created two tasks for Kotlin and LabView. Should there be a tracking supertask for such tasks? Aaron Liu (talk) 02:01, 2 December 2023 (UTC)

Good idea. -- DVrandecic (WMF) (talk) 03:56, 2 December 2023 (UTC)

Diff post

https://wikimediafoundation.org/news/2023/12/05/introducing-wikifunctions-first-wikimedia-project-to-launch-in-a-decade-creates-new-forms-of-knowledge/ Discussion at Hacker News: https://news.ycombinator.com/item?id=38548130 ―Justin (koavf)❤T☮C☺M☯ 21:08, 6 December 2023 (UTC)

Wikifunctions & Abstract Wikipedia Newsletter #136 is out: Looking back at 2023

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

In this issue, we look back at all the accomplishments that we achieved in 2023 and we thank you all for your help in achieving them. Also, we take a look at the latest software developments.

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

This will be the last newsletter for 2023, so see you again in 2024!

Enjoy the reading! -- User:Sannita (WMF) (talk) 11:49, 15 December 2023 (UTC)

This section was archived on a request by: Sannita (WMF) (talk) 10:30, 5 January 2024 (UTC)

Hindi translation of existing functions

Hey, this seems interesting. How can I translate existing functions in Hindi? -- Suyash.dwivedi (talk) 19:12, 8 December 2023 (UTC)

@Suyash.dwivedi, Do you mean to translate its labels and descriptions or to create ones like English plural (Z11089) but for Hindi? Msz2001 (talk) 19:27, 8 December 2023 (UTC)

Yes like was able to do this Hindi translation edit -- Suyash.dwivedi (talk) 19:54, 8 December 2023 (UTC)

It's done correctly. If you want to see more functions and objects, you can go to Special:ListObjectsByType/Z8. Msz2001 (talk) 20:19, 8 December 2023 (UTC)

There's also the draft page at Help:Multilingual with further suggestions of areas for translators to consider contributing to, which may help you, Suyash.

Also, any improvements to that page would be great, especially in terms of making it: informative for newcomers who may or may not have [some/any] coding skills; and making a good structure so that any (current & future) lists within it scale cleanly once the page itself has been marked for translation (which could perhaps be done soon, if other folks are happy with the content that we started it off with?). Quiddity (WMF) (talk) 23:54, 8 December 2023 (UTC)

Infinite loops with composition

I recently came across Composite negated is even (Z12485) and Composite negated is odd (Z12486) which use composition with the negated result of the other's function - together, these could create an infinite loop. Is the software smart enough to handle it if both are approved for their respective functions? DannyS712 (talk) 06:41, 23 December 2023 (UTC)

AFAIK, as long as the function has more than just those recursive composition implementations, it would be fine. 0xDeadbeef (talk) 15:41, 2 January 2024 (UTC)

This section was archived on a request by: DannyS712 (talk) 04:16, 8 January 2024 (UTC)

Vandal detected ⚠️

There is a new user, Christmas day vanda(ism. So far they have made one vandalistic edit, making a function called "On wheels!". I am just reporting them.

I also question the livelihood of Wikifunctions. It is not being extensively worked on. BrightSunMan (talk) 11:44, 25 December 2023 (UTC)

Account was locked globally and I deleted the page here. As for wikifunctions not being worked on, I disagree with that assessment - its probably just because of the holidays that it seems a bit slow at the moment --DannyS712 (talk) 16:26, 25 December 2023 (UTC)

Oh, good. I am happy to hear that it is being worked on. However, I base my assessment on some things, such as a low number of regulations, low-quality content (such as forgotten capitalisations), though I see that the project is new and still in its beta phase. I feel the difficulty of leading this project to progress. BrightSunMan (talk) 20:49, 25 December 2023 (UTC)

This section was archived on a request by: DannyS712 (talk) 04:10, 8 January 2024 (UTC)

Questions around string reversal and tests

I decided to take another look at wiki functions today as I saw another announcement as it continues to move forward.

Ultimately I ended up looking at reverse string (Z10012) and Reverse String (grapheme level) (Z10548) and getting a bit turned around with either some bugs, general questions, or things missing in my understanding.

• The `extended unicode grafems reverse` test case on 10012 fails for "ab🚵🏻‍♀️de". Is the expectation that all tests should pass? Is this actually something that we would want people to "fix" in this function in this case?
• The `Reverse String (grapheme level)` function appears to just fail with a void result for `'Intl' is not defined`. What are the expectations around using things such as Intl?

·addshore· ^{talk to me!} 15:40, 7 December 2023 (UTC)

We need to figure out how we want to deal, as a community, with failing tests. My gut feeling would be that every test that is connected should pass for every implementation that is connected, and it is up to the functioneers to ensure that. In the end, the functioneers really decide which implementations are connected and not. We could let the system automatically disconnect implementations that fail a connected test, but I am wary about that for now.

Intl is currently not available in the JavaScript interpreter we use, and thus cannot be used in Wikifunctions. If we want to use Intl, we need to make it available. We don't have a process to make this possible right now, so I guess it's up between "let's discuss this here" and "file a task in Phabricator" -- DVrandecic (WMF) (talk) 23:36, 7 December 2023 (UTC)

Yes, I have noticed that you are more conservative about connecting tests and implementations than I am. My criteria for connecting a test has so far been: is it something that a perfect version of this function would get right? And I deliberately go about writing (and connecting) tests that will be difficult to get right. This helps implementation writers to easily score how they are going as they improve their implementation. For connecting implementations, I have been (perhaps inconsistently) connecting at least the best performing implementation, on the assumption that for many functions (especially irregular language ones), the perfect function may never exist. I endorse the need for further discussion and guidance here. --99of9 (talk) 06:10, 8 December 2023 (UTC)

Perhaps it would be helpful to have an intermediate level between connected and disconnected - something like "desirable". Or is that what you take disconnected tests to mean? --99of9 (talk) 06:12, 8 December 2023 (UTC)

I'm no string handling expert, but I'm pretty sure Reverse String (grapheme level) (Z10548) is supposed to handle it by its definition, and reverse string (Z10012) isn't going to handle that ab🚵🏻‍♀️de test at all, since all Z10012 does is reverse the codepoints and not the graphemes (graphemes would need to be segmented according to Unicode® Standard Annex #29). 0xDeadbeef (talk) 17:24, 9 December 2023 (UTC)

I agree, I will be bold and try to move this test across to the grapheme level function. --99of9 (talk) 00:35, 12 December 2023 (UTC)

Tests apply to functions, not implementations, of course. If a test is a valid statement about how the function should evaluate, then it should not be disconnected from the function even if no implementation currently passes the test. As @99of9 suggests, it may be appropriate to distinguish between “valid but failing” tests and “invalid or contentious” tests. Where the consensus is that a test is invalid, it should generally be re-written as its negation. Similarly, if the consensus is that a valid test is unlikely to pass in any currently feasible implementation, the pragmatic limitation should be written into the function definition (making the valid test for an ideal function an invalid test for the currently limited function). GrounderUK (talk) 11:05, 8 December 2023 (UTC)

Duplicate functions

There has now been a duplicate function created. String Length (Duplicate of Z11040) (Z12257) was created and is a duplicate of string length (Z11040). I have protected Z12257 for now to try to stop further editing and to ask what to do going forward with duplicate functions. Ideally we would turn it into a redirect but that is not possible at the moment (See: phab:T344973 and phab:T258915). Terasail^[✉️] 12:48, 8 December 2023 (UTC)

I agree that we need to be able to merge and redirect functions. Unfortunately this seems to be not of interest for the staff working on Wikifunctions. --Ameisenigel (talk) 18:05, 10 December 2023 (UTC)

Is it possible to add a notification banner to a Z-Object. For example at the reduce function Built-in implementation of Reduce (Z976) there is a notification about the fact that the implementation is integrated in the core of the Software and not visible at the page. How was that added to the page and where is the text defined. I think if a duplicate function occurs it is for the beginning enough to inform about the other function and linking to the other function. Maybe at the talk page as long as no possibility to do it at the item exists. Hogü-456 (talk) 22:01, 14 December 2023 (UTC)

@Terasail @Ameisenigel For the time being, focus is on user interface and new types, and this already takes up a lot of time and focus, but next month we'll discuss the possibility of scheduling this task for the first half of the year. I'll keep you posted about it, but feel free to ping me on this. -- Sannita (WMF) (talk) 11:44, 15 December 2023 (UTC)

Switch Chinese Variants

I set the Chinese variant of string length (Z11040) to zh-hans, but I found that other pages were set to zh. I want to know how to modify it?

Perhaps we can also discuss whether it is necessary to translate all Chinese variants on this site? 星海子 (talk) 20:46, 10 December 2023 (UTC)

Sorry, I have selected zh-hans again in this revision, how do I undo it? 星海子 (talk) 13:21, 19 December 2023 (UTC)

Adding support for redirects

I figured I'd take a stab at adding these as a front-end type that would be implemented with a gadget, instead of relying on the development of support in the back end. We can create a new "redirect" type (Type (Z4)) that has a single key, the target of the redirect, use the internal wikilambda edit API (since I couldn't figure it out with the creation page)

Code for the type

{ "Z1K1": "Z2", "Z2K1": { "Z1K1": "Z6", "Z6K1": "Z0" }, "Z2K2": { "Z1K1": "Z4", "Z4K1": "Z0", "Z4K2": [ "Z3", { "Z1K1": "Z3", "Z3K1": "Z6", "Z3K2": "Z0K1", "Z3K3": { "Z1K1": "Z12", "Z12K1": [ "Z11", { "Z1K1": "Z11", "Z11K1": "Z1002", "Z11K2": "Redirect target" } ] } } ], "Z4K3": "Z101" }, "Z2K3": { "Z1K1": "Z12", "Z12K1": [ "Z11", { "Z1K1": "Z11", "Z11K1": "Z1002", "Z11K2": "Redirect" } ] }, "Z2K4": { "Z1K1": "Z32", "Z32K1": [ "Z31", { "Z1K1": "Z31", "Z31K1": "Z1002", "Z31K2": [ "Z6", "alias" ] } ] }, "Z2K5": { "Z1K1": "Z12", "Z12K1": [ "Z11", { "Z1K1": "Z11", "Z11K1": "Z1002", "Z11K2": "Redirect" } ] } }

and then you can use the following to change an existing function (and presumably any other object) into a redirect - replace the Z11522 with the ZID of the redirect type that we created, and Z10020 with the desired target of the redirect:

Code for a redirect
{ "Z1K1": "Z2", "Z2K1": { "Z1K1": "Z6", "Z6K1": "Z11523" }, "Z2K2": { "Z1K1": "Z11522", "Z11522K1": { "Z1K1": "Z6", "Z6K1": "Z10020" } }, "Z2K3": { "Z1K1": "Z12", "Z12K1": [ "Z11" ] }, "Z2K4": { "Z1K1": "Z32", "Z32K1": [ "Z31" ] }, "Z2K5": { "Z1K1": "Z12", "Z12K1": [ "Z11" ] } }

I just tested this out on the beta cluster: https://wikifunctions.beta.wmflabs.org/wiki/Special:Contributions/DannyS712. If there is interest in trying to pursue this, then I'll create a gadget that implements the redirection of redirects. Thoughts? --DannyS712 (talk) 20:59, 20 December 2023 (UTC)

This looks OK, and I'm satisfied we can do this. But this feels better done on the back-end, so I'm not sure we should. User:Sannita (WMF): does the dev team have thoughts? —‍Mdaniels5757 (talk • contribs) 22:06, 20 December 2023 (UTC)

@Mdaniels5757 As I said in a previous occasion, merge and redirects are not on our radar for the moment, since we're focusing on delivering new types and improving the user interface. Anyway, next month we'll discuss the possibility of scheduling this task for the first half of 2024. I'll keep you posted about it, but feel free to ping me on this. Sannita (WMF) (talk) 14:54, 21 December 2023 (UTC)

@Sannita (WMF) this would just be the ability to redirect an item, without merging - we don't need to be able to create redirects from scratch (since those wouldn't really be useful) just from existing items, and that is more important than merging, which can be done with gadgets or manually. --DannyS712 (talk) 19:40, 21 December 2023 (UTC)

@DannyS712 My guess is that it would be fine, but for a definitive answer I'd wait the end of the holidays, since we're all on leave now. Could it wait the beginning of next year? Sannita (WMF) (talk) 15:37, 23 December 2023 (UTC)

Sure no problem --DannyS712 (talk) 18:25, 23 December 2023 (UTC)

Global sysops acting here

Hi all. I recently procedurally requested that global sysops not be allowed to act here since the current policy does not permit them to do so, but was told that we need an explicit discussion to opt-out of the group (which would generally also prevent them from acting here in the future if we do meet the default criteria). At the moment, per m:Global sysops#Scope it is against policy for global sysops to use their permissions here, but they are technically able to do so per m:Special:WikiSets/7. I propose that we request from stewards that the global sysops only be technically permitted to use their permissions here when the wiki falls within the scope of the group (i.e. remove wikifunctions from the wikiset now but if we ever run low on admins in the future then they can come back to helping). An alternative would be to permanently opt-out (unless we later change our minds). --DannyS712 (talk) 21:34, 9 December 2023 (UTC)

Discussion

Sorry, it seems like I'm not understanding. According to Meta's policy, global sysops would not use admin tools here, since there are sufficient local admins. There could be a situation in the future where there are not, so it would be permitted to have global sysops step in to do things that local admins aren't. Why would we want the latter to not happen? And since this is all just hypothetical, I don't understand what's motivating this now: did global sysops come here and cause problems somehow? ―Justin (koavf)❤T☮C☺M☯ 05:24, 11 December 2023 (UTC)

@Koavf well sometimes global sysops don't realize that there are enough local admins (I think I made a few patrol actions here that I shouldn't have) but this is mostly just to avoid potential problems. I didn't think it would be at all controversial to have stewards add wikifunctions to the wikiset so that global sysops wouldn't be able to use the rights here, but at m:Steward requests/Miscellaneous/2023-12#Wikifunctions GS it turns out that stewards want a local discussion to confirm that the policy should be enforced on a technical level. To be clear, I am not proposing a permanent opt-out, just trying to get community consensus to remove us from the group now that we have enough local admins - we can be added back in the future if we don't have enough local admins later. DannyS712 (talk) 15:46, 11 December 2023 (UTC)

Sure. Thanks. ―Justin (koavf)❤T☮C☺M☯ 15:48, 11 December 2023 (UTC)

Hi all, just a couple of notes: these are on-wiki configs - nothing is really 'permanent' - if f: opts out it will continue to be opted out until either - the community decides to opt back in, or the community collapses enough to where there is a mess and there aren't sufficient people around to object to getting the project opted back in. I'm certainly not active on this project to consider "voting" on this proposal - but suggest that that it is a bit premature. There are currently about 6 active community temporary administrators. I would not chide GS's for acting reasonably here right now either - the GS page says "less than 10" - and while 15 accounts are members of the administrator group here, 2 are services and 4 are WMF staffers. Conversely, while it seems that only 6 of the 9 community temporary admins are active unlike many other small projects, they are likely more technically skilled and able to handle things than we would see on a small content project. Ideally, I'd like to see your project grow a bit more to where you have permanent admins before opting out of the ability to have the GS's deal with crosswiki issues that spill over here, but I'm not here to tell you what to do. Best regards, Xaosflux (talk) 21:43, 11 December 2023 (UTC)

Poll

• Enforce scope - remove from the group now but allow them in the future if we have too few admins at some point --DannyS712 (talk) 21:35, 9 December 2023 (UTC)
• Makes sense to remove now given the number of admins and the number of admin tasks that need doing here. While also re-allowing them in the future if numbers fall significantly without needing another discussion. Terasail^[✉️] 15:02, 10 December 2023 (UTC)
• The proposal makes sense to me --Ameisenigel (talk) 18:10, 10 December 2023 (UTC)
• I agree per above Msz2001 (talk) 12:18, 15 December 2023 (UTC)
• Oppose. I think that global sysops should be able to act in uncontroversial situations, for example, to revert vandalism. This reduces the load on local admins and allows them to focus on other administrative work. Frostly (talk) 01:38, 25 December 2023 (UTC)

Adding differences between other projects to FAQ

Hi there, I'd like to propose adding a section to the FAQ that discusses the differences between Wikifunctions and other projects such as https://rosettacode.org/, https://programming-idioms.org/, and https://the-algorithms.com/, I think that this topic is often discussed by newcomers to Wikifunctions (eg see Hacker News comments). This Mastodon post by Vrandečić https://mas.to/@vrandecic/110866878265998471 can likely be paraphrased for the section. Thoughts? — Frostly (talk) 00:50, 25 December 2023 (UTC)

I am pretty sure it is more suitable to add this information to Wikifunctions:What Wikifunctions is not instead, though I see that the article already states the general idea that you want to add at §Wikifunctions is not a code snippet website. BrightSunMan (talk) 11:31, 25 December 2023 (UTC)

Wait, how do you bypass the character limit for function descriptions?

For example, English plural (Z11089): Return the plural of an English word. See https://meta.wikimedia.org/wiki/Abstract_Wikipedia/Updates/2023-09-08 for context. BrightSunMan (talk) 17:06, 27 December 2023 (UTC)

Thanks for reporting! Filed as phab:T354402.

Relatedly, I'll also mention that there is a planned "long description" feature (phab:T260953) and I'll check with the team on the status for that. Quiddity (WMF) (talk) 03:30, 5 January 2024 (UTC)

Halting

I think it should be formulated that function implementations are required to halt. In fact there should be some technical limitation that guarantees our functions to halt, because otherwise this would be an easy target for vandals, and no useful function will fail to halt. I think we should formally document this if it already exists. Jasper Deng (talk) 21:45, 16 December 2023 (UTC)

I suspect that a general solution to this problem on Wikifunctions would be a major accomplishment in the field of computing, as it would present a solution to the Halting problem.

Given that a function halting is undecidable, this may not be possible through automation. However, there may be a middle ground here where the computation time for individual functions (not including the time used in called functions, in the instance of composite implementations) *MUST* exit within a predetermined and sensible amount of time or the implementation/function times outs and the implementation is either disconnected from the function or rejected by human editors. But even this solution is technically flawed and gets into P vs. NP territory. Keplersj (talk) 01:24, 31 December 2023 (UTC)

Halting is not enough, En:busy beavers Halts by definition but can occupy your machine practically indefinitely. I'm not sure there is a solution that would require halting would require a design of a formal proof language like :en:coq or another formal prover. This seems incompatible with the wiki function design as we can use several languages. This kind of stuffs needs persons that knows formal proving, and wiki functions try to be open to the most possible persons by supporting several languages. Having such a requirement for a quite rare skill is not consistent with that anyway.

It's as the query service on Wikidata, which is opened and has a query limit of 60 seconds. Comparatively there should be few functions that run as long on Wiki functions, so this could be solved by the same kind of restrictions, limit the number of calls by a client in a certain time frame, and put a timeout for function executions, I guess. The main usecase is text generation, not bitcoin mining :) TomT0m (talk) 07:56, 13 January 2024 (UTC)

Function page proposal: looking for feedback

Hi everyone,

This is Amin, one of the designers behind Wikifunctions.

We are currently working on the next iteration of the function page, and we would like to hear your thoughts on a possible new approach.

The current page includes two tabs:

• About, where people can read the function description, consult the function name or aliases in multiple languages, and try the function.

  

  Function page with the About tab open.

• Details, where people can read the function definition, view the function input(s) in multiple languages, consult any existing function implementation or test, and find the link to add a new implementation or test.

  

  Function page with the Details tab open.

While reviewing feedback shared on Phabricator, the Project chat, and the Telegram group we identified a few opportunities to be addressed as a first iteration.

We noticed that some of the information that we currently feature on the function page could be displayed with the “widgets” that we deployed on other Wikifunctions pages. For instance we could use the “About widget” to display the function information, or we could use the “Function explorer widget” to display the function definition.

About and Function Explorer widgets on a Test page.

After a few explorations we understood that those two widgets needed to be merged together on the function page to accomodate the editing of the function labels, from the function name to the function inputs labels.

Proposal for merging the About and Function Explorer widget into a new widget on the Function page.

This proposal reduces the space needed to display the same information, and possibly opt for a single view approach. We’re not touching the implementations and tests tables (for now!).

Proposal for a new Function page featuring a custom widget to display About and Function Definition information.

While there’s still some “unused” space, this is for accommodating content that might come in the future such as a “Function documentation widget” (next to “Try this function”?) or a “Where is this function used widget” (below “About”?).

Based on the new proposal, please feel free to answer any, some, or all of the following questions right below:

1. What usually brings you to a function page? What are you trying to achieve when you visit this page?
2. What do you think is working well in the new page?
3. What flows are still confusing in the new proposal?
4. Is there anything missing in the new page?
5. What functionality is redundant in the new approach?

We're looking forward to hearing from you. Thank you! AAlhazwani (WMF) (talk) 09:34, 6 December 2023 (UTC)

@AAlhazwani (WMF) The changes look good, not needing to switch tabs is an improvement. Personally I prefer being able to see the ZID in the page title in addition to the about box. The seperation between input type and label is minimal ("String"/"first string") and not ideal when scanning a page. It might be better if the label is on the left and input type is on the right in the same way that "join strings" and "Z10000" is formatted in the Name section. Terasail^[✉️] 13:08, 6 December 2023 (UTC)

I like the idea of single tab (or rather no tab 😉) layout. I'm wondering if making the Try this function box collapsible could be beneficial (with hidden/shown state saved across visits to a page), so that an editor/administrator etc. who is not really interested in calling the function can have more screen space for the more technical widgets below. Msz2001 (talk) 16:12, 6 December 2023 (UTC)

I share with you my experiences of defining functions and writing implementations and writing test cases. I often wish I had a requirements specification when writing implementations and when using functions written by others. Neither titles nor descriptions can fulfill this role, as their respective character limits are too tight. Titles and descriptions are for readers, but specifications, which define how the function should handle corner cases or the expected complexity, are truly useful for contributors. That can fill up the unused space, I suppose. MilkyDefer 07:42, 7 December 2023 (UTC)

Would the tests be able to fulfil this task of being a specification? -- DVrandecic (WMF) (talk) 23:30, 7 December 2023 (UTC)

If that were the case I would not have been stuck on is valid email address (Z10410). MilkyDefer 11:00, 12 December 2023 (UTC)

I don't understand, where are you stuck? -- Denny (talk) 03:57, 11 January 2024 (UTC)

(Sorry for overlooking your reply.) I am following textbook procedure of software development (waterfall model, I suppose?), and I believe tests should be made to match the spec, but not define the spec. I still hold this notion. I am currently stuck at correctly interpreting the specification of email addresses, which is essential to write valid test cases. If test cases can be used to define the specification, I could easily redefine "email address" using my current testcases, instead of being stuck at sorting out the actual spec and writing testcases. Hope that clears some of your confusions. MilkyDefer 16:09, 24 January 2024 (UTC)

1. Instead of just “About”, why not “About this function [Z10000]?

2. I’m not convinced that “Name” should come before “Description”. It is just a preferred alias. In any event, it should be something like “English Name”. I’m not sure how we stand with multiple fallback languages, but I suggest we should always be clear which language each label is assigned to.

3. Personally, I find it often makes more sense to talk about the output of a function before specifying the required inputs.

4. Similarly, the label for an input is generally more informative than its type.

5. We don’t have a label for the output. My expectation would be that one of the aliases for a function would be an appropriate label for its “output” (that is, something like “joined string”). I suspect we may need to change the function model here, however.

6.It is odd that we have an “Other languages” button but no reference to the current language. This relates back to point 2. If the current language explicitly applies to all the details, then any details that are missing in that language should be shown as such, together with whatever details are available in some fallback language (with that language being explicitly labelled). GrounderUK (talk) 21:17, 7 December 2023 (UTC)

Nice changes! As the others above, I too appreciate the tab-less layout. I have just a couple small suggestions:

• I'd like the Tests and Implementations tables to be collapsible, and I'd suggest collapsing the Tests table by default (to make the initial view less daunting). In fact, maybe even the Implementations table could be collapsed by default.
• I would suggest re-adding the "Aliases" label next to the aliases "pills", because the way they look right now conveys (to me at least) a notion of tags, rather than aliases, which may discourage people from adding useful aliases, or encourage them to add aliases that don't really fit that role well.

Waldyrious (talk) 19:13, 18 January 2024 (UTC)

thank you @Waldyrious for the kind feedback (and apologies for the belated reply!). collapsable tables, and even widgets in general is something that we could definitely explore. what i particularly like about this approach is that we could let people "customize" their own experience. for instance, is someone interested in the technical details only? they could collapse the about widget, and the try this function widget and keep only the implementations/tests tables open.

re:re-adding the aliases label, the assumption we're making is:

- when someone will add or edit aliases, this will happen in an input field with the label "Aliases" right above, giving them guidance about the expect type of content.

- when someone will read aliases, the content will be self-explanatory, meaning that it will be hopefully clear that whose are aliases to the function name in this case, and not more generic tags.

that said, what you shared is still a valuable feedback, and we should monitor this to observe if there's any confusion about aliases. AAlhazwani (WMF) (talk) 13:51, 8 February 2024 (UTC)