Latest comment: 27 days ago5 comments3 people in discussion
I feel like the project could be done a lot better by using templates kind of like how wikipedia does them. Just the entire thing is templates that can be rendered in many languages. So like Q106289265 would have the content {{Z26039|Q7257}} and could even have some aliasing done across languages so it could be {{subject is|Q7257}}. Code would be editable with a regular visual editor or code editor. Immanuelle (talk) 04:34, 29 March 2026 (UTC)Reply
This is available in pages when Parsoid rendering is enabled. We don't use this becuase it doesn't make sense for constructing and editing massive articles. Feeglgeef (talk) 21:37, 29 March 2026 (UTC)Reply
Immanuelle wrongly stated that there is no REST API for editing. There is. However, it does not work when called from software outside Abstract Wikipedia. That is because there is no way to grant a bot password or OAuth customer the permission to edit abstract articles (wikilambda-abstract-edit) and create them (wikilambda-abstract-create), since no grant on Special:ListGrants includes either. Should this be fixed? JJPMaster (she/they) 01:57, 26 April 2026 (UTC)Reply
Yes I think the rights should be added. I think the number of automated edits should be low at the moment as Abstract Wikipedia is still in an early phase and so far there is not much support for small languages and so many functions will maybe change to cover more languages. As automatic editing using a Bot Account requires an formal request it is no problem if the option exists. Hogü-456 (talk) 18:17, 26 April 2026 (UTC)Reply
Latest comment: 7 days ago18 comments5 people in discussion
A month ago, @内存溢出的猫[spaces3 1] That discussion doesn't seem to have yielded any fixes or meaningful discussions, at least not that I can see.
Two weeks ago, I tried to bring up a similar topic, but that discussion somehow got derailed and also didn't yield anything useful.
Now, the problem looks differently, but it's still a problem. When I look at Q10251, for example, what I see is four sentences that appear with no spaces between them. Not one, not two—none at all. It looks like this:
Plasma is a fundamental state of matter.Plasma is a classical state of matter.A plasma is a gas.A plasma is a matter.
Note that I emphasized appear: When I see them rendered on the screen, they have no spaces between them. In the HTML, however, they are represented as four <div>s, and their inline positioning is handled by CSS. This means, for example, that if I copy and paste them, I don't get a long string with no spaces after full stops, but four sentences with a single line break after each full stop:
Plasma is a fundamental state of matter.
Plasma is a classical state of matter.
A plasma is a gas.
A plasma is a matter.
This is not how it is supposed to be done. <div>s are supposed to be used for block elements and not hacked into appearing as if they are inline (also known as phrasing). Spaces between sentences are supposed to be real characters rather than HTML and CSS tricks, they may be different in different languages, and in some languages they may be nothing at all.
I hope that the definition of the problem is clear.
↑According to Google Translate, it's pronounced "Nèicún yìchū de māo". Please correct me if it's wrong. When I write, I want to know how are things that I write pronounced aloud, and very unfortunately, I never learned to read Chinese characters, and even if I did, most English speakers probably didn't. Come to think of it, is there a function that reliably transliterates Chinese characters?
Hi, have a look at it now. Does this match your expectations? I think it's not rendering right now for whatever reason, but there are other examples of it being done this way that you can see: Q241691. The article renders properly in both English (spaces between sentences) and Japanese (no spaces at all).
English:
Programmed Data Processor is a computer model series by Digital Equipment Corporation. PDP-8 is a Programmed Data Processor.
I have some, err, strong opinions about Immanuelle's 「Abstract Wikipedia Editor」 tool, which is the predominant cause for all of these very janky and poorly-laid-out articles that you see. This is not how an article ought to be written on Abstract Wikipedia, and I and other editors are aware of this. If you see these problems, please do fix them! The wiki will be all the better for it.
WikiLambda is doing WikiLambda things. This WASI time limit error happens intermittently on Abstract Wikipedia articles and it usually goes away after a short while. The only thing is that it doesn't really seem like purging these articles does anything to force the orchestrator to retry its evaluation so the article might not render that paragraph until someone comes in and pokes at it by editing it somehow.
The working article uses the paragraph from sentences function to lay out its individual sentence content. This function automatically handles converting any and all text-like objects (strings, HTML fragments, and monolingual text) to a consistent form, so sentence fragments can all be supplied verbatim to its list input. When the function is putting the sentences together it defaults to using a single space to separate them, but first checks if the requested language is in the languages without spaces between sentences list. If it is, it doesn't add spaces at all, and just concatenates the sentences normally. I hope this explanation makes sense. —rae5e<talk>18:19, 2 May 2026 (UTC)Reply
It makes some sense, but earlier, you suggested: "If you see these problems, please do fix them", and I'm not entirely sure how to do it. How would I fix it in Q100, for example? Amir E. Aharoni (talk) 19:41, 2 May 2026 (UTC)Reply
In this case you would do the following:
At the bottom, click the plus and then 「Add empty fragment」.
Set the function to f:Z33068, as mentioned earlier.
Now go through each sentence fragment, find the innermost sentence-generation function, click on the three dots, and copy it. Do not copy the calls to f:Z29749 or similar, these are not necessary.
Go to the paragraph with sentences function call and add an element to the list.
Click on the three dots next to the new element, and paste in the earlier sentence fragment.
You can now delete the original fragment and repeat the process in the same list for the one after it.
@Theki I intend on fixing it, I recently made an attempt but the suggested fixes made problems worse. Do you have any practical suggestions of how to structure the templates? I will try to implement them when I have more time.
Um, are you referring to my signature not matching my wiki username? I have considered for a long time changing it from theki, but I don't feel like putting in the effort when it seems to be perfectly ignorable for most people. The user 「Rae」 can't be usurped because they made, like, two or three articles on the Persian Wikipedia two decades ago or something, I don't know. If that weren't the case I would be User:Rae right now but after that failed to go through I just decided to stop bothering. Maybe at some point I'll come up with a username I'm happy with keeping for the foreseeable future but I have other concerns at the moment.
Could you explain how your attempted fixes 「made problems worse」? Presently I side with Feeglgeef's sentiments and prefer to wait for abstract content to actually be feasible to make on a reasonably descriptive scale (see: the type proposals) before I go around making articles willy-nilly, which is what AWE has been doing—making a bunch of pretty low-quality articles on a massive scale when it probably really would have been better to, err, hold off on that.
And I honestly know very little about the actual workings of your editor, I don't really use it nor am I familiar with its template syntax or whatever it may use, so I'm going to look over how it actually works and then get back to you on that. —rae5e<talk>23:28, 2 May 2026 (UTC)Reply
@Immanuelle: I checked. Your issue is that your editor is not providing the article language to Z33068K2; that is, the paragraph from sentences function has a second argument, and your editor was omitting it. If you properly specify it, it will work. Please, next time, actually tell me what went wrong instead of going quiet and forcing me to look after it myself. —rae5e<talk>17:06, 4 May 2026 (UTC)Reply
I avoid f:Z33068 for now, because executing a whole paragraph in a single call would often time out. So my current alternative is inserting f:Z35672 between sentences. Fairly clunky, but it works... --99of9 (talk) 06:08, 28 May 2026 (UTC)Reply
Can you categorize the talk pages of articles you're doing that with? It has major accessibility concerns for our friends using screen readers, so it'd be nice to be able to find those with issues when were able to fix the calls Feeglgeef (talk) 21:50, 28 May 2026 (UTC)Reply
There's more than one way to not use spaces correctly and more than one way to use spaces correctly, this wouldn't catch all of them. Feeglgeef (talk) 23:13, 28 May 2026 (UTC)Reply
Maybe a much easier solution would be to replace the "." after each sentence with ". " (a full stop and a space). The paragraghs might add an extra space, but that is displayed as one by the browser. HenkvD (talk)
Latest comment: 29 days ago7 comments4 people in discussion
I was trying out a few functions recently, such as the new superlative function, and I noticed that every adjective has to be a Wikidata item. For example, I couldn't type in the inputs "Bugatti Veyron", "fast", "Earth" because "fast" as an adjective is not a Wikidata item. This doesn't really make sense, given that Wiktionary already has the word for "fast" and its superlative form in many different languages. Would it be possible to integrate Wiktionary into the function, so the user can type an adjective or verb from Wiktionary instead of having to deal with Wikidata (which consists almost entirely of nouns)? Somepinkdude (talk) 16:49, 6 May 2026 (UTC)Reply
No, sadly. I would try "speed" as the adjective, though, you have to use abstract qualities instead of concrete English terms. Here's an example of the word being used.Feeglgeef (talk) 18:02, 6 May 2026 (UTC)Reply
I tried this, and it gave "Bugatti Veyron is the speedest car on Earth", which is laughably bad. The problem is that Wikidata does not "know" what the superlative form is, while Wiktionary does. Speed is a fairly common descriptor, but what about less common adjectives which aren't on Wikidata? Will there need to be a bot to copy all of this information from Wiktionary? Somepinkdude (talk) 22:14, 6 May 2026 (UTC)Reply
Unfortunately not, and, honestly, I wouldn't recommend article creation at the moment, it's likely to need significant refactoring as the way we represent abstract content changes, but, I can point you to Q668 as a reasonably good example at the moment. Feeglgeef (talk) 02:39, 8 May 2026 (UTC)Reply
308 is the number of concrete Wikipedias in which a manually-written article about India is available.
The abstract article renders for me in English as "India is a country in Asia. India is a republic. New Delhi is the capital of India. India is the most populous country in world." Switching to another language to get rendered as an abstract article is done by typing the language's name in the box above the rendered text. I tried French, German, and Dutch, and got errors in all of them. Amir E. Aharoni (talk) 03:12, 8 May 2026 (UTC)Reply
So it goes. The paragraph has quite a lot of distinct sentence generation functions, all of which of course have to be implemented in the target language. This will be rounded out once we're able to more effectively generalize linguistic content. I view these functions as sort of patchy temporary solutions to the sentence generation problem while we figure out something more robust, which I hope is soon to come. —rae5e<talk>04:15, 8 May 2026 (UTC)Reply
Wikifunctions & Abstract Wikipedia Newsletter #247 is out: References from Wikidata now available
Latest comment: 28 days ago1 comment1 person in discussion
There is a new update for Abstract Wikipedia and Wikifunctions. Please, come and read it!
In this issue, we announce that is now possible to pass references in Wikidata statements, we introduce the Abstract Data dashboard, we report you on the presentation about Abstract Wikipedia at WikiCon Australia, and we take a look at the latest software developments.
Want to catch up with the previous updates? Check our archive!
Latest comment: 25 days ago4 comments2 people in discussion
The use of f:Z33068 (en: paragraph from sentences) always most of the time results in the error "Reached time limit in orchestrator." So should it be used at all for now, temporarily? Or maybe there are already some tickets about this that I am not aware of? -- Asked42 (talk) 18:23, 10 May 2026 (UTC)Reply
It previously worked, so I'm hoping whatever the issue is will be fixed soon. The current state of the wiki makes immediatism an illogical philosophy to have at the moment, in my opinion. Feeglgeef (talk) 20:16, 10 May 2026 (UTC)Reply
This issue seems to no longer exist, you might need to clear the cache by making a dummy edit on affected articles. I implemented the function in Python (instead of composition), which has increased the speed by about 2000 ms. Feeglgeef (talk) 04:31, 11 May 2026 (UTC)Reply
I've added some of them. Thank you for your list of best practices by the way, I generally agree with them (I can't endorse connecting WD items currently in hope of a better technical solution, but otherwise I do). Feeglgeef (talk) 00:58, 15 May 2026 (UTC)Reply
Proposals on the architecture of Abstract Content rendering
Latest comment: 25 days ago1 comment1 person in discussion
Starting from a discussion born on the Wikifunctions Telegram chat, I've explained two different proposals on how the NLG on Abstract Wikipedia should be organized in the page User:Dv103/Abstract articles architectures. Please come to contribute to the discussion, or to propose alternatives. Dv103 (talk) 14:32, 11 May 2026 (UTC)Reply
Latest comment: 24 days ago3 comments2 people in discussion
The copyright message has a few issues, mainly that it does not address abstract content (which is not "text"), nor object labels (which are under CC0). Proposed text:
"
Text and abstract content are available under the [https://creativecommons.org/licenses/by-sa/4.0/ Creative Commons Attribution-ShareAlike License]; the labels of objects from [[f:|Wikifunctions]] are available under the [https://creativecommons.org/publicdomain/zero/1.0/ Creative Commons CC0 License]; additional terms may apply. See [https://foundation.wikimedia.org/wiki/Special:MyLanguage/Policy:Terms_of_Use Terms of Use] for details.
"
@Feeglgeef: As you probably imagine, this text is very tightly controlled by the Wikimedia Foundation's Legal department. I think the first port of call should be a discussion about why you might want to change things, rather than a rush to specific re-wordings, before approaching them for sign-off. Jdforrester (WMF) (talk) 14:28, 12 May 2026 (UTC)Reply
Well I briefly summarized my justification, my proposed text was just an idea for a starting point. Basically, the abstract content is not really "text", so the footer doesn't actually tell the reader what they're allowed to do with it, and I argue that the current wording implies that the labels are licensed under CC-BY-SA 4, when they aren't. I think a change is critical as otherwise we're not showing the reader a license, or, arguably, in the case of labels, showing users a license that does not apply, which is a pretty bad thing. Feeglgeef (talk) 14:51, 12 May 2026 (UTC)Reply
Latest comment: 16 days ago5 comments4 people in discussion
I'd think we should add f:Z33068 here. The function allows you to form a paragraph out of sentences and handles languages having different standards of whether to add a space between them, and adding it here would make finding it easier. I'm not sure what policy we want to have for the suggested functions, this idea might help formulate it. Feeglgeef (talk) 16:06, 12 May 2026 (UTC)Reply
Latest comment: 21 days ago8 comments4 people in discussion
https://abstract-data.toolforge.org/ is a very useful tool, but it doesn't seem to have anything pointing to the location of its source code. Is it closed-source or unfree?
While I'm at it I feel I should suggest having language pages' paths formatted differently from how they are currently—at the moment it's /languages/Toki%20Pona when something like /languages/tok would be more suitable. —rae5e<talk>
Thank you. I think a link to that repository should be put in a footer somewhere on the website as I wouldn't have found that if not for you. —rae5e<talk>02:30, 13 May 2026 (UTC)Reply
Thanks for the feedback and the report, fixed both things, we have now the link to the repo in the side bar footer, and also the language codes are used in the URLs. Thanks! DSantamaria-WMF (talk) 11:46, 13 May 2026 (UTC)Reply
I think the use of flags is not really harmful since this is not a language selector, it is just a list of languages. Of course not every language has an associated flag, for example Latin, which does look a bit awkward, but it can't be helped. Maybe give languages without a flag a unique icon from Wikimedia Commons? e.g.
I thought I saw 🏛️ being used for Latin earlier. But of course, as far as the Unicode Consortium is concerned, 🇬🇧 doesn't mean 'English', no more than 🏳️🌈 means 'Polari'; technically, it doesn't even mean 'United Kingdom', just the letters 🇺 and 🇰 next to each other (which linguistically would indicate Ukrainian in ISO 639, but these are 'regional indicator symbols'). Arlo Barnes (talk) 17:21, 14 May 2026 (UTC)Reply
As seems (from this comment and also others' comments) that flags are a little bit controversial, I just removed them, IMHO it was just an aesthetic concept, I like the look and feel that flags bring to the language labels, but happy to remove them if make some people feel uncomfortable with the concept. DSantamaria-WMF (talk) 05:54, 15 May 2026 (UTC)Reply
Latest comment: 21 days ago2 comments2 people in discussion
Make it more user-friendly by adding drag-and-drop compenots and one click additions, and make it similar to a visual macro buidler. ChippyTechGH (talk) 01:00, 15 May 2026 (UTC)Reply
Latest comment: 21 days ago6 comments2 people in discussion
Hi all, I've just created infobox for person (Z35167). All it can really do presently is display the name of the person in the chosen language and in the person's native language, but it's a good start. I started writing it as a composition but chose to switch to writing it in JavaScript instead, which ended up being less headache-inducing (managing a large list of strings to concatenate together is not fun, plus compositions bring lots of additional overhead). Unfortunately, this means that the actual useful parts of the infobox—the information about the person themself—is not really doable. I'd need to dereference the Wikidata property references to get their label in the requested language, but since they're references and I'm working with code, not compositions, I can't just call fetch Wikidata property (Z6822) and be done with it. If there's a WikiLambda API to do this inside of the JS itself that would be great and would solve everything, but at the moment that alone is what's holding it back, or so it seems. I can get the actual values of statements just fine, though. If I am missing some amazing WikiLambda API function that will solve this problem for me by letting me dereference the PID, then please let me know because that would be great.
If you want to look at an example of the infobox right meow, you can view Q317521 in Toki Pona and see how it states Musk's name in both Toki Pona and his native English name. COOL!
My hope is that this can be made less barebones in the near future. Infoboxes are a great way to get quick information on a subject and can fill in the informational gaps in the presently sparse articles we have at the moment, all while staying in the user's requested language. Feedback is appreciated! —rae5e<talk>02:58, 15 May 2026 (UTC)Reply
Thank you for this! I wonder if perhaps it would be better to create one "infobox" function and then have compositions call that, making wd retrival possible? Feeglgeef (talk) 03:38, 15 May 2026 (UTC)Reply
Working on that at the moment, I think I've got it working but I'm hitting a ratelimit in the orchestrator so I don't know for sure. The main issue with it now is that the actual infobox template (Z35175) wrapper was programmed in JS so as to not be a pain in the ass, so this means that it can only take in strings, HTML fragments, etc. so the retrieval of Wikidata stuff still needs to be done by the caller and is rather verbose (see the main implementation). The niceties will come soon later once I know that it all works at a lower level, though. —rae5e<talk>05:04, 15 May 2026 (UTC)Reply
So the problem now seems to be that when label of Wikidata property in language (Z29825) isn't being faulty, it's being incredibly slow. Considering retrieving Wikidata items from their references seems to take, like, four to five seconds, and we'll have tens of statements in these infoboxes, I don't see how the property names could be retrieved in a way that doesn't cause the orchestrator to time out or hit a ratelimit. —rae5e<talk>06:01, 15 May 2026 (UTC)Reply
It works now, a little rough around the edges, also very slow, but I think I'm mostly happy with it. Of course it would be great if all you needed to provide to the template function to get a label-statement row was the property reference itself, but I'm too sleep-deprived to figure that out at the moment. I made five bespoke functions specifically for this infobox, more than I would like, but it's probably not that bad. I'm just hoping I didn't duplicate any functionality in trying to make the composition less verbose and repetitive. —rae5e<talk>07:15, 15 May 2026 (UTC)Reply
Wikifunctions & Abstract Wikipedia Newsletter #248 is out: A higher meaning
Latest comment: 21 days ago1 comment1 person in discussion
There is a new update for Abstract Wikipedia and Wikifunctions. Please, come and read it!
In this issue, we discuss functions creating language fragments, we present our 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!
Latest comment: 10 days ago12 comments5 people in discussion
Yes, this question is probably easily answerable through a Web search, but I thought I'd ask here anyways. I am unfortunately not bilingual... I know Toki Pona, but it's a constructed language. I'd love to be a polyglot of some sorts but that is a future thing. I've been trying to translate pages into tok, for funsies mostly.
At any rate, I want to convert some of the un-translated pages, namely Feeglgeef's policy drafts, into ones that can be translated (and then translate them into Toki Pona of course). I think I have to be a translation administrator for this? Which is a process that I'd have to apply for, and I doubt I have the credentials to be accepted for such a role. Regardless, is there a way I can go about this without having to do it through someone else? I can probably easily find documentation on marking pages for translation but I don't know how much I'm actually capable of doing as just a regular user. Should I apply? —rae5e<talk>14:15, 20 May 2026 (UTC)Reply
The step of marking a page or translation for the first time or after changes must be done by a translation administrator.
I recommend learning the <translate> and <tvar> syntax and using it on a few pages before applying for this permission. After you do it on a few pages, and you feel confident, and you want to do it more, you can ask for the permission. Amir E. Aharoni (talk) 14:28, 20 May 2026 (UTC)Reply
Just to confirm, did I mark up this page for translation properly? I thought to give the hatnote its own <translate> enclosure so as to exclude the indent and italicization from needing to be included in the translatable text. —rae5e<talk>15:10, 20 May 2026 (UTC)Reply
Mostly properly, but don't exclude '' for italics from translation. It's generally a good idea to exclude complex markup from translation because it's hard for many people to type, and it usually stays the same in translation anyway. '' for italics is different, however: it's very simple to type and familiar to most editors; italic letters are used differently in different languages, and in some languages they aren't used at all, so translators need the freedom to use them appropriately; this markup can also appear in the middle of a translation unit and not only in the ends. Amir E. Aharoni (talk) 15:35, 20 May 2026 (UTC)Reply
Thank you for the guidance. Should the italics be included if they are used over the entire hatnote? I figure that placement of italics should be left up to the discretion of the translators, but the hatnote itself is meant to be entirely italicized, I would think irrespective of the language it's in. Is this the right idea or should they still be kept within the translation unit? —rae5e<talk>15:45, 20 May 2026 (UTC)Reply
Yes, italics should be included in the translation unit if they are used over the entire hatnote. Some languages don't use italic writing at all, so it shouldn't be forced. Amir E. Aharoni (talk) 18:36, 20 May 2026 (UTC)Reply
I'd support a translation administrator request;), for reasons below. I'm not sure why we need a seperate translation administrator right, or why we have to call it an "administrator" (deciding that a page could be translated is a much less important role than, say, page deletion, or blocking). We picked three of them (well, one of them went through the WMF, so we picked two), they don't appear very active, though, only marking 9 times this month, zero (0) of which were for pages marked for the first time. Both community translation admins used their global history and rights to get the role and only stop by occasionally, so having one who actually edits here would be nice. Feeglgeef (talk) 15:06, 20 May 2026 (UTC)Reply
This reply echos my philosophy of a sort of wiki-xenophobia (the term xenophobia is probably too harsh, and I wouldn't consider myself one in real life, but it's the best word I can think of), I generally distrust users with a lot of global rights (both global sysop etc. and large amounts of local rights) who come make metapedian contributions, not as people but to their ability to handle Wikifunctions and Abstract Wikipedia as incredibly unique and technically complex projects. I apologize if it my opinions come off as rude or ungrateful, I do appreciate the work of our translation administrators. Feeglgeef (talk) 15:26, 20 May 2026 (UTC)Reply
You don't bother me, it's fine. I think they definitely have a place, they can be useful and they usually are. Obviously local admins and what have you that earned their roles through the trust and reputation of the specific community they are in are going to occupy a more trusting position in my mind than a global sysop or global anything. Specialized role members are good and healthy in the long term; I think we are giving these privileges to global users sparingly as the project is still in its infancy and as core contributors emerge and take up key positions we will have a more well-rounded and self-sustaining community with less global privileges needed to take up certain tasks. Wikifunctions probably needed some Foundation members or other staff to act as functioneers initially while the general community was still orienting themselves with WikiLambda and working on applying for the role, but now we have 74(!) of them and the number of normal members using their specialized skills outnumbers those who were "grandfathered" in (for lack of a better term) or similar. The wiki is young—it just needs time. I myself have been considering applying for sysop privileges since they are obviously needed (there being exactly Zero of them at the moment); I've been weighing the pros and cons of such a commitment, it's obviously a lot to take up. I wish your sysop request went through, I think you would have made a great admin here. I'm unsure of what others think of my capabilities, I'm rather in-and-out around these social spaces so I don't know if there's much to go off of. —rae5e<talk>15:55, 20 May 2026 (UTC)Reply
Totally agree, and I'd support a sysopship request as well, though I'm apparently not good at assessing what the community considers supportable in admin candidate;).
Off-topic, but interestingly, the sysop toolset allows you to grant yourself translation adminship. I'm not sure if sysops are expected not to grant themselves the permissions (kind of like how on enwiki 'crats are expected not grant themselves any rights without discussion despite having the technical rights), but I did it to myself on WF because another sysop had. Additionally, the functioneer right exists on this wiki, with the same rights on WF, despite all of them not doing anything on this wiki. I believe this is because, on the technical side, both AW and WF are powered by the same MediaWiki extension (Wikilambda), with one wiki set to a mode for abstract articles and another set to a mode for ZObjects. Checking the Dagbani Wikipedia supports this theory. Feeglgeef (talk) 18:00, 20 May 2026 (UTC)Reply
It always depends on the local policy. For Wikifunctions it is: Administrators do not need to undergo another discussion to become translation administrators; they can self-grant the rights to their account if necessary. Temporary administrators are not allowed to self-grant permanent translation administrator rights.
If you don't consider yourself a xenophobe in real life, I would recommend not calling yourself that here, or anywhere really. Especially since it was the ideological capture during the 2010s of the Croatian-language Wikipedia w:hr: by actual xenophobes that was part of the impetus for Abstract Wikipedia according to Denny's blog. Arlo Barnes (talk) 22:10, 26 May 2026 (UTC)Reply
Latest comment: 15 days ago1 comment1 person in discussion
Hi all! I've written some draft policies and guidelines over the last few days. We're not a bureaucracy, so the point is not to set some rules but to kick off some discussions as to how our wiki will work.
So far, I've created:
I've written them as my opinion on what should happen, but I'm hoping to align them with community consensus as we discuss them more. Feeglgeef (talk) 13:44, 21 May 2026 (UTC)Reply
Wikifunctions & Abstract Wikipedia Newsletter #249 is out: Annual plan 2026-2027
Latest comment: 11 days ago1 comment1 person in discussion
There is a new update for Abstract Wikipedia and Wikifunctions. Please, come and read it!
In this issue, we present you the current draft of objectives for Wikifunctions and Abstract Wikipedia in the WMF Annual Plan 2026-2027, and we take a look at the latest software developments.
Want to catch up with the previous updates? Check our archive!
Latest comment: 9 days ago4 comments3 people in discussion
There is a discussion happening about what the notability criteria for Abstract Wikipedia should be, and in trying to participate I've found my idea of Abstract Wikipedia is awfully abstract. Is Abstract Wikipedia supposed to abstract Wikipedia, as in abstracting information from existing articles on the language Wikipedias (barring new contributions), or is it supposed to become the Abstract Wikipedia, supporting collaboration across all languages like it's the language Wikipedia to end all language Wikipedias (allowing new contributions)? I thought the answer would be obvious, but the name Abstract Wikipedia is a bit ambiguous. Am I missing something? Some helpful person (talk) 02:16, 27 May 2026 (UTC)Reply
I think (@DVrandecic (WMF)?) the idea is (and I personally prefer) the latter. I believe that, given the fact that it's much easier to write a concrete article than an abstract article, and the fact that the community of potential future contributors on enwiki is skeptical at best, we ultimately will never expand beyond the size of other wikis, but I see no problem with allowing volunteers to add information not on other wikis (it's probably not the most effective, but they're volunteers, beggars can't be choosers), as long as it's not vandalism, useless, or promotional slop. Feeglgeef (talk) 02:31, 27 May 2026 (UTC)Reply
@Some helpful person Abstract Wikipedia is a Wikipedia, where people can collaborate across languages on articles, which can then be used to fill gaps in the existing Wikipedias. Whereas I expect that current Wikipedia articles might be used as a convenient starting point for many of the articles in Abstract Wikipedia, this is more a consequence of Wikipedia being one of the best places to go to to find reliable knowledge, but that is not part of how it is supposed to work. So, this is not to abstract the existing Wikipedias, but to collaborate on an Abstract Wikipedia. At no point is this meant to replace existing Wikipedias. (Thanks to @Feeglgeef for the ping!) --DVrandecic (WMF) (talk) 17:01, 27 May 2026 (UTC)Reply
This could then be suplemented by helper templates: {{Call|Z26039|{{Wikidata item argument reference}}|{{Wikidata item reference|Q634}}|{{Language argument reference}}}}
Latest comment: 13 hours ago18 comments3 people in discussion
Some NLG functions give default texts, like Z33420 will give text like "Paris ∈ {city}". sometimes in other languages the English text is show. Currently there is no visual clue that these texts are not normal text in the requested language. I propose we mark these text with color Paris ∈ {city} with something like <span style="color:magenta;">Paris ∈ {city}</span>. To have this configurable/maintainable this could be included in a function, called NLG default text or so, with a text as input an a text in color as output. The exact formatting like magenta color or gray background or something else can be discussed/decided later. To have it even more configurable on personal stylesheets it could use a class like <span class="NLG Default text">Paris ∈ {city}</span>. What do you think? Could somebody make such a function already? HenkvD (talk) 12:00, 29 May 2026 (UTC)Reply
The are technically just monolingual texts in a language called "multiple languages". I threw a prototype together really quickly, f:Z35839. It will accept strings, monolingual texts, and html fragments as input, so you have to select which type you want. Feeglgeef (talk) 14:59, 29 May 2026 (UTC)Reply
OK, thanks, I added it to f:Z26039 and works as expected, see here. The test for the function with default text now fails because it now is in magenta color. That was to be expected. I will leave the tests unchanged if that is OK with you, as we might need to change the exact formatting.
Paris (Q90) in a language vls should give a magenta text. Instead it gives "Wikifunctions returned a failed response: Unspecified error". f:Z33422 results "Parys ∈ {stad}" (as a string). f:Z26039 also gives "Parys ∈ {stad}", but it's test f:Z33726 gives an HTML equivalent, not a string. HenkvD (talk) 17:59, 30 May 2026 (UTC)Reply
I agree with the above that this should not be applied to functions which return strings or monolingual text. If anything, it might work to insert it into functions returning HTML. The most egregious problems I've seen are when I tried to render into an RTL language (e.g. Hebrew 0 try on Q408), and it spilled all the formatting all over the article. I will revert the change to the string default at f:Z33421, but suggest it is tested carefully if implemented elsewhere. In general I prefer just marking with spans rather than colours at this stage. --99of9 (talk) 04:49, 3 June 2026 (UTC)Reply
Perhaps mark with spans given a specific ID and then allow users to use a userscript/gadget to paint them magenta? That seems like the most considerate approach. Feeglgeef (talk) 05:12, 3 June 2026 (UTC)Reply
I will (carefully) try some other alternatives, and use a personal class in my userscript for <span class="NLG Default text">. HenkvD (talk) 14:05, 4 June 2026 (UTC)Reply
I created a new implementation for f:Z35921 using emoji text, resulting in texts like "❌≪Paris ∈ {city}≫❌". It works on Q90 for not yet specified languages like Zeelandic. I will be bold in adding this other functions that use default texts. HenkvD (talk) 11:26, 5 June 2026 (UTC)Reply
Latest comment: 1 hour ago9 comments5 people in discussion
I haven't seen any unresolved objections to my proposal for a policy for deletion. Does anybody have any issues, and, if not, is it ok to ratify as an actual policy? I intend to remove the draft template and replace it with a policy template unless anyone voices any objection within a week. Feeglgeef (talk) 20:55, 29 May 2026 (UTC)Reply
I'm on Brave browser. Nevertheless, forget it. The culprit might be some random customization I did to my system which I cannot recollect. The reason is the span tag only though, tried a preview kicking out a text to just outside the tag and it worked. Bunnypranav (talk) 14:23, 30 May 2026 (UTC)Reply
Globally, it looks fine. I think that reasons 7 and 8 may need some examples/clarifications. There is no global consensus when it comes to creating categories. For example, categories for building interiors and exteriors. Personally, I feel that they are useful for easier discoverability. John Samuel (talk) 15:39, 30 May 2026 (UTC)Reply
I've copied them over from enwiki. They're probably included in "content otherwise not suited for an encyclopedia." Since sysops can't speedy them, it'd be up to commenters on Abstract:RFD to determine. Feeglgeef (talk) 16:48, 30 May 2026 (UTC)Reply
Latest comment: 4 days ago1 comment1 person in discussion
There is a new update for Abstract Wikipedia and Wikifunctions. Please, come and read it!
In this issue, we present you a recollection of our work so far, now that we celebrate our 250th newsletter, we share with you a summary of our latest outreach activities, and we take a look at the latest software developments.
Want to catch up with the previous updates? Check our archive!
Latest comment: 10 hours ago1 comment1 person in discussion
There is a new update for Abstract Wikipedia and Wikifunctions. Please, come and read it!
In this issue, we introduce our first function to import images on Abstract Wikipedia, we present our Functions of the Week, and we take a look at the latest software developments.
Want to catch up with the previous updates? Check our archive!
Done see Special:Diff/7692. Cheers, VIGNERON (talk) 09:08, 20 May 2026 (UTC)
Toki Pona🌐Toki Pona. — rae5e <talk> 16:37, 14 May 2026 (UTC)