Wikifunctions:Project chat

From Wikifunctions
Shortcut:
WF: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:

SpBot archives all sections tagged with {{Section resolved|1=~~~~}} after 1 day and sections whose most recent comment is older than 30 days.
edit
Archive
Archives

Function naming?

Should we create a naming guideline for functions, implementations, and test cases? Right now it's a mix of different styles. I've been using title case for function names (for example, substring exists (Z10070)), some people have been using all lowercase (like join strings (Z10000)), and some have capitalized only the first letter (like string equality (Z866)). Ingenuity (talk) 02:55, 5 August 2023 (UTC)Reply[reply]

Strong yes! -- DVrandecic (WMF) (talk) 06:57, 5 August 2023 (UTC)Reply[reply]
I'd personally prefer Wikidata/Wiktionary style labels (lower case unless there's a reason not to), alternatively first letter capitalized, like Wikipedia. My main reason for not liking title casing is that it is not used in many languages, like my native Swedish. A weaker rule-set would allow language variation under a common guideline. / Autom (talk) 08:04, 5 August 2023 (UTC)Reply[reply]
The embedded objects already use Sentence case and that's what I'd prefer for names, no matter whether these are types, objects or functions (as it would simplify it for the end-users). I'm not against the all-lowercase, but I feel like naming non-functional objects that way may feel a bit strange (we might be used to naming classes starting with capital letter, whereas functions are named very differently in the languages and there's no predominant style, I think).
There's another question that arises. Should we recommend functions that contain a verb in their names? String equality does describe what the function does but doesn't suggest how to interpret the result. Even if many people would intuitively think of the function returning true for equal strings, there's C's strcmp that does something very opposite: false means equal. Not to mention that for non-technical users, names like SHA-256 may mean nothing (and may even clash with a potential type for a SHA-256 value). On the other hand [Cc]alculate a SHA-256 of string is way more descriptional and gives some clues what to expect from it.
I'm strongly in favor of creating naming guidelines, as it would make it easier for us not to get lost in the project after a few years and not to make is messy. Msz2001 (talk) 08:58, 5 August 2023 (UTC)Reply[reply]
Note that you are also free to change the labels on the embedded objects to make it adhere to any style guide you come up with. -- DVrandecic (WMF) (talk) 16:16, 5 August 2023 (UTC)Reply[reply]

I've just created page WF:Naming convention where I tried to summarize this section and place some other recommendations that I deem useful. Since everything other than not useing Title Case hasn't been polled, feel free to edit and/or extend the page :) Msz2001 (talk) 17:43, 20 August 2023 (UTC)Reply[reply]

I like the draft as it stands so far. I think a next logical step would be to do a poll on whether labels should contain verbs and, in general, how descriptive they should be. I personally lean towards saying that they should as it would make it much more immediately clear what a function does. In any case, I feel that establishing these guidelines should be considered very important. For example of what to avoid, I have found contradictory recommendations for image captions on Commons which have confused me as a newer editor. Getting clear guidelines established quickly feels like a good way to avoid that. Bongo50 (talk) 22:03, 20 August 2023 (UTC)Reply[reply]

Poll on capitalization

Please indicate whether you'd prefer Sentence case, Title Case, all lowercase, or something else. Ingenuity (talk) 21:29, 5 August 2023 (UTC)Reply[reply]

  • I'd prefer either sentence case or lowercase, since they are already widely used on other projects. Ingenuity (talk) 21:29, 5 August 2023 (UTC)Reply[reply]
  • I prefer all lowercase unless things should be capitalized. E.g. K combinator (Z10249). 0xDeadbeef (talk) 04:12, 6 August 2023 (UTC)Reply[reply]
  • I prefer lowercase --Ameisenigel (talk) 09:03, 6 August 2023 (UTC)Reply[reply]
  • For the functions, I prefer all lowercase. Lepticed7 (talk) 09:42, 6 August 2023 (UTC)Reply[reply]
  • Either lowercase or sentence case. Msz2001 (talk) 10:57, 6 August 2023 (UTC)Reply[reply]
  • I prefer lowercase too, unless there is some stuff that has to be capitalized (like @0xDeadbeef showed) Poslovitch (talk) 11:14, 6 August 2023 (UTC)Reply[reply]
  • Lowercase, with exceptions like described above allowed. /Autom (talk) 12:44, 6 August 2023 (UTC)Reply[reply]
  • The scope of the poll could be made clearer — is it (i) only for functions or broader and (ii) only for English or broader? Assuming we're talking English labels for functions, I think all lowercase is reasonable. I would be fine with Sentence case and do not like the idea of using Title Case or CamelCase for this purpose. --Daniel Mietchen (talk) 21:57, 7 August 2023 (UTC)Reply[reply]
  • I prefer lowercase too. –– Tahmid (talk) 04:08, 8 August 2023 (UTC)Reply[reply]
  • Our "function names" are actually labels; their true names look like Z followed by a meaningless number. There is really no reason not to follow Wikidata's convention (i.e. lowercase). NguoiDungKhongDinhDanh (talk) 07:15, 8 August 2023 (UTC)Reply[reply]
  • Either works, but consistency and maybe a style guide is needed. Wd-Ryan (talk) 23:26, 8 August 2023 (UTC)Reply[reply]
  • I'd prefer all lowercase with exceptions as brought up above. Bongo50 (talk) 10:54, 20 August 2023 (UTC)Reply[reply]
  • I don't really care about the chosen solution but I agree that we should talk about it and write some guidelines. And if possible, make the solution simple. Cheers, VIGNERON (talk) 17:25, 21 August 2023 (UTC)Reply[reply]
  • I also prefer lowercase by default. Waldyrious (talk) 15:14, 23 August 2023 (UTC)Reply[reply]
  • Piling on to agree with the lowercase-with-exceptions consensus for function names. --99of9 (talk) 00:21, 31 August 2023 (UTC)Reply[reply]
  • Follow d: convention as per above by NDKDD. Koavf (talk) 06:19, 9 September 2023 (UTC)Reply[reply]

Patrol and Autopatrol rights?

Tracked in Phabricator:
Task T343946

Right now, many changes on Special:RecentChanges are unpatrolled, even though they are made by trusted users. On Commons, we have the autopatrolled group (containing the autopatrol right), which admins can give out to trusted users; right now, the autopatrol right is only available to bots and sysops.

Relatedly, many non-admin users can be trusted to patrol other people's edits. Again on Commons, we have the patroller group (containing the patrol right), which can be given to trusted users. Again, right now, this right is only available to bots and sysops.

This isn't much of a problem now as IP editing is disabled and few-to-no vandals are coming here. As we expand, this will likely become a problem.

I invite thoughts on:

  1. Should we create a new user group or two?
  2. If we make this two user groups, should (a) one group contain both patrol and autopatrol rights and the other the autopatrol right only (as on Commons) or (b) one group contain only the autopatrol right and one group only the patrol right (as on enwiki)?

Best, —‍Mdaniels5757 (talk • contribs) 02:48, 9 August 2023 (UTC)Reply[reply]

For the second question, I prefer the first option (also the case on Meta). One who patrols others' edits must be trustworthy themself. NguoiDungKhongDinhDanh talk 03:24, 9 August 2023 (UTC)Reply[reply]
I prefer one group for autopatrol and one for patrol including autopatrol. think it would make sense to include autopatrol in the funtioneer group. This would reduce the workload and functioneer rights will probably not be given out to vandals. --Ameisenigel (talk) 06:52, 9 August 2023 (UTC)Reply[reply]
@Ameisenigel Just to repeat what you said back to you, you want (1) an autopatrol group, (2) an autopatrol+patrol group, and (3) add autopatrol to functioneers? Also, should functioneers get patrol too, or just autopatrol? —‍Mdaniels5757 (talk • contribs) 16:42, 9 August 2023 (UTC)Reply[reply]
(1): yes
(2): yes
(3): yes, I originally just thought about adding autopatrol to functioneers. I do not have a strong opinion about adding patrol as well. --Ameisenigel (talk) 18:05, 9 August 2023 (UTC)Reply[reply]
I made a patch for adding autopatrolled only, as given the quantity of edits coming from users who would be autopatrolled there may be no need for non-sysop patrollers. The ticket is phab:T343946
Re functioneers getting autopatrol: I'm not opposed to it, but would want assurances from the WMF staff handing it out that they will only give it to established users on a WMF project. If they want/plan to expand their grants of functioneer past that, I think having those edits autopatrolled would not be desirable. —‍Mdaniels5757 (talk • contribs) 02:35, 10 August 2023 (UTC)Reply[reply]
@Mdaniels5757 Thanks for starting the good discussion, and the patch!
Re: The patch, shall I ask the dev-team to check and merge that as soon as possible (to potentially arrive with the deployment train next Wednesday), or does it need more discussion first?
Re: The current process for Wikifunctions:Apply for editing (early + temporary Functioneer user-group), yes I can confirm we're currently checking CentralAuth for existing advanced-rights and/or extensive-experience, and existing blocks (and historic logs in uncertain cases). The only exception is our current GSOC student whom has been working closely with the dev-team (cf. T333498). Thanks. Quiddity (WMF) (talk) 21:34, 11 August 2023 (UTC)Reply[reply]
@Quiddity (WMF) Thanks for responding!
Re the patch, in light of the responses here I don't think the patch adding an autopatrolled group needs any more discussion (it seems uncontentious) and can be merged whenever, but the ticket was set to stalled for lack of consensus. Maybe it can be merged Monday afternoon to allow more time for objections.
Re the functioneer group, that's great, and I think I'd want them to receive autopatrol in that case. My only concern would be when the functioneer group is depreciated, we should give active functioneers the autopatrol group, if that's technically feasible. But that shouldn't be a blocker. I'll make a patch for that, and that can also probably be merged Monday afternoon, if that's in time for the train.
Best, —‍Mdaniels5757 (talk • contribs) 01:01, 12 August 2023 (UTC)Reply[reply]
@Mdaniels5757 Note the Functioneer group itself is permanent. Staff are just allocating the group (with a temporary expiry) for the first few weeks/months so that if unforeseen problems arise then they don't affect too many people/edits. In the near-future, Admins will be in charge of assigning the group to folks. See mw:Help:Wikifunctions/User rights for the expected setup once we reach phase 3 of the deployment plan. Hope that helps, and you all have a good weekend! Quiddity (WMF) (talk) 01:56, 12 August 2023 (UTC)Reply[reply]
I think that it is a good idea and uncontroversial that autopatrol should be added as a usergroup, adding a patrol usegroup may be best after a separate discussion when WF is out of limited roll out so that the need can be better assessed. I think that at this moment it is probably best that functioneers do not get autopatrol/patrol until the group is in a more finalised form instead of the temporary state it is at the moment and can be reassessed at that time. Terasail[✉️] 11:11, 4 September 2023 (UTC)Reply[reply]

Add the ability for administrators to add and remove the confirmed user group

Tracked in Phabricator:
Task T344261

I have created a phabricator task on this however, this will require community consensus for this change to occur. I will copy over my reasoning here aswell (So you don't have to open phabricator).

If anyone were to request the confirmed (Not autoconfirmed) usergroup, there should be no real reason why this is restricted to Bureaucrats as it is at the moment (WF group rights). The ability for admins to complete this is somewhat standard with commons, wikidata and enwiki allowing it, with a notable exception being Meta-Wiki. There is a section available at WF:Requests for user groups#Confirmed to request this, however with a lack of any non Wikifunctions Staff bureaucrats, and Wikifunctions staff wanting to step away from general user group granting, admins and stewards are the only user groups able to grant general user groups for the community.

Do you think that this is a good change to make for Wikifunctions? Terasail[✉️] 17:01, 17 August 2023 (UTC)Reply[reply]

Using a GObject like closure system to support more languages.

GObject is an object system built in C and designed so that things built on top of it can be easily binded to lots of higher level languages (https://en.wikipedia.org/wiki/List_of_language_bindings_for_GTK). One of its features is a closure system that allows callbacks to functions in other languages to be created and be easily call from C code. One of the components of GObject closure is a system to convert language independent GTypes to language dependent types.

Would a similar system for Wikifunctions be applicable/useful? Having a system to convert Wikifunctions types to language dependent types and being able to have implementations in many different languages.

https://docs.gtk.org/gobject/struct.Closure.html CoderThomasB (talk) 02:27, 18 August 2023 (UTC)Reply[reply]

(unarchive and date-bump. Still intending to reply. Sorry for the delays) Quiddity (WMF) (talk) 22:28, 18 September 2023 (UTC)Reply[reply]

External function tables

I came across this list of Excel functions and their Wikifunctions mappings by @Sabas88:, and I think that we should have tables like this somewhere in the main namespace. It would be helpful to see what gaps are missing on the website. Spreadsheet programs, programming language libraries, etc.. -wd-Ryan (Talk/Edits) 14:46, 22 August 2023 (UTC)Reply[reply]

Thank you! I proposed the idea on Telegram, but I wasn't sure where to put the page.. I'm open to move it! --Sabas88 (talk) 07:53, 23 August 2023 (UTC)Reply[reply]
If we're going to bug-for-bug implementations of functions from other platforms (and Excel famously has bugs in the time/date functions that Microsoft has grandfathered in), then they need to kept in their own namespace in some fashion to protect ordinary users from those bugs. Stuartyeates (wikifunctions) (talk) 09:12, 24 August 2023 (UTC)Reply[reply]
Oops, I meant the Wikifunctions: namespace, not main. -wd-Ryan (Talk/Edits) 14:49, 24 August 2023 (UTC)Reply[reply]
Done Now at Wikifunctions:Excel functions --99of9 (talk) 23:57, 19 September 2023 (UTC)Reply[reply]

New name proposal for this page

Hi, I wish ask for your consent in order to rename this page which is simply called Wikifunctions:Project chat to Wikifunctions:Agora, in homage to the agoras, that was a central public space in ancient Greek city-states, which would make it possible to give a more original name. Regards, Manjiro5 (talk) 22:53, 24 August 2023 (UTC)Reply[reply]

I disagree. Our main language is English, so the page name should be a meaningful, common English word. Being a non-native speaker, I've never heard of "agora" before, and I don't see how ancient Greek city-states and Wikifunctions are related. NguoiDungKhongDinhDanh talk 23:59, 26 August 2023 (UTC)Reply[reply]
It would be useful it the MediaWiki:Sidebar link, Extension:Display Title and header section were translatable. /Autom (talk) 13:05, 27 August 2023 (UTC)Reply[reply]
I do not like this new proposed name. It is not particularly clear as to what its purpose is and I feel that clarity is more important than uniqueness or originality. Bongo50 (talk) 07:47, 28 August 2023 (UTC)Reply[reply]

Naming convention draft

A week ago I've made a draft WF:Naming conventions. I've mentioned it already in Function naming? thread but it appears to have got lost between comments. I'm reposting it thus here and seeking for input on that. Feedback and suggestions are welcome.

One more issue, that's not yet included there, is how descriptive the function names should be? Should we recommend including verbs there? Msz2001 (talk) 13:32, 27 August 2023 (UTC)Reply[reply]

As previously stated, I like the current draft a lot. I also lean towards descriptive function names with verbs. Bongo50 (talk) 14:45, 27 August 2023 (UTC)Reply[reply]
I think it's at least as important to consider whether we prioritize clarity over using a short name already in use. to NFC (Z10384) for example isn't going to mean as much to many as "to Normalization Form Canonical Composition (Unicode 15.x)". Stuartyeates (wikifunctions) (talk) 09:06, 28 August 2023 (UTC)Reply[reply]
In a case like that, I prefer the more descriptive name (with the shorter name as an alias, of course). People who will come to Wikifunctions won't necessarily be programmers and so I don't think we should assume familiarity with acronyms. Bongo50 (talk) 11:04, 28 August 2023 (UTC)Reply[reply]
Shouldn't it be at WF:Naming conventions? Might just be what I'm used to seeing on enwiki, but plural feels better here. Skarmory (talk • contribs) 05:59, 1 September 2023 (UTC)Reply[reply]
Agreed, probably we'll have multiple conventions (for example one for types, another for implementations, etc.). —Suruena (talk) 13:10, 2 September 2023 (UTC)Reply[reply]
Moved. Msz2001 (talk) 13:52, 2 September 2023 (UTC)Reply[reply]
I think it is useful to differentiate the names of predicate functions (returning a Boolean), and other functions. The current convention for predicate function is to use names like "is empty string" or "string starts with". When not returning a Boolean, I like the programming convention of using a noum (e.g. "distance between Earth and Sun on"), no need to use a verb ("calculate a distance between Earth and Sun on"). —Suruena (talk) 13:10, 2 September 2023 (UTC)Reply[reply]

Access from npm/pypi

Hi,

is there any plan to allow acces the wikifunctions from 3rd party code ?

for example using a npm package that could fetch function definitions and execute them locally ?


Julienb42 (talk) 11:33, 29 August 2023 (UTC)Reply[reply]

I very much hope that such libraries will develop. It is not likely that the development team will be tackling that task. --DVrandecic (WMF) (talk) 02:54, 30 August 2023 (UTC)Reply[reply]

Type for morphological function

There has been some discussion and wondering about the types a morphological function should take. For example, in the Beta, we have the following functions:

All of these functions take a string and return a string. Now one could argue that they really should take a monolingual text and return a monolingual text.

There are several points to consider:

  1. first, history: why do we have a monolingual text? It's an idea I carried over from Wikidata, and for Wikidata we had carried that over from RDF, where it is called a language-tagged string.
  2. the advantage of monolingual texts come in particular from their role in a multilingual text, where we can select a specific language from a dictionary with several languages.
  3. stronger typing usually avoids certain mistakes. It is usually a really good idea to type, for example, numbers and dates, in order to avoid adding them up in a meaningless way. Personally I have a bias towards stricter typing, as you can see. And yet I find myself wondering if it makes sense in this case: what kind of errors would we be able to avoid by this stricter typing? What kind of helpful hints do we give to the users by using this stronger typing? I am a bit of a loss here, I am not sure I see an immediate advantage.
  4. if a function such as "English plural" has the input type "Monolingual text", this would mean that everyone using that function needs to, in addition to enter the word they want to pluralize (e.g. "book"), also enter the language, i.e. English. But how useful is that? What if it is a different language? What's the point of forcing the user to select that every time?
  5. in the end, the implementations would probably be something like "check if this is the right language(English) -o- get the string from the monolingual text -o- do the actual string manipulation -o- package it as a monolingual text(English)". So we would likely have a string-based function to do the string manipulation anyway, in addition to the one based on monolingual text?
  6. but the representations of the forms of the Lexemes in Wikidata will all be coming as monolingual text, so having the same type seems an advantage when we tie together with Wikidata for the natural language generation?
  7. I guess for each of those functions, we would simply ensure that they have the right language, raise an error. That seems again not particularly friendly: why ask for the language then at all?
  8. a minor advantage is that we could start right away with morphological functions and don't need to wait for the monolingual text type to become properly supported.

Particularly Point 4 is giving me a headache, and gently nudging towards "let's just use strings for morphological functions".

I would like to get input from the community on this question. In particular calling @Mahir256 who I know is interested in that question, but I sure hope there are others. I honestly don't know what the best approach is. I am also happy to answer any further questions to help with the decision finding. -- DVrandecic (WMF) (talk) 03:23, 30 August 2023 (UTC)Reply[reply]

This is far outside my expertise, and I'm monolingual to boot, but I'm still building a multilingual tool (wikidata:Wikidata:Entity Explosion) which I hope will use some of these string functions in future. I would expect that in the long term we will want both a monolingual and a string version. I agree with you in #5 that one will often wrap the other. One thing you haven't mentioned above is that the monolingual version will also require/ensure a single script system, so we won't get mishmashes like (Greek)'βιβλίο'+(Latin)'s'. I imagine there would be an advantage to some calling functions to be able to assume that the output was in the script/language they expected, without having to do a subsequent check. So the bit you described as "package as a monolingual text" may be doing some heavy lifting? But other reusers would be more carefree and could just call the general string version if they didn't really care what came back (or if they knew they had already sanitised their input). --99of9 (talk) 01:05, 31 August 2023 (UTC)Reply[reply]
What I can come up with as cases when languages are mixed in when the subject of the article is a specific language. Then there might be cases where we use some "plural" descriptor/constructor and it’s not really the same language as the default rendering language and we might have to use a specific function instead of the "default" renderer for the language, and we might be happy if there an error because we mixed-up stuff.
What seems sure is that if we have a function "english plural" it could be useful to have just a function "plural", generic to all languages and selects the good function according to the language tag. If we do this it’s pretty certain that we always selects the right function for the language, so usually few possibilities of errors. Maybe there are some cases where we get a random lexeme from a query from Wikidata and, for some sophisticated language generic situation, stuffs become mixed up and we end up calling a renderer for this lexeme and the languages do not match, however.
It’s probably irrelevant (and a rabbit hole), but this switching functions according to types reminds me of the notion of "dependant types" : https://cstheory.stackexchange.com/questions/33984/dependent-types-and-compile-time-types , where the type system can do sophisticated stuffs like selecting a type according to a runtime value and do sophisticated verifications, but I believe it’s hard to get to such sophistication in the Wikifunction case. Is Wikifunction type system sophisticated enough to be able to express some kind of useful specification to the code ? And how will implementations handle this ? I guess it could be interesting at the implementation level if the typing helps us to guarantee that some situations never occurs to simplify the implementation, which could be a win. This is an interesting stuff to think about because Wikifunction always have an intermediate step between nested function call, however, putting verifications at that step. If the implementation indeed are correct and respects the typing contracts, everything should be fine. TomT0m (talk) 18:06, 31 August 2023 (UTC)Reply[reply]
I guess an answer for 4 to not force everyone to enter a tag would be that the UI (and the type system?) is aware of the type "English string" and in this case just selects the right tag for the value. You then have a widget that just asks for the string and just adds automatically the tag to the value. TomT0m (talk) 18:12, 31 August 2023 (UTC)Reply[reply]
Personally, I think that since the name of the function is "English plural", the function will only be called in an English context and the input and output parameters should simply be strings. A multilingual function, perhaps "plural", would use monolingual text and would then call "English plural" in the English case, "pluriel français" in the French case etc., but once the language is determined, strings are better. Using monolingual text in the English case adds complexity and I do not think there is much advantage - it can only add checks for cases which should never occur, as you have to get the context right anyway. There is a general feeling that stronger typing is more virtuous, but I think that that is not always true. Strobilomyces (talk) 12:11, 19 September 2023 (UTC)Reply[reply]

separation of functions, implementations and tests?

I wonder why these three are not separated into different namespaces. They seem to be clearly delineated, and I imagine we will later want to search them separately. I'm sure there are technical reasons I haven't considered, so if anyone knows them, I'm interested to hear. --99of9 (talk) 00:28, 31 August 2023 (UTC)Reply[reply]

Function exists?

Tracked in Phabricator:
Task T285424

How can I know if a function already exists? Search bar at the top is utterly broken: no functions/implements/test cases (or, any ZObjects) can be found by name via it. Sometimes I attempted to create a def for a new function, but when I publish it, the system tells me that a function with the same label in the same language already exists (clashing). This is quite a problem, as users tend to create several objects with the same function if we don't know if it had been created by someone else. -- U.T. 06:51, 31 August 2023 (UTC)Reply[reply]

@Unite together: Thanks for your report. There's already an open bug on Phabricator, if you see something is missing, please edit it accordingly or suggest me the proper integrations here, so that I could add them to the ticket. Thanks! --Sannita (WMF) (talk) 09:12, 31 August 2023 (UTC)Reply[reply]
@Unite together: While the automatic search doesn't work, it does work when pressing enter (or using Special:Search directly). This will match both labels and aliases in any language, but not substrings. /Autom (talk) 10:44, 31 August 2023 (UTC)Reply[reply]

Nearby

Tracked in Phabricator:
Task T345459
Tracked in Phabricator:
Task T345463

Hi,
project has Special:Nearby for geographical coordinates with button Nearby in mobile version (in the collapsible sidebar: press ☰). If it's not needed (?), should it be removed or replaced?
I also want to note that banners (for example, Wikifunctions is a new project by...) are visible only in the desktop version. Proeksad (talk) 20:20, 31 August 2023 (UTC)Reply[reply]

I think the button is unnecessary now and can be removed. Alternatively, it might be possible to create a parallel feature that would allow you to select functions that receive coordinates as input (how will we find them all? This is a future question), and that accessing them through this button would input the user's location. · מקף Hyphen ෴ · 21:17, 31 August 2023 (UTC)Reply[reply]
Thanks, I've filed phab:T345459 to change that configuration to remove Nearby, and phab:T345463 to enable Sitenotice here. Quiddity (WMF) (talk) 18:25, 1 September 2023 (UTC)Reply[reply]

Editing sandboxes

I see Wikifunctions:Sandbox is open to editing for all editors, but as of before getting functioneer, the sandboxes listed there (e.g. Sandbox-Function (Z10119), the function sandbox) did not allow editing unless you have the right user access group. Is this intended? Skarmory (talk) 05:48, 1 September 2023 (UTC)Reply[reply]

I think it’s an issue where you can’t let everyone edit a function (yet), only functioneers. Zippybonzo (talk) 10:56, 3 September 2023 (UTC)Reply[reply]

Wikifunctions & Abstract Wikipedia Newsletter #125 is out: Wikimania digest, CoSMo language, GFpedia demo, CCKS keynote

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

In this issue, we recap what happened at our sessions at Wikimania 2023, we talk about some new updates regarding our Natural Language Generation special interest group (NLG SIG), and we briefly speak about Denny's most recent keynote speech.

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

Enjoy the reading! -- User:Sannita (WMF) (talk) 10:35, 1 September 2023 (UTC)Reply[reply]

Object annotations

Hi, I think it would be very useful and powerful to "annotate" with extra information each kind of object, for example:

  • type: granularity, range, modulo, holes, physical units, measurement scale (nominal, ordinal, interval, ratio)...
  • function: pre-conditions, post-conditions...
  • implementation: computational complexity, space complexity, algorithm used...
  • test: nominal / robustness / boundary test, autocoded test...

Of course these are just examples, and it can be argued whether each one should be available or not, but the general capability to add this "semantic information" that can be used by different tools (e.g. tools to check if every function is tested with both nominal, boundary, and robustness tests). Maybe "keys" can already be used to annotate objects with these different annotation, or otherwise we can use templates in the talk pages temporally until Wikifunctions support this concept. Do you think keys can be used for that? Which additional annotations do you think can be added? Thanks! —Suruena (talk) 09:11, 2 September 2023 (UTC)Reply[reply]

Creating types

Hi, I just created the function is leap year (Gregorian calendar) (Z10996), but even if the input type should be a "year" (specifically a Gregorian year), as currently I think it's not possible to create a new type (tried creating year (Z11002) but not really a type, and I have not permissions to create an actual type) so I used instead directly a String (because numbers are not allowed yet either...). Even if this works for now, I think that in the future it would be needed to modify the function to use a proper type instead (for example, annother function is needed if the year follows the Julian calendar instead of the Gregorian calendar). I assume that new Types cannot be created by everybody, but only by admins because need to be agreed by the community (like the Wikidata properties). In my opinions each function should be as precise as possible regarding the types expected and returned, so users known clearly what to expect from the functions and to simplify implementations. Can anybody confirm if types are expected to be created just by admins? In any case, I propose to create a dedicated template like template:new type to temporally annotate those functions that should use a different type not available yet. Opinions? Thanks —Suruena (talk) 09:29, 2 September 2023 (UTC)Reply[reply]

As far as I know, at the moment, Wikifunctions only support passing strings and bools to functions. Eventually it will be possible to define and pass any type. Creating functions dealing with other types is not recommended now and such existing ones are marked usually with (!) at the beginning of its name.
Currently, only staff can create new types but according to mw:Help:Wikifunctions/User rights, the ability will be eventually given to all functioneers. Msz2001 (talk) 13:58, 2 September 2023 (UTC)Reply[reply]
@Suruena Hey, sorry for replying this late to your message. I suggest you to use Wikifunctions:Suggest a function in cases like this, so that we can take note of what type we should be focusing on more when developing the new types. Sannita (WMF) (talk) 15:59, 5 September 2023 (UTC)Reply[reply]

Unable to edit Z868

Tried to edit String to list (Z868) but was unable to do so as it does not have a return type set (and I could not set it to be anything; it appears to return a list of code points). Can anyone help with this? ネイ (talk) 11:38, 2 September 2023 (UTC)Reply[reply]

Also there seems to be a bug with the Discussion Tool. On Talk:Z868 the sentence generated by Discussion Tool reads as follows (the span tag is shown): "You can use this page to start a discussion with others about how to improve String to list (<span dir="ltr">Z868</span>)." ネイ (talk) 11:39, 2 September 2023 (UTC)Reply[reply]
Thanks for reporting! The DiscussionTools bug is tracked at phab:T344491. Quiddity (WMF) (talk) 19:42, 8 September 2023 (UTC)Reply[reply]
It's missing an Output type, because the appropriate List type isn't supported yet. This Object (and similar ones) will be fixed by the development team once the relevant types has been finalized. See more context at Wikifunctions:Status#Only String and Boolean types are supported. I hope that helps. Quiddity (WMF) (talk) 19:45, 8 September 2023 (UTC)Reply[reply]
Thank you for the pointers! Will wait and see whether they get resolved. ネイ (talk) 08:38, 10 September 2023 (UTC)Reply[reply]

Blocking policy?

Hello all. I will like to propose to introduce a local blocking policy (link). The page is largely based of its common's counterpart. CU & OS subsections can be commented out as we're likely not gonna have any local CU/OS anytime soon. Comments? Minorax (talk) 08:08, 3 September 2023 (UTC)Reply[reply]

Seems good, we might end up with CU and OS so just leave that section as draft I would say. Zippybonzo (talk) 10:55, 3 September 2023 (UTC)Reply[reply]
Support Support with the removal of the CU/OS sections and explicit mentions, the policy makes sense however I strongly disagree that they should be left as drafts since this is likley to just add to confusion and will imply that CU/OS blocks are local since they are on the local policy page. There is nothing stopping such sections just being added through discussion in the future. Terasail[✉️] 11:36, 3 September 2023 (UTC)Reply[reply]
👍 · מקף Hyphen ෴ · 12:11, 3 September 2023 (UTC)Reply[reply]
I Support Support generally, but I think it should include how would we handle the situation of a global block that needs to be whitelisted locally and users who need the ipblock-exempt permission. Also, I suggest removing the part of CU/OS as well. Xnet1234 (talk) 19:29, 3 September 2023 (UTC)Reply[reply]
It seems better to exclude CU/OS block. When it is necessary to introduce it, it can be introduced either through a separate RFC or by forming a consensus. I agree with the rest. --Sotiale (talk) 11:34, 4 September 2023 (UTC)Reply[reply]
Support Support with removal of CU/OS --Ameisenigel (talk) 17:06, 4 September 2023 (UTC)Reply[reply]
Support Support with removal of CU/OS for now. Koavf (talk) 06:24, 9 September 2023 (UTC)Reply[reply]

Translation Administrator requirements

There are currently no local or Meta-Wiki requirements for Translation Administrator and the guidelines currently listed at Wikifunctions:Translation administrators#Requirements are currently pulled from Administrator requrements in order to have a baseline for steward requests. This will be unique to Wikifuntions since all other projects rely on bureaucrats to decide when to grant TA. I am proposing that Wikifunctions replaces what is currently listed and adds the following requirements:

  • Create a new discussion section requesting the user group at Wikifunctions:Requests for user groups#Translation administrator.
  • Allow 1 week for any discussion.
  • The candidate must obtain at least 2/3 (two thirds) support.
  • Present a sample edit to demonstrate your practical experience with the translation syntax (Suggestion from Minorax)

This should clear things up since the active guidelines were never considered by the community and just added by myself which shouldn't stand for a long period of time.

Do you think this is a positive change and do you have any thoughts? Terasail[✉️] 11:57, 3 September 2023 (UTC)Reply[reply]

Seems fine. However, I'd like the requester to have an example of how they would use the tool if granted (similar to the requirements on meta). Minorax (talk) 13:36, 3 September 2023 (UTC)Reply[reply]
That is a good idea, I had not thoroughly read through the Meta-Wiki policy but "Present a sample edit to demonstrate your practical experience with the translation syntax" is a good idea. I will add it above, Thanks. Terasail[✉️] 16:15, 3 September 2023 (UTC)Reply[reply]
Looks good to me --Ameisenigel (talk) 17:06, 4 September 2023 (UTC)Reply[reply]
I have added these changes to Wikifunctions:Translation administrators Terasail[✉️] 16:02, 22 September 2023 (UTC)Reply[reply]

Search issues

I think we should make search search for functions instead of mainspace because the current search is really hard to use to the point where it is nearly impossible to use. Zippybonzo (talk) 15:39, 3 September 2023 (UTC)Reply[reply]

There's currently a bug with the inline autocomplete search (not showing any results), but if you click [enter] or the "Search" button it should give full search results. See the similar thread #Function exists? above.
If I've misunderstood which issue you're describing, please clarify further. Thanks! Quiddity (WMF) (talk) 18:57, 8 September 2023 (UTC)Reply[reply]

Function maintainer requirements

I am proposing the following local requirements for the Wikifunctions:Maintainers group:

I will provide any reasoning for my individual points upon request, but it's mostly to ensure only trusted and experienced users can have the right to ensure that nothing gets broken accidentally. Zippybonzo (talk) 10:38, 4 September 2023 (UTC)Reply[reply]

I think it is a bit too early to be setting out maintainer requirements, considering that the maintainer group has yet to be utilized. Currently only WF Staff can give out the maintainer group and with WF still in limited roll out, we should not be restricting what the staff wish to do with such a role until the group is handed over to the community to manage. On another note, these requirements are currently higher than the requirements to get administrator so that isn't great either. Terasail[✉️] 10:49, 4 September 2023 (UTC)Reply[reply]
I agree with Terasail that it might be too early to define these requirements --Ameisenigel (talk) 17:08, 4 September 2023 (UTC)Reply[reply]
It'd still be worth keeping this in mind for when group assignments are handed over to the community. Deauthorized (talk) 07:07, 5 September 2023 (UTC)Reply[reply]

Help please

Tracked in Phabricator:
Task T346006

I was trying to implement a test for choose from comma-separated list (Z10601), and struggled with the current capabilities of the interface. One idea I had was English days all end in "day" (Z11042), which I had to put in as a test of string ends with (Z10618), even though it's secretly also testing the random selector. But English days all end in "day" (Z11042) won't even do that, as it says I still have to "select function". But if you open the dropdown for the call, then the dropdown for the text, you'll see that I have selected it. So I think there's a bug, but am also struggling with how to make tests for this kind of function. --99of9 (talk) 01:32, 8 September 2023 (UTC)Reply[reply]

Oh yeah, that is weird. Can confirm it shows up when editing the function. -wd-Ryan (Talk/Edits) 15:02, 8 September 2023 (UTC)Reply[reply]
Tracked in Phabricator:
Task T346296
I'm not sure why I missed this before, but I've now found a simple way to do the same test on the function I was trying to test. choose a day of the week ending in "day" (Z11088). Nevertheless, I still don't see anything wrong with English days all end in "day" (Z11042), and the runtime error messages there confuse me. --99of9 (talk) 00:48, 12 September 2023 (UTC)Reply[reply]

Wikifunctions & Abstract Wikipedia Newsletter #126 is out: Let's start building morphological paradigms!

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

In this issue, Denny proposes a call for action for creating morphological paradigms on Wikifunctions.

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

Enjoy the reading! -- User:Sannita (WMF) (talk) 19:25, 10 September 2023 (UTC)Reply[reply]

Aliases of a function name

Tracked in Phabricator:
Task T326304
Tracked in Phabricator:
Task T345301

I've tried to enter aliases for a function name. After saving and then reopening, I couldn't see them anywhere, so this seems to be a missing feature. Have I missed something? Is this already tracked? --99of9 (talk) 06:30, 13 September 2023 (UTC)Reply[reply]

@99of9: After entering one alias, make sure you still have that text box highlighted, and press enter. Repeat for the next alias and save the page.
I have made the same mistake embarrassingly often but it has a ticket on the bug tracker. /Autom (talk) 10:42, 13 September 2023 (UTC)Reply[reply]
Thanks, I'll remember that! --99of9 (talk) 10:48, 13 September 2023 (UTC)Reply[reply]
I thought I would too, but still have edit comments like this. /Autom (talk) 10:53, 13 September 2023 (UTC)Reply[reply]
I don't blame you, it isn't clear at all that it isn't just comma-separated. -wd-Ryan (Talk/Edits) 13:40, 13 September 2023 (UTC)Reply[reply]

Gateway timeout. Is Wikifunctions overloaded already?

I wrote a composition implementation of string is element of CSV (Z11094), and have noticed that the simple test cases often timeout. The composition requires quite a few sub-calls, but nothing is inherently computationally expensive. Since I'm currently the only editor in recent changes, I seem to be stressing WF on my own!? Is scalability going to be a big issue? --99of9 (talk) 01:33, 14 September 2023 (UTC)Reply[reply]

@99of9: Thanks much for calling attention to this. I see there was a flurry of RequestTimeoutException during August 24-28, then none of those until September 14, when some more of them occurred. We will continue to monitor this. One question: when you observed these timeouts, did the UI show you an explicit timeout error message? (If so, and if you see it again, please copy it to here.) Thanks! DMartin (WMF) (talk) 04:23, 15 September 2023 (UTC)Reply[reply]
@DMartin (WMF): Yes, I can still reproduce it. Go here, then if any of the top three tests fail with an X, click details. In my case I see the second test failing, then get the following details:

composition of substring tests

string split across two elements is not an element

Error summary: [Z507/Error in evaluation] {"Z1K1":"Z7","Z7K1":{"Z1K1":"Z8","Z8K1":["Z17",{"Z1K1":"Z17","Z17K1":"Z6","Z17K2":"Z11094K1","Z17K3":{"Z1K1":"Z12","Z12K1":["Z11",{"Z1K1":"Z11","Z11K1":"Z1002","Z11K2":"string"}]}},{"Z1K1":"Z17","Z17K1":"Z6","Z17K2":"Z11094K2","Z17K3":{"Z1K1":"Z12","Z12K1":["Z11",{"Z1K1":"Z11","Z11K1":"Z1002","Z11K2":"comma-separated value series"}]}}],"Z8K2":"Z40","Z8K3":["Z20","Z11095","Z11097","Z11100","Z11106","Z11107","Z11108","Z11109","Z11110"],"Z8K4":["Z14","Z11099"],"Z8K5":"Z11094"},"Z11094K1":"day,Wed","Z11094K2":"Monday,Tuesday,Wednesday,Thursday,Friday,Saturday,Sunday"} Validator error summary: [Z507/Error in evaluation] Expected result: {"Z1K1":"Z40","Z40K1":"Z42"} Actual result: {"Z1K1":"Z5","Z5K1":"Z507","Z5K2":{"Z1K1":{"Z1K1":"Z7","Z7K1":"Z885","Z885K1":"Z507"},"K1":"{\"Z1K1\":\"Z7\",\"Z7K1\":{\"Z1K1\":\"Z8\",\"Z8K1\":[\"Z17\",{\"Z1K1\":\"Z17\",\"Z17K1\":\"Z6\",\"Z17K2\":\"Z11094K1\",\"Z17K3\":{\"Z1K1\":\"Z12\",\"Z12K1\":[\"Z11\",{\"Z1K1\":\"Z11\",\"Z11K1\":\"Z1002\",\"Z11K2\":\"string\"}]}},{\"Z1K1\":\"Z17\",\"Z17K1\":\"Z6\",\"Z17K2\":\"Z11094K2\",\"Z17K3\":{\"Z1K1\":\"Z12\",\"Z12K1\":[\"Z11\",{\"Z1K1\":\"Z11\",\"Z11K1\":\"Z1002\",\"Z11K2\":\"comma-separated value series\"}]}}],\"Z8K2\":\"Z40\",\"Z8K3\":[\"Z20\",\"Z11095\",\"Z11097\",\"Z11100\",\"Z11106\",\"Z11107\",\"Z11108\",\"Z11109\",\"Z11110\"],\"Z8K4\":[\"Z14\",\"Z11099\"],\"Z8K5\":\"Z11094\"},\"Z11094K1\":\"day,Wed\",\"Z11094K2\":\"Monday,Tuesday,Wednesday,Thursday,Friday,Saturday,Sunday\"}","K2":{"Z1K1":"Z5","Z5K1":"Z500","Z5K2":{"Z1K1":{"Z1K1":"Z7","Z7K1":"Z885","Z885K1":"Z500"},"K1":"Gateway Timeout"}}}}

--99of9 (talk) 11:31, 17 September 2023 (UTC)Reply[reply]

@99of9:, thanks! Using your instructions, I saw the same error myself 2 or 3 times during the last couple days, but today it's not occurring for me, plus the tests seem to finish considerably faster. Afraid I can't explain the improvement, but will continue to monitor. In the meantime, your implementation page has brought to light a bad bug: after clicking on any of the Details links, the page freezes. I can't do anything else until I refresh the tab. I'm wondering if this is specific to my OS/browser combination. Have you also seen this behavior?
DMartin (WMF) (talk) 05:28, 21 September 2023 (UTC)Reply[reply]
@DMartin (WMF): Yes, that happens to me too at the moment. I can't remember if it was different before. --99of9 (talk) 05:52, 21 September 2023 (UTC)Reply[reply]

Page on Wikidata about interoperation with Wikifunctions

Heads up that I created a barebones page at d:Wikidata:Wikifunctions, as all the other sister projects have similar such pages. It would be great if users here who are motivated to figure out how the two projects can work together would help flesh out that page. Thanks. ―Justin (koavf)❤T☮C☺M☯ 08:28, 14 September 2023 (UTC)Reply[reply]

@Koavf Thank you very much! Sannita (WMF) (talk) 12:22, 15 September 2023 (UTC)Reply[reply]

Next Wikifunctions & Abstract Wikipedia Volunteer's Corner on Monday 18

Hello all, this is a brief reminder that the next Wikifunctions & Abstract Wikipedia Volunteers' Corner will be held on September 18 at 17:30 UTC.

If you have questions or ideas to discuss, or you want to get in touch with the dev team, please join us! We will also hold a live demo on how to create a function.

The meeting will be held, as usual, on Jitsi at the following address: https://meet.jit.si/AWVolunteersCorner.

See you there! -- Sannita (WMF) (talk) 12:25, 15 September 2023 (UTC)Reply[reply]

Can categories be added to main namespace pages?

This project doesn't use categories at all in the main namespace. Consequently, special pages like Special:UncategorizedPages become useless because they are flooded by entries. Is it possible on a technical level to add something like Category:All functions to just make one category that all of these are in to clear out that special page into something that can be reasonably used? If that is not possible locally, is there at least consensus to make a ticket at phab: for this feature? ―Justin (koavf)❤T☮C☺M☯ 06:04, 17 September 2023 (UTC)Reply[reply]

I think it's better to configure Wikifunctions with the settings of Wikidata as the concept is the same. Minorax (talk) 06:52, 17 September 2023 (UTC)Reply[reply]
The same problem exists on Wikidata. ―Justin (koavf)❤T☮C☺M☯ 07:47, 17 September 2023 (UTC)Reply[reply]
@Koavf: Unfortunately, the "categories" system in MediaWiki is a wikitext-exclusive feature. There has been discussion for over a decade about changing this (e.g. as part of T112999 and other broad topics), for which I've gently lobbied, but it'd cost a awful lot to change over to a proper system[1] for marginal use cases[2], so hasn't been seriously explored.
There's an existing, much simpler, feature request at T305363 to provide a way to hide non-wikitext pages from such listings, but I'd just recommend you not waste time looking at them.
  1. ↑ I'd roughly guesstimate a couple of years and a few million US$ in development cost, and maybe a tenth of that for new servers/etc. depending on desired feature set. Requested features like T5311 would become possible, but would also add to the cost, for example.
  2. ↑ To be clear, marginal use cases for Wikipedias, which dominates general MediaWiki development discussions; obviously here on Wikifunctions, or over on Wikidata, this would have immediate utility, plus also on Gadgets' pages etc..
    3. Jdforrester (WMF) (talk) 11:26, 18 September 2023 (UTC)Reply[reply]
    Thanks, JD. That's a little disheartening, but good to know. Very thorough response. ―Justin (koavf)❤T☮C☺M☯ 12:43, 18 September 2023 (UTC)Reply[reply]

    Will python or javascript functions be able to call other wikifunctions?

    I hope so. Can they already? --99of9 (talk) 03:45, 18 September 2023 (UTC)Reply[reply]

    Eventually yes, but it's not a superurgent feature for us right now. -- DVrandecic (WMF) (talk) 00:17, 23 September 2023 (UTC)Reply[reply]

    Wikifunctions & Abstract Wikipedia Newsletter #127 is out: Renderers and parsers for types

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

    In this issue, Denny introduces a discussion about how to represent integers on Wikifunctions and its related challenges.

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

    Enjoy the reading! -- User:Sannita (WMF) (talk) 08:07, 22 September 2023 (UTC)Reply[reply]

    Retrieved from "https://www.wikifunctions.org/w/index.php?title=Wikifunctions:Project_chat&oldid=54427"