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

Feedback on the "About" widget on Wikifunctions

Hi all! We are collecting feedback on our "About" widget for multilingual readers and editors, after some months from its implementation.

We would love to hear from you about the following topics:

1. What do you think of our improvements of the user interface? Is it functional? Does it help you doing your work? Is there anything we should fix or improve?
2. What do you think of the workflow to edit multiple language labels in one edit? Does it work? Is it simple? Is there anything we should fix or improve?
3. Does the language fallback strategy we implemented work? Have you had need to try it? Is it functional? Is there anything we should fix or improve?

Feel free to reply here, if you used the widget. If you didn't use it, give it a try, and then let us know!

Thanks in advance! Sannita (WMF) (talk) 15:30, 7 October 2024 (UTC)

Hi!

I really like the new design, it makes it much easier to create and improve translations.

1. There are only a few tweaks I'd make, but they are all minor: Sometimes the tags show the "+1" button even though there is enough space to display one or a few more. When editing tags, the tags from the existing translation are comma-separated, but in the text field they have to be separated by pressing return.
2. I haven't used that yet, but I think the resulting design choice of putting the submit button at the top feels a little unconventional at first.
3. I haven't seen it in action, but the placeholder / available translation combination is a lot better than what was there previously.

Thanks for all of the work that was put in to this, the effort really shows in the result!

Jummit (talk) 16:36, 7 October 2024 (UTC)

Replied at Wikifunctions talk:Design/About widget improvements. Amir E. Aharoni (talk) 18:13, 1 November 2024 (UTC)

Other languages, lists, other types..

Hello,

Wikifunctions seems like an awesome project!!

Will you be adding implementations in other languages, such as java, C++, Rust... (i only know java personnally)?

I've tried using lists, but adding items one by one isn't very confortable... Will you be adding an option of entering a list in text format, like for example in python : [1,2,4,5] ?

Will you add Arrays, so we can code functions with matrixes, so we can code some math?

Is the goal ultimately to be able to code any function in any language on any subject?

Why isn't there categories for the functions? That's pretty useful.

Anyways, good luck, keep going! Blocktomo (talk) 21:01, 12 October 2024 (UTC)

Not sure about java, C++ and rust, I think it would be possible, but spreading it across languages makes supporting all the functions harder because if someone who maintains a lot of functions in one language retires, then it leaves a mess for us in future. Zippybonzo (talk) 15:11, 14 October 2024 (UTC)

But isn't that the whole point of the community? Somebody starts something and people chip in, give their contribution... It opens more possibilities for everybody! Blocktomo (talk) 19:08, 16 October 2024 (UTC)

Wikidata integration

Any news from the WMF regarding an integration with wikidata? If it integrated with wikidata I think we could get a lot more functions that worked with wikidata and overall it would improve the project IMO. Zippybonzo (talk) 15:10, 14 October 2024 (UTC)

Likely the best way to stay informed is to put this on your watchlist: d:Wikidata:Wikifunctions. ―Justin (koavf)❤T☮C☺M☯ 15:52, 14 October 2024 (UTC)

@Koavf: That's about using Wikifunctions on Wikidata; I think @Zippybonzo is asking about using Wikidata on Wikifunctions. Jdforrester (WMF) (talk) 13:16, 16 October 2024 (UTC)

Well, it's generally about integration between the two and there's no local equivalent. If there were some big developments, they would be mentioned there. ―Justin (koavf)❤T☮C☺M☯ 13:17, 16 October 2024 (UTC)

@Koavf: No, I promise you, we would not write about Wikifunctions changes on Wikidata when the audience is the Wikifunctions community. :-) Jdforrester (WMF) (talk) 13:19, 16 October 2024 (UTC)

@Zippybonzo: See the thread two above. :-) Jdforrester (WMF) (talk) 13:15, 16 October 2024 (UTC)

Wikifunctions & Abstract Wikipedia Newsletter #176 is out: What could abstract content look like?

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

In this issue, we present some thoughts by User:Mahir256 about how abstract content could look like in the future, 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) 14:13, 17 October 2024 (UTC)

Migrating linguistic algorithms from Wiktionary to Wikifunctions

There is a vast codebase covering word inflection and other aspects of language in English Wiktionary. It's written in Lua. Wikifunctions doesn't support Lua so far. So I'm wondering:

1. Is Lua support planned? Wikifunctions:FAQ says:

   We hope to add at least one further programming language in 2024 (but have not yet decided which one).

   @Theknightwho, who is a major contributor to English Wiktionary's Lua modules, said this:

   without some way of implementing our existing modules there, there's unlikely to be much interest in using it for anything

2. If it becomes supported, would it be feasible and/or sensible to migrate algorithms for various linguistic purposes? I already see some natural language operations at Project:Catalogue#Natural language operations. Could they be reused in Wiktionary? If they are, that would be a huge weight off Wiktionary's shoulders.

JWBTH (talk) 16:30, 25 October 2024 (UTC)

@JWBTH @Theknightwho Thank you for your questions, and sorry for taking this long to answer.

We are currently working on integration with Wikidata and Wikipedia, so for now we don’t have plans on researching support for another programming language. Having said that, Lua is one of the candidates for new languages to be supported, also considering how much it is used on our sister projects. One caveat: Mediawiki Lua is a different language than proper Lua, so we need to take that into consideration when researching support. Would a real Lua still be good for you?

As for the second question, we definitely welcome a collaboration with Wiktionary on linguistic functions, since this is one of our focus areas here on Wikifunctions. How do you figure the reuse of natural language operations on English Wiktionary? What would be the main pain point that Wikifunctions would help you relieve?

Also, you’re welcome to join today’s Volunteer’s Corner to discuss things live with the other members of the community! Sannita (WMF) (talk) 15:22, 4 November 2024 (UTC)

@Sannita (WMF) Thanks for the response. To address your first point, I think @JWBTH and I are suggesting two different (albeit related) things here:

1. Adding Lua to Wikifunctions would make it easier to port linguistics functions from English Wiktionary (or other projects) to Wikifunctions. For this to be feasible, some Scribunto functions would need to be reimplemented in some fashion; e.g. the ustring library, which reimplments the standard Lua string library but with Unicode support); a pure-Lua ustring library exists, but it has unacceptably poor performance as compared to Scribunto's callbacks to PHP, which use PHP's PCRE2 regex engine (written in C), which is at least 100 times faster. I'm sure there are several other similar examples.
2. It would be great if project-based modules were able to call functions hosted on Wikifunctions, as this would obviate the need for the massive amount of duplicated code that currently exists between projects (many of which simply fork modules from large projects like English Wikipedia and Wiktionary). This wouldn't necessarily require Wikifunctions to "natively" support Lua, but there would need to be a way for Lua to interface with the languages that Wikifunctions does support. My main concern here is performance, since the English Wiktionary has (for a while now) been running into performance limitations with Scribunto, so any Wikifunctions-based solution would need to match (or ideally improve on) the current level of performance we achieve with Scribunto; otherwise, there would be a major disincentive to use Wikifunctions-based functions.

In terms of your second question, the advantage of centrally-hosted functions is twofold:

Firstly, it would be beneficial for multiple projects to be able to take advantage of sophisticated linguistic functions without having to fork all the existing modules; this is similar to the benefit Wikidata provides for many projects now.

Secondly, and more specifically for English Wiktionary, most of our linguistic functions are geared towards two things: morphology (noun/adjective case forms, verb conjugation, and so on) and transliteration. Both of these are generally pretty straightforward to get right most of the time, but can become extremely complex in certain cases when they have to rely on contextual information. For instance, adjectives must decline with the same case as the noun in Russian, while in Japanese, transliteration can be affected by morphemic breaks (e.g. between a stem and its suffix), which requires textual analysis; in Mongolian, transliteration of

ю

depends on the vowel harmony of the segment, while the Tibetan script can be ambiguous, requiring semantic and/or phonological analysis to determine where the vowel lies in a syllable. There are many, many more examples. As a result, we've developed some analytical functions to aid with this already, which could be of benefit to Wikifunctions, and I think there is a lot of scope for mutually-beneficial collaboration. Theknightwho (talk) 16:57, 4 November 2024 (UTC)

Theknightwho gave most of the technical and linguistic details, I'll just add:

> We are currently working on integration with Wikidata and Wikipedia
If you're working on integration with Wikipedia and we're talking non-linguistic functions or functions for English only, then probably you don't require any intricate algorithms English Wiktionary offers at this stage.

However, as the range of languages expands, you will require to adopt Wiktionary modules in some form. Well, unless you intend to reinvent the wheel or decide to use some third-party solution with unclear licensing situation and/or from people undedicated to the cause of Wikimedia. (You might have other considerations on this, of course, this is only how I see the situation.)

So, if you're interested in developing universal solutions that are wider than English alone, you might want to clarify Wiktionary/Lua support early rather than late. Otherwise you may find yourself in a situation where you need to substantially restructure the architecture to generalize it (and treat English as a special case). JWBTH (talk) 21:40, 4 November 2024 (UTC)

As a matter of fact, linguistics is a whole universe, of course, and is not limited to the morphology/transliteration that operate on the word level (on which Wiktionary operates) as opposed to sentence etc. So if you go for the sentence level, you'll have to refer to third-party solutions anyway, I suppose. But why not reuse code that is there to be reused. JWBTH (talk) 22:00, 4 November 2024 (UTC)

Wikifunctions & Abstract Wikipedia Newsletter #177 is out: Our goal for this Quarter: Agreement

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

In this issue, we discuss our goal of building up phrases from Lexemes using linguistic agreement, i.e. accordance to number and gender when constructing a phrase.

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

Enjoy the reading! -- User:Sannita (WMF) (talk) 16:32, 25 October 2024 (UTC)

Agreement implies inflection. I'm wondering, isn't a duplication of effort happening between Wiktionary and 1) Wikifunctions, 2) Wikidata Lexemes? AFAIK, there is some limited work done to migrate word forms from Wiktionary to Wikidata by bots. However, I've talked to Wiktionary people, and they are barely aware of the developments you have on these projects, despite the enormous work they have done to cover inflection and other topics for the purposes of dictionary. See also my topic just above: Wikifunctions:Project chat#Migrating linguistic algorithms from Wiktionary to Wikifunctions. JWBTH (talk) 18:04, 25 October 2024 (UTC)

Just chiming in to boost this, as someone who contributes a lot to Wiktionary. Our module infrastructure is far from perfect, but we have a bunch of stable, mature and relatively comprehensive functions for handling inflections in all major languages, and a good number of minor ones. It would be good for us to collaborate and draw from that experience, instead of reinventing the wheel all over again here; nothing I have seen on Wikifunctions approaches the sophistication of wikt:Module:ru-noun, wikt:Module:ar-verb or wikt:Module:mn-noun (though I'm happy to be proven wrong). Even taking English, suffix English word (Z13254) cannot handle many of the edge cases handled correctly by export.add_suffix in wikt:Module:en-utilities, for instance (see the comments in that module for examples). Theknightwho (talk) 20:36, 25 October 2024 (UTC)

@GrounderUK: I've seen you contributing to natural language functions. Could you comment on that? JWBTH (talk) 22:58, 25 October 2024 (UTC)

Yes. Specifically on suffix English word (Z13254), I have not sought to make it comprehensive (because, guess what, Wikifunctions is not a dictionary). The problem is largely historical. When Wikifunctions could handle only Strings and Booleans, morphological functions were an interesting use case for exploration and demonstration but there was a general lack of understanding of how final consonant doubling works in English. Having fixed English -ing form (Z13087) so that all tests passed, I created suffix English word (Z13254) as a general solution that could easily be implemented in other morphological functions.

I see that some new test cases have been added to other functions recently, so I shall probably make the changes necessary to ensure those pass, but the more significant limitation of the current function is its general inability to distinguish between stressed and unstressed final syllables, which is not something I’m planning to address.

On the wider question of interactions between Wiktionaries, Wikidata and Wikifunctions, I shall no doubt find time to comment later but I don’t have any understanding of technical constraints that would prevent Wiktionary (or other) modules from being exposed as (or embedded within) callable functions on Wikifunctions (although I know that this is not currently possible). GrounderUK (talk) 09:14, 26 October 2024 (UTC)

Thanks for the reply.
> I have not sought to make it comprehensive (because, guess what, Wikifunctions is not a dictionary)
It's interesting, because, judging by the stated vision for Wikifunctions/Abstract Wikipedia, these projects do intend to reach certain comprehensiveness when it comes to natural language generation, one day. JWBTH (talk) 13:17, 26 October 2024 (UTC)

“One day”, yes, the NLG capabilities of Wikifunctions will be somewhat comprehensive, but this function and other morphological functions may not be part of that future landscape. We have only just enabled Wikidata access from Wikifunctions, so I think it is still an open question, but my guess is that we will rarely rely on string agglutination as a first resort when generating English texts.--GrounderUK (talk) 15:52, 26 October 2024 (UTC)

I mean, I appreciate the bottom-up approach of the projects' team well outlined at meta:Abstract Wikipedia/Updates/2022-11-04, but on the other hand I hear from many proponents of the top-down approach starting from Google.org fellows and ending with the active editors of Wikitionary (some of whom voice some strong negative opinions about the projects' outlook).
So I'm trying to figure out are there realistic plans to have these "bottom" and "top" ends meet anytime. JWBTH (talk) 13:17, 26 October 2024 (UTC)

Personally, I think the bottom-up approach is more likely to be successful or, at least, useful, when it comes to Abstract Wikipedia content. My medium-term aspiration is to provide NLG-wrapper functions for Wikidata statements, depending on the Wikidata property. If there is eventually some top-down representation available that can be reused for that purpose, then perhaps progress will be facilitated, but I do not (yet) see this as worth waiting for.--GrounderUK (talk) 15:52, 26 October 2024 (UTC)

You mentioned "inability to distinguish between stressed and unstressed final syllables". This sounds like something for which Wikidata lexicographical properties should be created if there aren't already. If they aren't, this is not going anywhere. JWBTH (talk) 13:17, 26 October 2024 (UTC)

Agreed. But the function in question takes a simple string as an input, so it is not possible for this function to make such a distinction. Similarly, the function returns a simple string, so it is unable to handle cases where more than one option exists. Presumably, some new function will be specified in due course and, under appropriate conditions, this new function will call the existing function or replicate its logic.--GrounderUK (talk) 15:52, 26 October 2024 (UTC)

The same goes for the vast array of linguistic features that contribute to producing 20 million nonlemma forms (by @Surjection's evaluation) in the Finnish language alone.

technical constraints that would prevent Wiktionary (or other) modules from being exposed as (or embedded within) callable functions on Wikifunctions

I'm wondering whether it is possible the other way around. One of the problems with English Wiktionary is that it is, well, English. And it only serves the purposes of the dictionary. Wikifunctions is a cross-linguistic project created with centralization in mind. It would be great if Wiktionary editors who are good in this morphology-inflection-agreement domain could migrate the most high-level of their linguistic developments to Wikifunctions while keeping the implementation functions local. JWBTH (talk) 13:17, 26 October 2024 (UTC)

Anyone is free to contribute new functions or implementations to Wikifunctions, of course. Whether these would ever be usable within a Wiktionary edition, I cannot say and I leave it to individual contributors to give appropriate consideration to the Intellectual Property implications. That having been said, I believe that Python and JavaScript implementations of these functions are more likely to be reused outside of the WMF projects than is the case with LUA modules.--GrounderUK (talk) 15:52, 26 October 2024 (UTC)

You’re welcome. I’ll respond to your reply in the old-fashioned Wiki-way, lest we (I) lose sight of the questions! GrounderUK (talk) 14:19, 26 October 2024 (UTC)

@GrounderUK To address your question of technical constraints preventing use on other projects: the big one is that Wikipedia/Wiktionary modules have to be written in Lua, which Wikifunctions doesn't support. I also appreciate your point that Wikifunctions isn't a dictionary, but there is already a wealth of experience in language-related scripting within the Wiktionary community, so it would be good for there to be some collaboration between the two communities, as there's no reason why Wikifunctions shouldn't have sophisticated morphology functions, as they have applications in other contexts besides dictionaries.

On the point of the new testcases, I was the one who added those, which all relate to adjectives with a -y or -ey suffix. All (except "expensive" → "more/most expensive") are supported by export.add_suffix in wikt:Module:en-utilities, so please do feel free to make use of that module. Some of the code should be simplifiable in Python, as parts of that module are designed around Scribunto-specific optimisations and the constraints of Lua's pattern engine, which is far less sophisticated than Python's regex library. Theknightwho (talk) 15:16, 26 October 2024 (UTC)

Yes, thanks for adding those new test cases. Please feel free to add more! I’ll work my way through them when I have time. I’m not convinced, however, that these functions should handle the comparative and superlative forms of “expensive” (and the like). Arguably, there are no such forms (or they are non-standard) and the use of “more” and “most” is periphrastic (sense 3). That, I think, is the consensus within the Wikidata lexicography community, so d:Lexeme:L6080 has no such forms. This means that Select lexeme forms from lexeme (Z19243) will return an empty list for L6080 with comparative (Q14169499) as its “grammatical features” (expensive (L6080) has no comparative form (Z19395)). Accordingly, the onus is then on the calling function to supply the periphrasis (depending on the lexeme’s language). Sorry to labour the point a bit here, but someone might go ahead and create the required functions before I get round to it! GrounderUK (talk) 10:55, 27 October 2024 (UTC)

@GrounderUK That's very reasonable, and I'm inclined to agree. To be honest, I only added "most expensive" to the superlative function because "more expensive" was already given as a test on the comparative one (or it might have been the other way around). The model you describe, of the onus being on the calling function, is also precisely how we handle it on Wiktionary: by default, adjectives and adverbs are displayed with "more X" and "most X" as the comparative/superlative, and the flag er triggers the use of add_suffix, which generates the expected forms (and there are manual overrides for both, too, though in practice these are rarely needed); there is also a - flag for when adjectives/adverbs are not comparable. Ultimately, there is still some level of editor input required, to decide whether the "-er" and "-est" forms are appropriate in the first place, or if any forms should be displayed at all. Theknightwho (talk) 14:45, 27 October 2024 (UTC)

@DVrandecic (WMF): This may be of interest to you as well, as the author of some natural language functions and, not least, the ideator of Wikifunctions/Abstract Wikipedia. I was suprised to see no communication lines between Wiktionary and Wikifunctions/Abstract Wikipedia, given the linguistic focus of both projects and the amount of the work done and experience accumulated in the former. JWBTH (talk) 23:11, 25 October 2024 (UTC)

changing object type

helloo!!! :33

when i first saw this project, i completely fell in love and decided to contribute as much as i can. i tried to create a function that helps the user working with the vowel harmony in azerbaijani. however, i just realised that i've misassigned it as a string, and therefore i cannot do anything with it. is it possible to convert it to a function, or do i have to create a new page for that? thanks in advance <3 əkrəm. 17:42, 25 October 2024 (UTC)

Hi, since it is not possible to change the type of the object, I have deleted the page. You can just create the function with the correct type now. --Ameisenigel (talk) 17:54, 25 October 2024 (UTC)

aight, thanks!! ^^ əkrəm. 18:07, 25 October 2024 (UTC)

Perspectives about programming in the programming language community, relevant for Wikifunction ?

this blogpost (and the associated reseach paper) by en:felienne hermans may be relevant for Wikifunction. It's about how feminism and more diversity may be beneficial for the programming language community by providing different perspectives.

There are several points in the paper that may be somehow relevant : 

• (arguably) how spreadsheets are or not a programming language, and how this is controversial in the community (spreadsheets are often overlooked and not considered valuable matter for the community). The spreadsheets formula language is kind of akin to the "composition" language in wikifunction (although the composition language is more powerful)
• More importantly : how her work on mother tongue language and programming language is not really considered a valuable topic.

@DVrandecic (WMF) I don't know if you and I know each others and your respective works but if not you might want to have a chat :) TomT0m (talk) 12:54, 26 October 2024 (UTC)

accepting selected string literals as input

hello againnn!! :33

i wonder if there's a way to assign some selected string literals as acceptable inputs, other than checking it in the implementation. tia!! :3 əkrəm. 13:12, 26 October 2024 (UTC)

You can only specify which type is allowed as an input for your function. Everything else needs to be handled with the actual implementation of the function. --Ameisenigel (talk) 16:14, 27 October 2024 (UTC)

alright, thanks ^^ əkrəm. 15:17, 28 October 2024 (UTC)

by the way, is there a way to call another function inside an implementation? :3 əkrəm. 15:17, 28 October 2024 (UTC)

SI Units appropriate?

Hello! I'd like to know if SI Units as a type would be appropriate for this project. The idea for them is to

• Have a standard for outputting them and for what is a valid output
• Have a display for them that is human-readable and standard.

But I'm not sure if that's what types on this project are supposed to be. On one hand, some of the types seem to be quite like this, with one being days of the week or RGBA colors, but, on the other hand, types in programming languages are usually not like this, and are usually more broad. I'd just like to know if this would be an appropriate type. I made a proposal here. Thanks. Feeglgeef (talk) 01:15, 28 October 2024 (UTC)

Thanks for kicking off the discussion. I've made an alternative suggestion in your proposal which I think would significantly simplify this. If others agree, I'm happy to try to write this up as a formal proposal. 99of9 (talk) 01:34, 28 October 2024 (UTC)

I definitely agree we should support SI units and measurements. Many thanks for the proposal. Please see my comments there. GrounderUK (talk) 13:25, 28 October 2024 (UTC)

Android app for Wikifunctions

Hi, is there an Android app for Wikifunctions? How does it work? I have been advised that there is no infrastructure for push notifications for Android apps for sister wikis and I would be interested to know more. Related: phab:T378545. Thanks! Gryllida (talk) 23:16, 29 October 2024 (UTC)

If I remember correctly, Kiwix has Wikifunctions. Otherwise, I don't think there is an Android app. Feeglgeef (talk) 23:29, 29 October 2024 (UTC)

Nevermind, it does not. Feeglgeef (talk) 23:32, 29 October 2024 (UTC)

@Gryllida There is still no app for Wikifunctions, and there are no current plans to develop one. The project itself is still building up its features, so we are focusing on giving new functions (literally) to the community for the time being. Sannita (WMF) (talk) 09:49, 30 October 2024 (UTC)

Automatically subscribed

I added a topic above and was automatically subscribed to it. I didn't see this feature before -- at other wikis I need to subscribe manually to new topics I added. How is this configured?

And how do I automatically subscribe to article and article talk for each article I edited?

Thank you. Gryllida (talk) 23:18, 29 October 2024 (UTC)

To answer your second question: Special:Preferences#mw-prefsection-watchlist "Add pages I create and files I upload to my watchlist". ―Justin (koavf)❤T☮C☺M☯ 23:49, 29 October 2024 (UTC)

Wikifunctions & Abstract Wikipedia Newsletter #178 is out: Rewriting the backend

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

In this issue, we discuss how the team is working hard to rewrite Wikifunctions' backend, to overcome some of the limits we encountered with the current language.

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

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

Enjoy the reading! -- User:Sannita (WMF) (talk) 13:19, 2 November 2024 (UTC)

New Implementation of is a palindrome (Z10096)

I created a new implementation Javascript-Implementierung von "ist Palindrom" (Z19595) and a new test "Hä, Bierbrei? Bäh!" (Z19593) for is a palindrome (Z10096). Is there a request page where I can apply for the connection?

There are two connected tests:

- "eěe" from UTF-8 hex is a palindrome (Z10551)

- is 👨‍👩‍👧‍👦 palindrome (Z10556)

which should IMHO have a result of "true" (see discussion) and are set to false. Can anyone confirm and change this? --Balû (talk) 10:23, 7 November 2024 (UTC)

Hello! I've connected the implementation and test for you. Feel free to send me a message on my talk page and I can connect something for you. Feeglgeef (talk) 14:12, 7 November 2024 (UTC)

You can make requests here:Wikifunctions:Community portal#Tasks listed by users (click the reply link). GrounderUK (talk) 00:09, 8 November 2024 (UTC)

Wikifunctions & Abstract Wikipedia Newsletter #179 is out: The dream of a Universal Language

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

In this issue, we talk about several presentation in and around the topics of languages and our work, we discuss the current refactoring of our functions catalogue 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) 22:50, 7 November 2024 (UTC)