Wikifunctions:Project chat/Archive/2025/09

Next Wikifunctions & Abstract Wikipedia Volunteers’ Corner is tomorrow!

We remind you that our next Wikifunctions & Abstract Wikipedia Volunteers’ Corner will be tomorrow, September 8, at 17:30 UTC (link to the meeting).

Unless you have many questions, we will follow our usual agenda, giving updates on the upcoming plans and recent activities, having plenty of time and space for your questions, and building a Function together.

See you at the Corner! -- User:Sannita (WMF) (talk) 13:39, 7 September 2025 (UTC)

This section was archived on a request by: Sannita (WMF) (talk) 21:25, 21 September 2025 (UTC)

Wikifunctions & Abstract Wikipedia Newsletter #216 is out: Copying function calls from one Wikipedia to another

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

In this issue, we announce that it is now possible to use natural languages as a default value in embedded function calls, we discuss the latest news in Types, 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) 16:04, 8 September 2025 (UTC)

This section was archived on a request by: Sannita (WMF) (talk) 21:25, 21 September 2025 (UTC)

Wikifunctions & Abstract Wikipedia Newsletter #217 is out: More than 3,000 functions on Wikifunctions

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

In this issue, we celebrate reaching the milestone of 3,000 functions on Wikifunctions, we discuss our upcoming commitments in outreach, we share with you our latest blogpost, 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) 18:21, 12 September 2025 (UTC)

This section was archived on a request by: Sannita (WMF) (talk) 21:25, 21 September 2025 (UTC)

Wikifunctions:Human languages reorganisation

There is a discussion at Wikifunctions talk:Human languages#Updating the list about a remake of the page; I am posting here to increase the discussion's visibility. Xeroctic (talk) 15:32, 3 September 2025 (UTC)

Decision tables for natural language generation

I like tables and spreadsheets and I have looked at Wikifunctions:Abstract Wikipedia/2025 fragment experiments and I have thinked about what can help writing the functions and especially understanding the rules before. One possibility for such a thing are decision tables. I have created a subpage of my user page with an example. The basic idea is writing down known variants of a specific type of sentence and then thinking about the rules what change the output. For every property new columns are added to the table. There are historic examples of programming languages based on decision tables. A programming language I looked at a bit was the experimental programming language DETAB-X. Do you think the approach with using decision tables can help by creating implementations for other natural languages. Hogü-456 (talk) 20:48, 3 September 2025 (UTC)

@Hogü-456: I don't quite understand what the value of this kind of table would be. Won't there be hundreds of rows for even the most trivial fragment? Who would be helped by this? Shouldn't the entries instead be Test cases for the individual Functions? Jdforrester (WMF) (talk) 21:19, 3 September 2025 (UTC)

The decision table in the example is complete for this specific kind of fragment. It is the german version of Z26043. I think writing the rules down in such a structured way can help when creating the function. It is a tool to use before creating the function to get an overview about what to pay attention to when implementing it. There are also fragments with many rules and so there are limitations of it. After creating the function it is necessary to create Test cases to look if the function does work as expected. I will try to explain it more at the subpage of my user page. This can help people understanding how to use it. Hogü-456 (talk) 19:45, 4 September 2025 (UTC)

Is developing a general conjugation function possible?

Hello, I mainly contribute to the French Wiktionary and I am currently exploring Wikifunctions. I noticed that you have a Conjugate être (Z21599) function. Looking at the code, I see that all forms are hard-coded. This is a shame, because all the forms are already present on Wikidata : L1882.

So my first question is, why does not this function use Wikidata lexeme?

More generally, some contributors to the French Wiktionary have experimented with the Wikidata lexeme trying to develop modules that would use this data. The main issue is that calling data from Wikidata requires setting the Lexeme-ID, which is highly not user-friendly at all, because the wikicode becomes highly cryptic.

My second question is about this problem. Would it be possible to develop a function that would generate the conjugation (are anything else using the Wikidata lexeme forms) of any French verbs? For example a function that would take only two inputs: the name of the verb (for example "être") and the language (for example "fr/French")? Pamputt (talk) 06:00, 2 September 2025 (UTC)

Hi, I concur to what Pamputt said, AFAIK right now it’s impossible to associate lexeme IDs to wiktionary pages, so we have to manually indicate them in the wikitext if we want to use their data. And to answer your second question, I already developped a Lua module on frwikt that does exactly that, it’s just no deployed yet. Maybe it could be ported here, but there is a lot of code and associated data. — Danÿa (talk) 11:11, 2 September 2025 (UTC)

As a side note, the “futur antérieur” forms in the JS implementation of Z21599 are incorrect. I would have fixed them myself but I don’t have the required perms. — Danÿa (talk) 12:01, 2 September 2025 (UTC)

Thanks for pointing that out. I hope I’ve fixed them correctly! GrounderUK (talk) 12:41, 2 September 2025 (UTC)

That’s perfect :) — Danÿa (talk) 16:42, 2 September 2025 (UTC)

Sorry for replying in reverse order. I think linking Wiktionary pages to Wikidata lexemes is just a hard problem. Wikidata lexeme reference to string (Z19310) may be of some use when using the visual editor on a Wiktionary that supports embedded functions. For example,

{{#function:Z19310|L1882}}. "L1882"? {{#function:Z27423|L1882}}

evaluates to « L1882. "L1882"? être ». I never needed to type in "L1882", but this lookup is only available in the embedded functions editor (or in the Wikifunctions object editors).

The more general case of finding a lexeme given some text is not currently possible using Wikifunctions. We can’t even find all the lexemes with representations (of forms) equal to some string… yet. We are reliant on the development team for this sort of capability and, as far as I can tell, it is not currently planned. GrounderUK (talk) 15:12, 2 September 2025 (UTC)

It’s an historical artifact, I believe. When Wikifunctions integration with Wikidata began, it always failed for L1882 (fr) être. We can implement a new version at any time but I’ve been waiting for a consensus on Wikifunctions:Type proposals/French tenses.

We now have types for Grammatical gender (m/f) (Z25340) and Grammatical number (singular / plural) (Z26934), but we need grammatical tense before we can define a conjugation properly. Ultimately, we should be able to return a full conjugation given only a lexeme reference (similar to Latin first declension table (Z26333), but with no hardcoded text).

I support the principle of specifying lexemes using strings in a particular language and I’m happy to draft or comment on a Feature request for this to be supported, based on the discussion here. In the mean time, we can look at “perfectly regular” conjugation functions (like Conjugate regular -er verb (Z21617)), with a view to supporting the regular exceptions (like « payer »), accepting that we cannot determine whether a particular string represents an irregular verb, unless we hardcode the exceptions (or, at least, the mapping to the irregular verb’s lexeme reference). Even then, we’d still have the « ressortir » problem, but perhaps a text convention might address those odd cases? GrounderUK (talk) 14:27, 3 September 2025 (UTC)

Ultimately, we should be able to return a full conjugation given only a lexeme reference (similar to tableau de la 1e déclinaison en latin (Z26333), but with no hardcoded text).

When I opened this discussion, this was exactly what I had in mind. Technically, I am not sure to follow everything. Yet get a Lexeme data directly from a string would be very useful for readability. Pamputt (talk) 17:54, 3 September 2025 (UTC)

I think that this proposal could be relevant here. Dv103 (talk) 10:17, 6 September 2025 (UTC)

WikiProject Wiktionary functions

I've created the page Wikifunctions:WikiProject Wiktionary functions to coordinate the creation of functions specifically aimed at Wiktionary. Both contributors to Wikifunctions and Wiktionaries are invited. In particular, here is a proposal of the first function properly aimed at Wiktionaries. Dv103 (talk) 10:16, 6 September 2025 (UTC)

@Dv103:: Before we can sign off on Wikifunctions I would like my previous concerns to be addressed (i.e. demonstrating why this would be a substantial improvement over Lua). Maybe @Koavf and Juwan would be interested. But I appreciate your efforts here. Ioaxxere (talk) 04:51, 8 September 2025 (UTC)

Confirming interest, lamenting ignorance to be of any use. :/ ―Justin (koavf)❤T☮C☺M☯ 04:54, 8 September 2025 (UTC)

ditto with Justin. Juwan (talk) 10:45, 8 September 2025 (UTC)

I'll try to answer your previous concerns:

• The ability to write high-performance functions — ideally in a compiled language like C, not Python

As already answered, the performance issue is already mitigated through caching, that completely removes the necessity to run the code for each page rendering.

• The ability to call functions from within a template (say {{#invoke:wikifunction|Z12345|{{{input}}}}} or mw.wikifunction(Z12345, input) within Lua)

For now it's not possible.

• The ability to write reusable code, such as being able to create a helper function Z98765 and use it inside the other functions Z98766, Z98767, etc. with minimal performance overhead

This is already possible (as for the performance, consider the presence of caching) and one of the main advantages of Wikifunctions.

• (Ideally) the ability to access external data in a way equivalent to the mw.wikibase or mw.title APIs in Lua, and perhaps even directly query the database in a way similar to https://quarry.wmcloud.org/

For now not possible.

In general, I think that the main advantage of Wikifunctions is the centralisation of code, with a focus for small language editions of Wiktionary (considering that porting Lua modules and adapting them can become very difficult for small communities). Another great advantage is the possible integration with Wikidata, allowing the centralisation of data between language editions.

Consider for example the conjugation tables: now in the English Wiktionary there are lots of templates that handle the conjugation tables of various parts of speech of numerous languages, most of which require a manual input to handle all the possible conjugation patterns and all the irregolarities. With this proposal, instead, it could be possible to unify all those modules in a single Wikifunctions function, that automatically chooses the proper conjugation table (by language of the lexeme, part of speech and eventual other useful gammatical features) and fills it with the form taken from wikidata.

The idea being that, in order to create the conjugation table of the Latin verb placeō in a small-community Wiktionary language edition, instead of having to import the template la-conj and to call it through {{la-conj|2+.opt-semi-depon.noimp|placeō}} (having to read through the documentation to understand how to generate the specific conjugation pattern of this particular verb), it could be possible to write something like {{#function:Znnnnnn|L281501|}} (with both the search of the ZID of the function and the LID of the lexeme facilitated in the Visual Edit mode), with no other action needed by the local Wiktionary community.

Finally, for @Juwan and @Koavf, even if you don't have tecnical knowledge in coding, it's still very useful for us to understand what it is actually needed on Wiktionaries. Dv103 (talk) 18:07, 8 September 2025 (UTC)

Rohingya is missing a ZObject

Wikifunctions:Catalogue/Natural language operations/Rohingya exists, but there does not seem to be a ZObject for the Rohingya language (rhg). Xeroctic (talk) 14:19, 13 September 2025 (UTC)

@Xeroctic: Yes, there is no support for rhg in MediaWiki yet, and I don't see a task in Phabricator. Do you know if there is general demand for this, or is it specific to Wikifunctions? Jdforrester (WMF) (talk) 17:09, 15 September 2025 (UTC)

@Xeroctic: Sorry, that's not quite right; although MediaWiki itself doesn't support Rohingya, the cldr extension defines rhg-arab and rhg-rohg. I can add those both, if that's what's wanted? Jdforrester (WMF) (talk) 17:16, 15 September 2025 (UTC)

Both scripts have functions, so both of them could be added.

(small note: I am mainly asking this because on my Human languages page draft, Rohingya seems to be the only language without a ZObject which appears in the Catalogue) Xeroctic (talk) 17:48, 15 September 2025 (UTC)

@Xeroctic: I've created https://gitlab.wikimedia.org/repos/abstract-wiki/wikifunctions/function-schemata/-/merge_requests/271 with Z1978 for rhg-rohg ( 𐴌𐴟𐴇𐴥𐴝𐴚𐴒𐴙𐴝 ) and Z1979 for rhg-arab (رُحَ࣪ڠۡگَ࣪ࢬ عَرࣤبِي لࣦكَ࣪), which should land this week and so get deployed next week. (I'm not sure that the copied Arabic is correct, but we can fix that on-wiki later if needed.) Jdforrester (WMF) (talk) 17:44, 17 September 2025 (UTC)

Now it has been added, I have added both codes to my languages list. Xeroctic (talk) 19:29, 25 September 2025 (UTC)

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

Python outage

Please see phab:T404797. This topic is about system resilience. We generally aim to have implementations in both JavaScript and Python, although some functions can only be implemented as compositions. A complete failure in Python is generally less severe than the equivalent in JavaScript, because function evaluations use the “preferred” implementation, which generally turns out not to be one in Python.

There is a Wikifunctions:Catalogue of functions and implementations that has not been updated at all this year. It would be good to have something more like List of Functions filtered by their Tests, allowing us to identify any functions that lack an implementation in one language or another. GrounderUK (talk) 12:10, 17 September 2025 (UTC)

@GrounderUK: TT73 created that page in the past but isn't active any more; maybe it should be deleted?

For the feature request, this is mentioned in passing in phab:T359672 ("Provide a list of Functions that lack an implementation in a given programming language."), and I'll spin out your request to a sub-task. Jdforrester (WMF) (talk) 17:40, 17 September 2025 (UTC)

Thanks. I knew it was loitering around somewhere! phab:T404897

GrounderUK (talk) 18:00, 17 September 2025 (UTC)

While the page continues to exist (and is linked to from the Catalogue), there’s always the chance that someone will update it. There have been questions about it, from time to time. GrounderUK (talk) 18:09, 17 September 2025 (UTC)

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

Wikifunctions & Abstract Wikipedia Newsletter #218 is out: Wikifunctions available on 123 Wiktionary languages

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

In this issue, we update you on the recent Wikifunctions deployment on Wiktionaries, we introduce our new page for requesting cleanups, we update you on what's new on Types, we remind you of the upcoming 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 the next Natural Language Generation Special Interest Group meeting will be held on September 23, at 16:00 UTC (link to the meeting).

Enjoy the reading! -- User:Sannita (WMF) (talk) 15:26, 20 September 2025 (UTC)

Thank you! Emilia Noah (talk) 12:25, 23 September 2025 (UTC)

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

Wikifunctions & Abstract Wikipedia Newsletter #219 is out: Accessing qualifiers in Wikidata statements

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

In this issue, we introduce the possibility of calling also qualifiers from Wikidata, we update you on the recent deployments of Wikifunctions and on the Wikifunctions presentations at Wikimedia events, we give you the recent updates on Types, 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:46, 26 September 2025 (UTC)

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

Color type available for testing

We published a new type RGBA color (Z28579) based on the type proposal for RGBA color. We would like to invite gentle testing. Let us know if you find issues. --DVrandecic (WMF) (talk) 19:43, 29 September 2025 (UTC)

I've put together some basic read and display functions. They currently just handle 32-bit representations, but will be further improved and can be configured.

• read RGBA color (Z28624)
• display RGBA color (Z28650)

99of9 (talk) 03:29, 3 October 2025 (UTC)

Given that there is no outcry about this suggestion, and it improves the usability of that type, I have connected it. Thanks for providing the functions! I recognize the mentioned limitation to 32-bit representations. --DVrandecic (WMF) (talk) 16:58, 13 October 2025 (UTC)

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

Added this page to the MassMessage global distribution list

As a quick FYI, I noticed that this page wasn't getting the Wikimedia-wide messages, so I've added this page to the general target list. If the community wants these sent elsewhere, we can create that venue and change the target, of course! Jdforrester (WMF) (talk) 12:34, 30 September 2025 (UTC)

Thanks! --Ameisenigel (talk) 17:43, 30 September 2025 (UTC)

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

Tutorial for Text fragments

I think it is helpful to have a tutorial about how to create text fragments. There is an overview of functions for fragments at Wikifunctions:Abstract Wikipedia/2025 fragment experiments. So far I am not sure what is relevant to understand how to create them. For the one I created I looked at an example functions and modified it. What do you think should be written down at a tutorial page. I hope it will help to get more text fragments in more languages.--Hogü-456 (talk) 21:05, 30 September 2025 (UTC)

@Hogü-456: This is a nice idea. As the page you linked says, this is all very much experimental right now, but I think it'd be great to discuss what we've learnt so far and how we do (and don't!) want to guide people to create them. Maybe we should discuss on Wikifunctions talk:Abstract Wikipedia/2025 fragment experiments? Or here, but it might get a bit complex debating e.g. if all fragments must return a Z11/monolingual string, and how to indicate that Lexemes are missing in the given language in responses, etc.? Jdforrester (WMF) (talk) 17:15, 3 October 2025 (UTC)

Yes, that seems like the right place. We’ll probably want separate topics for each “debate”. GrounderUK (talk) 09:09, 4 October 2025 (UTC)

@GrounderUK, @Hogü-456: Excellent; I've started two threads there for top-of-mind issues, but I'm sure there's more! Let's discuss. Jdforrester (WMF) (talk) 18:10, 6 October 2025 (UTC)

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

Language shortcuts

@Arlo Barnes: as the creator of the page. The shortcut WF:ldn was recently created as a shortcut for the page on Láadan. I think this, and future redirects, should be moved to subpages of WF:HL, as many shortcuts may need to be made, at least one for each language (they probably need to be at least partially capitalised to prevent confusion with translation subpages). Xeroctic (talk) 11:10, 6 September 2025 (UTC)

So it would be WF:HL/LDN because WF:HL/ldn would be the translation page, for example? But WF:HL just redirects, so WF:human languages/ldn would be the actual translation page for the main list, and perhaps WF:human languages/LDN/ldn for the subpage. Arlo Barnes (talk) 16:35, 6 September 2025 (UTC)

The all-capitals term would probably be best for the shortcut, as is practice on English Wikipedia and probably other wikis (the current shortcut is mixed case, but due to being after the namespace colon, it can be presented as all-lowercase unlike the last part of subpages). Additionally, I am unsure whether translation pages are necessary for redirects (unlike the pages they target). Xeroctic (talk) 18:54, 6 September 2025 (UTC)

The English Wikipedia has w:Category:Redirects from ISO 639 e.g. w:ISO 639:abc. YoshiRulz (talk) 00:12, 7 September 2025 (UTC)

Belated reply, but something similar to this could be used, except the equivalent for my proposal would be WF:HL/ABC in that case (although due to its small number of speakers that example probably will not have a ZObject). Xeroctic (talk) 09:01, 22 September 2025 (UTC)

Feedback requested - type proposal (taxon ranks)

Hi, I just started a new type proposal, and I'd greatly appreciate any feedback, as there's a technical question I'd like answered and a few other things to work out before it can move on. I'm also not quite sure where to file it under on WF:Type proposals (Lightweight Wikidata enumerations, or some other section, seeing as it's not completely written?). Thanks. --WrenFalcon (talk) 16:47, 24 September 2025 (UTC)

IMO It would be fine to list it under Lightweight Wikidata enumerations, since it seems very likely to become one of those.  And if that starts to seem unlikely, it could easily be moved to another location. DMartin (WMF) (talk) 00:39, 30 September 2025 (UTC)

From IPA symbols to corresponding Wikidata items?

Is it currently technically possible to write a function that takes a string representing an IPA symbol as input, and outputs the corresponding Wikidata item? E.g. given "θ", the function would output voiceless dental fricative (Q332019). The more general question would be: Is it currently technically possible to go from strings to Wikidata items?

Why is this interesting to me? If I were able to start with a Wikidata lexeme form, extract its IPA transcription (P898) as a string, then link it to the corresponding Wikidata item, I could use the item's statements describing phonological features to know whether I have to apply certain Sandhi rules while generating natural language sentences. Otherwise, for each Sandhi rule whose applicability doesn't derive from the spelling itself of the words involved, the necessary information for its applicability would need to be encoded as statements (needing dedicated Wikidata items) in each Wikidata lexeme form for the given language. This is particularly problematic, if proper names are involved.

The primary use case I have in mind, is the Eifel rule in Luxembourgish, where some words drop their final -n or -nn in writing, depending on the phoneme of the word that follows them. --Volvox (talk) 14:58, 23 September 2025 (UTC)

In general, it's impossible to get a Wikidata Item based on the string label. In this case, instead, I think that it is still possible to implement this by manually listing the entire IPA alphabet in an implementation. I think that it could even be possible to propose a new Lightweight Wikidata Enumeration "IPA symbol". Dv103 (talk) 16:47, 23 September 2025 (UTC)

@Dv103: Yes, I think this would be an appropriate new light-weight enum, and I can see it being useful for language-related things. Do you want to (co-)propose it on Wikifunctions:Type proposals? Jdforrester (WMF) (talk) 13:18, 24 September 2025 (UTC)

I don’t think “the entire IPA alphabet” is well defined. It’s also copyright CC-BY-SA 3.0 attribution required, in case that’s relevant. Conceptually, it’s the taxonomy of phones that’s important. Representing a phone using IPA-consistent glyphs feels more like a reading and display function requirement, but they don’t get connected to lightweight enum types, at present.

For example, voiceless dental fricative (Q332019) has an IPA transcription (P898) property with the value « θ ». The string is constrained but not identified as a Wikidata item in its own right.

Also worth considering are the phonemic inventories that define approximations for general use with particular languages and variants. These allow the same IPA symbol to be used for distinct phones, like the [d] in “standard” varieties of French (dental and voiced) and English (alveolar, voiceless and lenis or unaspirated). (Standard IPA does not represent the phonemic fortis and lenis distinction, so English transcriptions typically represent lenis voiceless consonants as voiced or, less inaccurately, as de-voiced [d̥].) GrounderUK (talk) 11:45, 28 September 2025 (UTC)

@GrounderUK: Do you have a citation for the system of the IPA, created in 1886 and extended since, being under copyright somehow? The licence on File:IPA_chart_2020.svg is about the file itself, and I don't think it can apply to the underlying content as factual statements? But happy to be corrected! Jdforrester (WMF) (talk) 13:19, 2 October 2025 (UTC)

The claim is the International Phonetic Association’s own:

https://www.internationalphoneticassociation.org/content/ipa-chart. I’m not qualified to comment on the claim’s validity or the extent of its applicability. GrounderUK (talk) 19:09, 2 October 2025 (UTC)

Prevent changing built-in names

A new user recent changed two-built in function names (the original English strings) to what appears to be some nonsensical text, both of which I have reverted, and neither of them appeared on Special:AbuseLog. Although probably unlikely to happen very frequently, it may be useful to prevent changing built-in objects' keys which do not correspond to the GitLab source code, either through an AbuseFilter or otherwise. Xeroctic (talk) 12:44, 23 September 2025 (UTC)

Thanks for reverting these changes. I’m not sure that “en” labels deserve more protection than those in other languages, but I wouldn’t object to requiring at least Functioneer rights to make such changes. We could consider reserving the right to Administrators etc, but I think the safeguards around granting Functioneer rights are more than adequate, requiring a formal request and a 48-hour delay. GrounderUK (talk) 13:47, 23 September 2025 (UTC)

+1 So9q (talk) 16:00, 27 September 2025 (UTC)

@Xeroctic, @GrounderUK: There are other kinds of Objects that could be quite disruptive if people mis-label them, like Types. Would you want us to build user rights for those too? Jdforrester (WMF) (talk) 18:19, 23 September 2025 (UTC)

Types and built-ins limited to functioneers sounds reasonable to me. So9q (talk) 16:02, 27 September 2025 (UTC)

I'd prefer not to restrict adding new label languages. Often the most important contributions of non-functioneers are translations, and the most important translations are of types and built-ins. I think we can monitor for disruption easily enough. --99of9 (talk) 10:31, 28 September 2025 (UTC)

+1 So9q (talk) 21:09, 29 September 2025 (UTC)

@99of9: OK, so we're talking about rights to edit and create labels (2x) for Functions and Types (2x) for pre-defined and all (2x) Objects, so 8 new rights overall? And an initial configuration that editing labels for pre-defined Functions and Types are restricted to Functioneers, but all other rights are open to all logged-in users, as now? This is certainly do-able, I'll write it up as a task. Jdforrester (WMF) (talk) 13:15, 2 October 2025 (UTC)

Filed as T406254: Provide ability for WF.org to be configured to stop edits to Objects' labels, especially edits to labels of pre-defined Types and Functions if people want to track. Jdforrester (WMF) (talk) 18:18, 2 October 2025 (UTC)

I'm not sure we *need* all 8. But sure, with them we can certainly specify things very precisely. 99of9 (talk) 05:29, 3 October 2025 (UTC)

It’s hard to know where to draw the line. I agree with @99of9, in general. But I thought we were just talking about “en” labels. GrounderUK (talk) 10:39, 28 September 2025 (UTC)

@GrounderUK: As a matter of policy, I think treating English differently from every other language would be an extremely unusual step, and not one I would feel at all comfortable about. Jdforrester (WMF) (talk) 13:12, 2 October 2025 (UTC)

+1 --Ameisenigel (talk) 17:52, 2 October 2025 (UTC)

I think that’s what I said in my original reply to @Xeroctic who was explicitly suggesting that the “original English strings” should not be changed so as to differ from the “…the GitLab source code”. If the proposed change applies to languages other than “en”, then I do not support it, for the reasons given by @99of9. GrounderUK (talk) 19:22, 2 October 2025 (UTC)

@GrounderUK Is this the reasoning you are referring to: "I'd prefer not to restrict adding new label languages. Often the most important contributions of non-functioneers are translations, and the most important translations are of types and built-ins. I think we can monitor for disruption easily enough."?

In that case, perhaps you misunderstood @Jdforrester (WMF)? The rights enable us to block _edits to existing labels_, but would allow adding labels in new languages (create) if I understood the task in phab correctly. So9q (talk) 19:29, 2 October 2025 (UTC)

I didn’t read 99of9’s comment as suggesting that add should be treated differently from change. I don’t think that’s a useful distinction, because the first label added may well have been inappropriate and the edit is simply attempting to improve it. GrounderUK (talk) 19:58, 2 October 2025 (UTC)

In this case, my words were limited but precise. I do not necessarily need them to be treated differently (I'm fine with not blocking either), but if we are to block edits, then I don't want to also block first labels. The reason I think there is a distinction between them is because cleanup of inappropriate labels is a higher order task than just chipping in a label. For example, I can't attest that "Often the most important contributions of non-functioneers are improving existing labels". I only recall one case of that, where a newcomer came to this board and said that most of the labels in their language were bad... Anyway, regarding English, I agree that we should find a solution that doesn't treat languages differently. --99of9 (talk) 05:26, 3 October 2025 (UTC)

Thanks for clarifying. I don’t agree that correcting objectionable labels is a “higher-order task”. I can easily imagine someone embedding a function being motivated to correct a misleading label, whereas a missing label might be met with a shrug. That, I think, is exactly the sort of contribution we should be keeping as straightforward as possible. That said, having distinct rights is not actively harmful, so I just suggest we keep the create and edit rights aligned and (for the time being) impose no additional restrictions on anyone. GrounderUK (talk) 11:17, 3 October 2025 (UTC)

Unlike other Wikimedia projects' strings, non-English translations of those are held on Wikifunctions rather than translatewiki, which is why I mentioned English in particular. Considering that protecting built-in objects may hinder the other translations from being added or edited, I would be fine with exempting new translations. Xeroctic (talk) 19:31, 2 October 2025 (UTC)

Thanks for clarifying. I don’t think Wikifunctions is very different from Wikidata in this regard. The key distinction is that some objects are assigned an initial “en” label that is unlikely to be objectionable in itself. The same distinction may be applied to Natural language objects, which also have an initial label assigned in that language. If we chose to distinguish just such labels, I would be happier with more restrictive rights being applied to edits. But wherever we allow anyone to create a label, I don’t see why we wouldn’t be equally permissive if someone wants to edit a label that they find objectionable. GrounderUK (talk) 11:41, 3 October 2025 (UTC)

Wikilinks in HTML fragments

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

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

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

Technical issues: Community process

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

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

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

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

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

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

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

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

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

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

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