This is an archive of past discussions. Do not edit the contents of this page.
If you wish to start a new discussion or revive an old one, please do so on the current talk page.
Abstract Wikipedia should use a different mw-wiki-logo than Wikipedia for Vector 2010 skin
Hello friends. I've been asked to start a community conversation about this. I'd like to propose that Abstract Wikipedia create its own logo, so that folks visiting this wiki don't get it mixed up with Wikipedia. Even though this project is under the Wikipedia domain, I think it's pretty unique and it'd make sense to make sure it doesn't get mixed up with enwiki or other Wikipedias by newbies googling for Wikipedia articles. Thoughts? Thanks. Novem Linguae (talk) 12:02, 1 May 2026 (UTC)
Latest comment: 5 months ago1 comment1 person in discussion
The Wikidata tool Reasonator already automatically creates several sentences in English describing human Wikidata items using auto_long_desc.js under a GPL 2.0 free software license without using any large language model or other AI.
Latest comment: 5 months ago7 comments4 people in discussion
Might be a stupid question but what articles are/will be allowed on Abstract Wikipedia? How far is it meant to expand? The language Wikipedias have some differing policies, so might not be as simple as copying those. Personally I find the idea of creating an article for any and every Wikidata item really cool and a good baseline for what can have an article, but wouldn't ~120 million abstract articles become unwieldy? If the only requirement is that the article topic has a Wikidata item, then there are many interesting possibilities; one could write about individual dates, Wikidata test items, even Wikimedia disambiguation pages. Have not found where this is explained, if anywhere. This may be up to common sense, but trouble is, couldn't one create an encyclopedically meaningful article on just about anything? Pretty important policy not to have if it's undecided, though is not a problem at the moment. Just wondering. Some helpful person (talk) 23:36, 1 May 2026 (UTC)
Ah, I forgot about that page. So it is meant to abstract information from existing Wikipedia articles? Makes sense, though it still raises the question of creating new articles. Some helpful person (talk) 00:41, 2 May 2026 (UTC)
At this juncture, I don't think anyone has in mind drafting anything new here as such: this is just responding to existing Wikidata items and the possibility of new Wikipedia articles drafted from them, using Wikifunctions. Koavf (talk) 00:51, 2 May 2026 (UTC)
I don't think we ever get any article an existing wiki does not have. Even if abstract content creation gets as fast as reasonably possible, it will never beat out typing text, so we will never catch up with, say, enwiki or eswiki. Feeglgeef (talk) 01:10, 2 May 2026 (UTC)
It's also a question of policy. There are topics about which things could be said, but which wouldn't meet the baseline notability or other criteria of the big monolingual wikis. Arlo Barnes (talk) 20:22, 2 May 2026 (UTC)
This is true, if we keep d:'s notability policy (which seems like the most natural one) then there are many subjects that we theoretically can talk about that don't meet the GNG and similar guidelines. Feeglgeef (talk) 22:25, 2 May 2026 (UTC)
How many articles in how many languages are actually fully available without errors
The most important thing to count is already listed there: How many articles in how many languages are actually fully available without errors? It should be not just a count, but a list: I want to see which articles are readable in which languages; which articles are readable in some languages, but not others (which ones?); which articles are not readable in any language; etc.
An even more relevant, but much harder to measure thing is how many of those articles are actually more useful than not having an article at all. There is no article about Boston in many languages, but Q100, which currently says "Boston is the capital of Massachusetts.Boston is the largest city of Massachusetts." is not significantly more useful than nothing at all even if it's fully rendered in another language in which there is no concrete article about it. Amir E. Aharoni (talk) 12:12, 2 May 2026 (UTC)
The status update is about two projects and so I can understand if there are comments here. What do you think about creating a status update overview page with links to the status updates in Abstract Wikipedia to offer the possibility to discuss the status updates and especially things related to Abstract Wikipedia there. Hogü-456 (talk) 18:57, 4 May 2026 (UTC)
I don't think that's necessary. You can just include your abstractwiki (as in, the live wiki, not the project) related comments on the page on f:, or, if for some reason that's not possible, as a reply to the newsletter announcement here. The point is, the project chat is crowded enough with topics as it is, ideally it should be more focussed on general matters of discussion than close-ended enquiries about topics that have their own talk page. I find Amire80's use of a new == heading here to be improper. Feeglgeef (talk) 19:32, 4 May 2026 (UTC)
Wikifunctions & Abstract Wikipedia Newsletter #246 is out: Request for input: what should we count for Abstract Wikipedia
Latest comment: 5 months ago1 comment1 person in discussion
There is a new update for Abstract Wikipedia and Wikifunctions. Please, come and read it!
In this issue, we ask you what would be the relevant metrics for Abstract Wikipedia, we discuss our latest news on Composition Language v2, and we take a look at the latest software developments.
Want to catch up with the previous updates? Check our archive!
Latest comment: 3 months ago26 comments7 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? @Amir E. Aharoni Yes, it is correct. For pinyin transliterations, the only way is lemma-based. I'll also encourage you to read in underrepresented Varieties of Chinese:-) I am working on them on English Wiktionary. ——内存溢出的猫 (talk) 11:21, 18 June 2026 (UTC)
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.
In the absence of consensus on such things as these (and awaiting any official policy pages) I have written f:User:Theki/best practices on my Wikifunctions userpage. You are welcome to read it if you wish. —rae5e<talk>17:20, 2 May 2026 (UTC)
The output of Q241691 looks OK to me in this regard. How was it done?
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)
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)
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)
@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)
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)
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)
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)
I'm not totally sure what you want to track, but I'm confident that this will find all my uses. --99of9 (talk) 02:10, 29 May 2026 (UTC)
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)
@HenkvD: I originally thought this was a bit hacky, but it actually makes sense -- the spacing is determined by punctuation. For example, English used to have the convention of using two spaces, Chinese uses no spaces, and in Tibetan, ། marks the end of a short phrase or sentence (still needs a space after it), while ༎ marks the end of a paragraph. (Yes, there's a dedicated paragraph-ending punctuation mark!) This at least matches our current abstraction model well. Also, I don't think this will lead to extra spaces. ——内存溢出的猫 (talk) 11:21, 18 June 2026 (UTC)
<tangent>「Yes, there's a dedicated paragraph-ending punctuation mark!」 We English folk have used ¶ for that before, so I don't suppose a paragraph mark in Tibetan is all that unusual... </tangent>—rae5e<talk>17:25, 18 June 2026 (UTC)
I agree. We should not change functions which correctly return sentences into functions which return sentences with spaces stuck to them. Z35672 (search, stats) works well until the performance is good enough for Z33068 (search, stats). --99of9 (talk) 12:34, 18 June 2026 (UTC)
I think if the current WL system allowed for starting tags and then ending them at a later indeterminate point, Z33068's performance issues could be perhaps mitigated slightly. One could use a start paragraph call, followed by some sentences in some well-established form, and then close the paragraph with an end paragraph call. An issue I've had with paragraphs is that you can't see the paragraph build itself up sentence-by-sentence, and the failure of a single function call means the inability of the entire paragraph to render at all—something that would, of course, be fixed by making paragraphs more granular in this way. Something to think about, although I am sure it's not possible presently (since the abstract HTML renderer doesn't build up the document gradually, and instead expects the HTML to be well-formed from the outset). —rae5e<talk>17:28, 18 June 2026 (UTC)
Each fragment is its own div, and you can't do <div><p></div><div>[text]</div><div></p></div>, it will break the browser's tag grouping. Feeglgeef (talk) 18:55, 18 June 2026 (UTC)
Hence why I mentioned that I don't suspect it will be possible. The concept is just something to think about. —rae5e<talk>19:34, 18 June 2026 (UTC)
Again, this should definitely have been on the talk page for that status update. This isn't the everything page, it should be used for discussion relating to the wiki. Feeglgeef (talk) 18:26, 2 May 2026 (UTC)
It's not a question just about the status update, even if it was prompted by it. It's a question about Abstract Wikipedia that can be relevant beyond the status update.
Stop policing how people use discussion pages without a particularly good reason. If you don't have an answer to the actual question, don't write anything. Amir E. Aharoni (talk) 19:38, 2 May 2026 (UTC)
I have to agree with Feeglgeef that this would be better raised on the status update's talk page itself. —rae5e<talk>19:42, 2 May 2026 (UTC)
I'm "policing" which discussion pages are being used for the same reason different discussion spaces exist in the first place. And your distinction between "just about" and "prompted by" is irrelevant. If I want to ask someone how they did something, I would ask them first, not go to a general discussion board. This is still the project chat, not a Q&A zone. @DVrandecic (WMF), can you please answer the question? Feeglgeef (talk) 22:22, 2 May 2026 (UTC)
I have a local script that I have run on a local copy. Nothing more complicated than that. Could also be very wrong -- the script hasn't been peer-reviewed or anything. --DVrandecic (WMF) (talk) 08:54, 4 May 2026 (UTC)
Latest comment: 5 months 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)
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)
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)
Well, no, the superlative form is chosen by f:Z12203. I think there's a bug with the English implementation that calls that function wrong. Feeglgeef (talk) 22:19, 6 May 2026 (UTC)
@Somepinkdude I did find the item fast (Q19807466) which was linked to a concept database's entry for "fast"; I have at least linked it to the English lexeme "fast" and will try to add more links at a better hour. Mahir256 (talk) 04:18, 7 May 2026 (UTC)
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)
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)
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)
Wikifunctions & Abstract Wikipedia Newsletter #247 is out: References from Wikidata now available
Latest comment: 5 months 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: 5 months 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)
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)
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)
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)
Proposals on the architecture of Abstract Content rendering
Latest comment: 5 months 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)
Latest comment: 5 months 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)
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)
Latest comment: 4 months 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)
Latest comment: 4 months 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)
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)
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)
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)
Latest comment: 4 months 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)
Latest comment: 4 months 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)
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)
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)
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)
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)
Wikifunctions & Abstract Wikipedia Newsletter #248 is out: A higher meaning
Latest comment: 4 months 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: 4 months 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)
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)
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)
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)
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)
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)
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)
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)
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)
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)
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)
Latest comment: 4 months 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)
Wikifunctions & Abstract Wikipedia Newsletter #249 is out: Annual plan 2026-2027
Latest comment: 4 months 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: 4 months 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)
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)
@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)
This could then be suplemented by helper templates: {{Call|Z26039|{{Wikidata item argument reference}}|{{Wikidata item reference|Q634}}|{{Language argument reference}}}}
Latest comment: 4 months 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)
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)
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)
You shouldn't be returning HTML in string-typed functions. I'm not sure, then, how we implement your proposal, actually. Feeglgeef (talk) 18:54, 30 May 2026 (UTC)
I tried with f:Z35921 but now the output is the literal text, and not HTML. Does anybody have an idea how to implement the text in a color?
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)
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)
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)
If possible, can you use <span lang="mul">? This would allow it to also catch some instances automatically. Feeglgeef (talk) 16:14, 4 June 2026 (UTC)
I have done so, but how can I set my personal stylesheet to show color magenta with <span lang="mul">? HenkvD (talk) 22:20, 4 June 2026 (UTC)
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)
Latest comment: 4 months 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)
@Bunnypranav: I can see the text everywhere (I tested connected and not connected, on my phone, laptop, with Chrome or Firefox; what system do you use?). As the name suggest, the span anchor is here to create an HTML anchor, so you can do link like Abstract_Wikipedia:Deletion_policy#7. Cheers, VIGNERON (talk) 13:49, 30 May 2026 (UTC)
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)
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)
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)
Support this then. Feeglgeef (talk) 12:31, 1 May 2026 (UTC)
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)
