Wikifunctions:Project chat

Welcome to the Project chat, a place to discuss any and all aspects of Wikifunctions: the project itself, policy and proposals, individual data items, technical issues, etc.

Other places to find help:

• Wikifunctions:Administrators' noticeboard
• Wikifunctions:Report a technical problem
• Wikifunctions:FAQ

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

edit
Archives
2023/08 2023/09 2023/1 2023/10 2023/11 2023/12 2024/01 2024/02 2024/03 2024/04 2024/05 2024/06 2024/07 2024/08 2024/09 2024/10 2024/11 2024/12 2025/01 2025/02 2025/03 2025/04 2025/05 2025/06 2025/07 2025/08 2025/09

language to language tag (Z14329) and language tag to language (Z860) might be set as the read and display functions for Natural language (Z60). I think this would make a fairly large number of functions available as embedded functions (including all the read and display functions for supported types). There are around a hundred functions with Z60 in their inputs but I reckon around half of these would remain unavailable if we decide to make this change (based on this search) GrounderUK (talk) 08:49, 24 July 2025 (UTC)Reply

Interesting idea to just use the codes. Actual read and display functions need two arguments, so we'd need to wrap those functions, but they could indeed be reasonable defaults. I'm not sure what your search query is trying to show (many of those functions seem to have other argument types that are also readable and output types that are displayable). --99of9 (talk) 12:14, 24 July 2025 (UTC)Reply

I’m not sure we’d need to wrap display functions for the types supported as inputs to embedded functions. The search is just what was left after I excluded various types that are not supported, so it should include all the functions that might be supported by enabling read and display functions for Z60 (so none of them should currently be available to embed). I reached the maximum size for the search terms, so I couldn’t exclude any more types. GrounderUK (talk) 14:25, 24 July 2025 (UTC)Reply

Thanks for the suggestion! We have recently discussed adding Natural language (Z60) support to embedded function calls (only as inputs). As we've indeed seen that it would enable lots of new functions for embedding, we've added it to the scope for this quarter. Our intention is to add support by having a Natural languages lookup field that would allow editors to search through available Z60 objects by their labels and select one. The selected language would be inserted as a Zid, for example {{#function:Z23468|Q144|Z1003}}. We could very well add a read function to the type as well, but then we'd have to deal with double support of language codes and zids, which needs additional engineering work and might be prone to validation errors and confusion. We are tracking this work in phab:T400165 and I've included this suggestion as a possible solution. If there are strong reasons to also link a read function to the type, please follow-up in the task so that we can work out how to enable this double support. In such case, we should decide on a different function to be used as a read function, as read functions require a second argument (language) and Z860 doesn't have one. Otherwise, I believe our preferred solution is to go ahead with the custom selector and provide a nicer user experience. Geno (WMF) (talk) 17:11, 24 July 2025 (UTC)Reply

Thanks @Geno (WMF). I wasn’t suggesting we might do this instead of what you are proposing, but we might do it sooner, even if we have to wrap Z860 to provide the second argument.

The Wikifunctions component also allows languages to be found by searching on their code or their ZID, so I hope that will also be an option for embedded function calls. I think what we ultimately require is quadruple support, so that the user can also specify the language as a Wikidata item reference.

I don’t know why displaying a language is not currently within scope, but I think it’s important to consider the solution options for that at the same time, even if implementation occurs later. The main challenge for community functions here is that we have no way for such a function to convert a language code to a ZID and no way to extract a label from a Z60 even if we have the ZID. This leaves us with nothing to display other than the text of the Z60K1/code itself. GrounderUK (talk) 22:16, 24 July 2025 (UTC)Reply

@GrounderUK: To clarify, if we do what you ask and add a reader function for Z60s, it will break the code we are writing and we will have to write more. So we are saying we should be sure we can justify spending more time (and thus money). Adding a display function for Z60s does not break that code, but is not planned work. We could do it, but (as I said below) I don't think it's a good idea with that proposed function as its output is terrible. Jdforrester (WMF) (talk) 22:36, 24 July 2025 (UTC)Reply

Thanks, James. For the avoidance of doubt, I haven’t asked anybody to do anything. Nor am I likely to do so in the absence of a community consensus. (But if you could just sort phab:T366459, that would be much appreciated.) I imagine the language code to ZID lookup would have to be a built-in function, so that would require a separate Feature request in any event. GrounderUK (talk) 23:11, 24 July 2025 (UTC)Reply

@GrounderUK: In terms of the display function, I think Z14329 would give readers a very poor experience. Language codes as a plain piece of text aren't obviously telling the user something, and the codes aren't familiar to many users; even experts will be confused by some (think e.g. of Z1547, code es-419). Also, that function doesn't take into account the context language, which all display and reader functions are required to do. Maybe we should wait on that side until we have agreement on what a better function would be, and build it? I'd be happy to help create a candidate function, though maybe it should return HTML so we can link the language label to something or style it? Jdforrester (WMF) (talk) 17:18, 24 July 2025 (UTC)Reply

Thanks, James. I’m afraid we haven’t really got a grip on how we give the end-user options so that the function result looks and behaves the way the contributing community wants it to. Consider this simple example:

Hanover (German: Hannover) is a German city. w:simple:Hanover

In this sentence, the first “German” is a link to the German language article (provided by a template call: {{lang-de|hannover}}). That’s the Simple Wikipedia article, of course, not Simple Wiktionary or English Wikipedia. The editorial rule here is already quite complicated: if the label for an item in the language of the function’s context differs from the label in some other language (specified or derived), also provide (in parentheses, say) the label in the other language (typically in italics) together with the name of the other language (positioned relative to the label and separated from it according to the style appropriate to the context) as a link to the article appropriate to the context. (Compare w:fr:Hanovre, where the French « en langue » template prefixes "en " and separates the link from the following colon with a space.) GrounderUK (talk) 11:50, 25 July 2025 (UTC)Reply

@GrounderUK: Exactly, I think a conversation (here? on Talk:Z11?) about what ideally we'd want to be able to show to readers, and then maybe what compromises we'd accept (ahead of features/consensus/magic AGI/etc.) before rushing to connect a given Function as the display Function for the Type. Jdforrester (WMF) (talk) 15:03, 31 July 2025 (UTC)Reply

It’s rather a question for the content contributors who will be using embedded functions, I think. Maybe we should have a separate forum for the wider community? @Sannita (WMF) GrounderUK (talk) 21:33, 30 August 2025 (UTC)Reply

@GrounderUK Sorry for taking this much to answer. I don't have an answer as to where to store the discussion. Being something that involves at 99% community, I'd say community should decide where to host it. I guess a new page for the scope it's a good idea, but I'm not willing to make a decision on behalf of the community. Sannita (WMF) (talk) 10:07, 7 September 2025 (UTC)Reply

Thanks, @Sannita (WMF). I think we need to think carefully about who “the community” is in this context and, more generally, how to engage the wider community (outside of Wikifunctions) in discussions of this type. Happy to file a task for this, if you like. GrounderUK (talk) 23:36, 15 September 2025 (UTC)Reply

Hi. I have something that needs to be clear. How does this wiki is the only wiki that have the Vector 2022 skin optimized for mobile view? In other wikis, it's not optimized for mobile view and we have to zoom the page to see the content, but in Wikifunctions we don't have to do that. Although I have already enabled the responsive mode in global preferences page, but Wikifunctions is still the only wiki that has the Vector 2022 skin for mobile optimized, it does no effects in other wikis. I have checked this wiki and it seems there's no related configuration in MediaWiki:Vector-2022.css or MediaWiki:Common.css, so it might be related to some deep configurations. I also mentioned about this in here but there's no response. Nvdtn19 (talk) 09:51, 22 August 2025 (UTC)Reply

@Nvdtn19: It's an experimental mode built by the Web team, of which we are the first (and so far, only) wiki to take advantage. I believe that the long-term plan is (or was?) to convert all wikis over to it eventually, but I am not involved, sorry. Jdforrester (WMF) (talk) 13:51, 26 August 2025 (UTC)Reply

@Jdforrester (WMF): Oh... So is there any way to contact them? I wanna ask when will this feature be available in remaining wikis. Nvdtn19 (talk) 05:57, 7 September 2025 (UTC)Reply

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)Reply

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)Reply

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)Reply

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

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

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)Reply

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)Reply

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)Reply

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

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)Reply

@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)Reply

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

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

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)Reply

@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)Reply

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)Reply

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)Reply

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

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)Reply

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)Reply

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

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)Reply

@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)Reply

@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)Reply

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)Reply

@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)Reply

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

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)Reply

@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)Reply

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

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

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)Reply

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)Reply

@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)Reply

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)Reply

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

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)Reply

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)Reply

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

@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)Reply

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

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)Reply

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

@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)Reply

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)Reply

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)Reply

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)Reply

@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)Reply

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

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)Reply

@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)Reply

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)Reply

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)Reply

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)Reply

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)Reply

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)Reply

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)Reply

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)Reply

@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)Reply

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)Reply

@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)Reply

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)Reply

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)Reply

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)Reply

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)Reply

We published a new type RGBA colour (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)Reply

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 colour (Z28624)
• display RGBA colour (Z28650)

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

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)Reply

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

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)Reply

@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)Reply

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

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

In this issue, we update you on the latest functions and types you can create, we announce that functions are now available to call on 152 projects, we talk about our presentations at Wikimedia meetings, and we take a look at the latest software developments.

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

Also, we remind you that if you have questions or ideas to discuss, the next Volunteers' Corner will be held on October 6, at 17:30 UTC (link to the meeting).

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