Wiktionary talk:Per-language pages proposal

Idea about page structure[edit]

Language name as namespace, language code as its alias, term as page title. This way we can also easily do language-based search (a basic feature which Wiktionary lacks). We can add a drop-down list just before the Search box to select namespace/language. --Z 21:49, 2 February 2014 (UTC)[reply]

That would be way too many namespaces and it would mean that changing a language code will require more than just an admin with a bot. --Wiki Tiki 89 21:54, 2 February 2014 (UTC)[reply]

What do you mean exactly? What you said apparently applies to the idea of creating terms as subpages of the language codes (or vice versa) as well. --Z 22:37, 2 February 2014 (UTC)[reply]

Normal Wiktionary admins or bureaucrats can't change namespaces. You need to edit the wiki configuration files to do that, it's hardcoded. —CodeCa t 22:39, 2 February 2014 (UTC)[reply]

I understood your idea to mean that "English:" or "en:" will be used as a namespace. Was I wrong? --Wiki Tiki 89 22:39, 2 February 2014 (UTC)[reply]

Oh, I see now. --Z 22:44, 2 February 2014 (UTC)[reply]

Chinese character entries[edit]

Re "It might also mean we could not name our Chinese character entries "Translingual" anymore (which is not so bad?)." Why is that (beyond the same issue that there is with any other translingual entry)? --Wiki Tiki 89 22:03, 2 February 2014 (UTC)[reply]

Because they're not really translingual, they only apply to languages that use Chinese characters. If we keep it as it is, then that would mean assuming that if a translingual entry exists for character X, then that entry applies to all languages that have a word with character X. —CodeCa t 22:19, 2 February 2014 (UTC)[reply]

Which is almost always true. The languages that use Chinese characters, usually retain their meaning. --Wiki Tiki 89 22:35, 2 February 2014 (UTC)[reply]

Absolutely always or almost always? —CodeCa t 22:37, 2 February 2014 (UTC)[reply]

It doesn't have to be absolutely always. --Wiki Tiki 89 22:38, 2 February 2014 (UTC)[reply]

What happens in the rare cases where it's not true? —CodeCa t 22:39, 2 February 2014 (UTC)[reply]

An irrelevant translingual section is displayed. --Wiki Tiki 89 22:40, 2 February 2014 (UTC)[reply]

I support using "Translingual", even if all definitions are in place for each CJKV language and all Sinitic varieties, if they're important. Differences in meanings/usages are not uncommon at all.

Character 食, which has only a generic meaning "to eat/eating" but is hardly ever used in modern Mandarin in this sense but it's used as a component in all CJKV languages, vernacular Cantonese. Originally, they're all Chinese in a broad sense of the language but many Han characters have undefined part of speech, and a broad meaning. Stroke orders, etymology, broad meanings, other character information are better kept at "Translingual". Unihan database info for Han characters, e.g. [食@Unihan is also quite generic, even though it has more information specific to Chinese or Mandarin. --Anatoli ^{(обсудить}/^вклад) 23:55, 2 February 2014 (UTC)[reply]

It's also worth thinking in terms of how CJKV languages treat separate Han characters. There are specific Character dictionaries 字典, as opposed to "word dictionaries", which explain readings, etymologies, stroke orders in relation to their languages. There are things that are common for each, though. --Anatoli ^{(обсудить}/^вклад) 00:33, 3 February 2014 (UTC)[reply]

We could treat scripts as languages, and have "language" sections for the characters that are part of them. —CodeCa t 00:38, 3 February 2014 (UTC)[reply]

What do you suggest specifically? "Han" as a large section, with Mandarin, Japanese, etc. as subsections? --Anatoli ^{(обсудить}/^вклад) 00:53, 3 February 2014 (UTC)[reply]

Not as subsections. Just rename "Translingual" to "Han script". —CodeCa t 00:56, 3 February 2014 (UTC)[reply]

I'm tentatively OK with "Han script" but note that we already have "Han character", "Kanji", "Hanzi" and "Hanja" subheaders, which mean about the same thing. --Anatoli ^{(обсудить}/^вклад) 01:02, 3 February 2014 (UTC)[reply]

I don't think that's necessary. But in either case, switching the ==Translingual== header to ==Han script== has nothing to do with the per-language pages proposal. --Wiki Tiki 89 05:01, 3 February 2014 (UTC)[reply]

Well, it does, though, insofar as figuring out what to call the subpage for such data. Would we still use the mul lang code? Or would we have to come up with something else? ‑‑ Eiríkr Útlendi │ Tala við mig 00:28, 7 February 2014 (UTC)[reply]
But that's a general question about what to do with translingual sections as a whole and not specific to Chinese characters. But the way I see it, why come up with something else when the mul code works fine? --Wiki Tiki 89 00:35, 7 February 2014 (UTC)[reply]

WikiTiki is right, this question is orthogonal to splitting pages onto subpages. If our current use of ==Translingual== as a header for Chinese characters in general, or for any specific character, is as right as our use of ==German== as a header for essen, then that/those Chinese character(s) should go on (a) mul subpage(s) to the same extent that essen should go on a de subpage. If our use of ==Translingual== as a header is not right, either in general or in any specific case, then we need to change that regardless of whether or not we split pages. - -sche (discuss) 00:55, 7 February 2014 (UTC)[reply]

Discussion moved to Wiktionary:Beer parlour/2014/February#Chinese character entries in Translingual sections.

Backwards compatibility for users[edit]

By which I do not mean the technical backward compatibility, but instead the UI experience that readers have. This could be preserved by having foo/en and foo/fr transclude on foo so that, from the reader's perspective, the page foo will look exactly the same as it currently does. Some of the implementation problems (like what language to redirect a user to if the one they want does not exist) can be solved easily with this; if the Ukrainian does not exist, send them to the page with all the transclusions (not, say, the Russian page). Also, the IWs can be fixed slowly without leaving broken links or anything, because all entries will still be located on the all-language pages, at least from a reader's perspective. The only problem I can see with this is that it requires a bot to continually create these pages as language-specific pages are created. —Μετάknowledge^{discuss/deeds} 22:48, 2 February 2014 (UTC)[reply]

I just realised that if we are to take language code etc from the page title, transcluding may be much harder than I thought. But without it, we'd have to use disambiguation pages, which are monumentally stupid. —Μετάknowledge^{discuss/deeds} 22:51, 2 February 2014 (UTC)[reply]

Agreed. Maybe we can make a script that automatically transcludes a page’s subpages into itself (which would require the term/lang format) ~~and beg the MW folk to add a way for {{PAGENAME}} to return the page’s true name even when transcluded~~. — Ungoliant ^(falai) 22:54, 2 February 2014 (UTC)[reply]

We already have Special:PrefixIndex- would probably need to extend that with Lua somehow to get the functionality. DTLHS (talk) 22:56, 2 February 2014 (UTC)[reply]

@Metaknowledge (talk • contribs), does DLTHS's comment address your concern about transcluding? I confess I don't quite understand the problem you describe, in saying "if we are to take language code etc from the page title"...

PS: How the heck does this "ping" feature work? Does {{user}} do it? Does a regular wikilink to a username do it? Does just @NAME do it?

‑‑ Eiríkr Útlendi │ Tala við mig 00:26, 7 February 2014 (UTC)[reply]

On the nature of the problem: one of the advantages of subpages is that we don't have to use langcodes as much; we can just steal 'em from the title. Of course, that's complicated when you're transcluding and the pagetitle is no longer the same.

On the nature of pinging: All of the above (and the handy {{ping}}) do it except just writing a user's handle. —Μετάknowledge^{discuss/deeds} 00:56, 7 February 2014 (UTC)[reply]

“Users” don’t need “backwards compatibility.” Readers need information to be presented simply and clearly. A list of links to the language entries that share a spelling would be much more “compatible” than a confusing duplication of content.

If we can build this right, then search results will take a reader directly to the entry they’re looking for most of the time, anyway. —Michael Z. 2014-02-07 18:12 z

The readers themselves disagree, as evidenced on WT:FEEDBACK, where they already dislike that they can't see definitions when they go to e.g. fleering. If they searched for fleering and then had to click through to fleering/en, and then had to click through again to fleer/en (or to fleer and then fleer/en), it's quite bizarre to think that they would find that "simple" or "clear" or good in any way. - -sche (discuss) 19:17, 7 February 2014 (UTC)[reply]

I am arguing against the kind of redundancy that you are arguing against. I’m also suggesting that the search result should show readers what they’re looking for and they shouldn’t have to click through anything.

That our search field’s default behaviour is “jump” and that we have instituted the self-contradictory notion of “soft redirects” are separate issues. —Michael Z. 2014-03-02 19:26 z

I understood your comment that "a list of links to the language entries that share a spelling would be much more 'compatible' than a confusing duplication of content" to mean that you thought splitting pages and having directories that merely linked to subpages, like this (with foo/en taking you to here, foo/fr taking you to here, etc) was preferable to having directories that transcluded subpages, so I pointed out that average readers had expressed the opposite opinion. If I misunderstood your comment, I apologise. I think that the current arrangement, where there are no subpages at all, is the one with the least duplication/redundancy. Do you agree? - -sche (discuss) 21:45, 2 March 2014 (UTC)[reply]

Transcluding all subpages[edit]

I removed one of the stated disadvantages to this approach, as it seemed to be based on a misunderstanding of what's proposed.

Disadvantages:

Generally, the same disadvantages as our current system. Users have to hunt through the page to find what they want, which eliminates a lot of the logic and usefulness that dedicated subpages would have for the average user.

What's proposed when transcluding all subpages is that there would be both dedicated subpages, and an everything-all-together page. Depending on how the user searches, and / or how preferences and options are configured, users would be directed either to the everything page, or to the lang-specific page. (At least, as I currently envision it.) There may be other disadvantages, but a lack of subpages is not an issue, since those would actually also exist. ‑‑ Eiríkr Útlendi │ Tala við mig 00:21, 7 February 2014 (UTC)[reply]

Yes, I know that's what you meant, and the disadvantage was directed towards that. If all the content is given as one page to the user, then they still have to look through it, the existence of a subpage is not relevant anymore at that point. The subpage is only useful then if the user explicitly requests that language in search or the URL, but that's exactly the situation where the format of the "main" page doesn't matter. So it eliminates the usefulness of a dedicated subpage to the user, whenever the user is not directed to that subpage. —CodeCa t 00:47, 7 February 2014 (UTC)[reply]

No it doesn't. If the user doesn't know what language he/she is searching for, then neither does Wiktionary. If there are multiple languages in an entry, displaying them all at once is the easiest way for the user to figure out which language is relevant. --Wiki Tiki 89 00:59, 7 February 2014 (UTC)[reply]

Not if we list all languages by name. Then they can just select the language from there. —CodeCa t 01:00, 7 February 2014 (UTC)[reply]

But that requires the user to know which language to click on. Otherwise, it's more annoying to have to click on each one one-by-one, than it is to have all of them on one page. --Wiki Tiki 89 01:02, 7 February 2014 (UTC)[reply]

Most users will know what language they want, and for someone who knows the language, transcluding all subpages onto the main page is less convenient (why else would we be doing this, invent things like tabbed languages etc?). The whole point of this change is to optimise Wiktionary for majority use cases. We shouldn't sacrifice usability for the majority to cater for the minority that might not know what language they're looking up. That's backwards. —CodeCa t 01:04, 7 February 2014 (UTC)[reply]

If the user knows what language he/she wants, then the user will search only for that language. --Wiki Tiki 89 01:06, 7 February 2014 (UTC)[reply]

Not necessarily. There might be internal links that don't point to the correct language, or there might be search scripts in browsers (like mine), or incoming links from Wikipedia, or someone might have just typed the word in the URL because they don't know the language code. There are many situations in which the language is known, but the user still ends up on the disambiguation page. —CodeCa t 01:09, 7 February 2014 (UTC)[reply]

Well presumably there would still be a table of contents at the top listing the languages, making it essentially no different from the disambiguation page idea. --Wiki Tiki 89 01:14, 7 February 2014 (UTC)[reply]

The difference is speed. I don't want all the content to be transcluded, because it's too slow. I don't think the need for it justifies the cost. —CodeCa t 01:15, 7 February 2014 (UTC)[reply]

So the only downside is the page loading time. --Wiki Tiki 89 01:20, 7 February 2014 (UTC)[reply]

A disambig page that consists solely of a list of languages is a substantial usability regression from the current everything-all-together display, in that it unnecessarily adds the need for another click-through before users can find anything useful.

To take a different tack, what positives are there to having a page that is just a list of languages that have that given headword? How is that more useful than displaying everything together? I mean just the page itself, ignoring technical considerations, linking, and the like -- I mean solely the page as a newbie user would find it. ‑‑ Eiríkr Útlendi │ Tala við mig 01:18, 7 February 2014 (UTC)[reply]

You're comparing the wrong thing here. You're assuming that if the user lands on a page with all the languages' content, they've found what they need, but that's obviously not true. They have to find what they need within that page too, and that's much harder when pages have many languages on them. There's a lot of scrolling and visual searching involved. A simple list on the other hand is much easier to search through. Why else would all other online dictionaries work with lists of languages? I don't think Wiktionary is being particularly "clever" by doing it differently. If everyone else does it another way, maybe they're onto something and we need to set our pride and complacency aside. —CodeCa t 01:23, 7 February 2014 (UTC)[reply]

At that point, the user can presumably click on the language header to go to the subpage. --Wiki Tiki 89 01:25, 7 February 2014 (UTC)[reply]

You mean, at that point they can first search through the whole page for the correct header, and then go to the subpage if they even think it's useful by that point. —CodeCa t 01:26, 7 February 2014 (UTC)[reply]

You're going in circles, we've already covered that. --Wiki Tiki 89 01:31, 7 February 2014 (UTC)[reply]

Then what is your point? I've made mine. —CodeCa t 01:34, 7 February 2014 (UTC)[reply]

I've made mine too, if you want you can re-read the section. --Wiki Tiki 89 01:37, 7 February 2014 (UTC)[reply]

Then I suppose we just see it differently. —CodeCa t 01:37, 7 February 2014 (UTC)[reply]

@CodeCat, have I correctly understood that your primary objection to transclusion (of all lang-specific subpages of a term onto the all-lang landing page for that term) would be technical in nature, having to do with the speed of the operation? This is an honest question; I'm not trying to pigeonhole, I'm trying to get a handle on everyone's positions. :) ‑‑ Eiríkr Útlendi │ Tala við mig 03:08, 7 February 2014 (UTC)[reply]
- That is my only objection to transclusion and list of subpages combined. I don't think that the majority of users who just want to get to their desired language should wait for the whole page to load just for the benefit of a minority of users. —CodeCa t 03:31, 7 February 2014 (UTC)[reply]
  One of the supposed advantages to subpages which their supporters have cited is that they allow "users who just want to get to their desired language" to get right to that language — by going to its subpage. A user who goes to the main page most likely wants to view all of the languages at once. Hence, the main pages should transclude the subpages (if subpages are used).
  Note how often people complain on WT:FB that they have gone to, say, fleering and not found any definitions (the definitions are at fleer). If the main pages were mere lists of subpages, people who navigated to them would have to make still more clicks just to get a peek at the content they want. That is a bad idea and I imagine it would be quite unpopular with Wiktionary's casual users. - -sche (discuss) 04:51, 7 February 2014 (UTC)[reply]
  But I already showed many examples where someone knows what language they want, but will still end up on the main page. In Firefox I have a search script set up that lets me search words on Wiktionary, either by typing them in the search bar, or by typing "wik" followed by the word in the URL bar. This is probably a pretty common setup among regular Wiktionary users. There is no way that I know of that that script could be adapted to support the language subpages as well. The only way is a workaround at best, to just type the word with /lang at the end of it. But that means having to type that with every single search, which is very bothersome and would actually be a regression for me. I use tabbed languages, so by default, it goes to the last-viewed language. That means I don't have to tell it what language to go to, it remembers it for me. We should do the same with our subpages approach: if the user goes to the main page, but they have a "current language" set during their session, redirect them to the correct subpage. That would be a big usability advantage for this kind of usage.
  
  I also realised that I have another objection against transcluding all subpages. It confuses users who don't realise that there is more than one language on the page, because they normally only see the first language on the page (often English). A list of languages would not allow such confusion. —CodeCa t 14:09, 7 February 2014 (UTC)[reply]
  Why would they "normally only see the first language on the page"? --Wiki Tiki 89 14:30, 7 February 2014 (UTC)[reply]
  
  (@CodeCat) You have a special script for searching Wiktionary from your search or URL bars, and you use tabbed languages. In this respect, you are probably in the minority of people who use this site. And you seem to be saying that once your search script takes you to [[land]], you don't like that you can already see the Dutch content on that page by scrolling down to it without having to click to another page; you would prefer that you landed on a page and then had to go to a different page to get to the content that you wanted. In this respect, you are definitely in the minority, as evidenced by the feedback I noted above. - -sche (discuss) 19:18, 7 February 2014 (UTC)[reply]

What about a compromise? We could just transclude the definitions on the hub page while linking to the full subpages (is this totally crazy?) DTLHS (talk) 04:58, 7 February 2014 (UTC)[reply]

That would be pretty hard to implement. --Wiki Tiki 89 05:12, 7 February 2014 (UTC)[reply]

I think that having the current pages display the same content they already do, by transcluding the subpages or whichever method we find, is crucial to this proposal. I don’t know how we can implement it, but I expect many users will be too lazy to add the language and for them the structural change will be a nightmare unless the current pages remain the same. We can’t please them all, but it would be nice if we could avoid displeasing too many people. — Ungoliant ^(falai) 13:20, 7 February 2014 (UTC)[reply]

I don't see what's crucial about it. For me, the whole point of this proposal is to get away from bad past practices, and to innovate and restructure our content so that it's actually more well thought out. If we just linger on with our past habits and don't actually change anything, it's a huge wasted opportunity and wouldn't achieve the improvement that I think it was intended to. —CodeCa t 14:09, 7 February 2014 (UTC)[reply]

We will still be changing the structure, the improvement will still be there. — Ungoliant ^(falai) 14:28, 7 February 2014 (UTC)[reply]

No one likes immediate drastic changes to the interface. Even if we were to do that in future, we would have to introduce it as an option first and then get everyone to switch over to it. --Wiki Tiki 89 14:30, 7 February 2014 (UTC)[reply]

Well, it’s certainly a disadvantage to have the same main content in two places, looking identical or nearly identical. How will the reader orient themselves if language entries also appear in aggregated pages, which sometimes will only have the same language content? Not everyone looks at the URL. Could be extremely confusing, for old readers and new.

If we take this approach, there must be a clear visual and content difference between the language pages and the aggregating pages (since purely visual differences might not propagate to other wiki skins and sites that reuse our content). —Michael Z. 2014-02-07 18:08 z

If the pages are designed well, the user will be able to know the difference between the main page and a subpage. This is already done by the little "< parent page" link at the top of all subpages, but that might not be enough. --Wiki Tiki 89 18:44, 7 February 2014 (UTC)[reply]

Why not make the language sections collapsible on the main page? That would be a compromise. The content is all there, while at the same time you have the choice of seeing only what you need to, and it's cleanly listed so that you don't have to hunt through all of the content to find your language. —CodeCa t 22:09, 7 February 2014 (UTC)[reply]

Because that's still a lot of clicking if you don't know what language you're looking for. --Wiki Tiki 89 22:38, 7 February 2014 (UTC)[reply]

It would be zero clicking if there’s an expand/collapse all entries control and persistent state. —Michael Z. 2014-02-07 23:27 z

That's a good point. --Wiki Tiki 89 23:28, 7 February 2014 (UTC)[reply]

Ideally, the content would only be loaded when you expand it. That would keep the load times down. —CodeCa t 23:57, 7 February 2014 (UTC)[reply]

You can't have both dynamically loaded expanding content and the ability to have everything be expanded by default, without slowing down the loading even more. --Wiki Tiki 89 00:04, 8 February 2014 (UTC)[reply]

Why not? If it is expanded by default, it loads the subpages automatically while it loads the main page. —CodeCa t 00:31, 8 February 2014 (UTC)[reply]

I think we need a JavaScript expert's opinion on this. --Wiki Tiki 89 00:33, 8 February 2014 (UTC)[reply]

Maybe with lazy loading. The headings are in the HTML, and if they are expanded then their section content starts loading from the top of the page on down. Perhaps if everything is working correctly, the reader barely notices it happening.

(Relevant: I am not a JavaScript expert). —Michael Z. 2014-02-09 05:45 z

@CodeCat:re "For me, the whole point of this proposal is to get away from bad past practices, and to innovate and restructure our content so that it's actually more well thought out."
There is no independent value to getting away from past practices or to innovating. Merely asserting that past practices are bad and claiming that one's current thoughts are superior to the earlier thoughts of others is unsatisfactory. Oftentimes your arguments seem crucially dependent on imposing some kind of homogeneity in service of some unstated, but deeply felt ideal. I don't think that waving the flag of bleeding-edge innovation should and will successfully rally support after the modest benefits and substantial costs of earlier drastic changes. DCDuring TALK 14:09, 9 February 2014 (UTC)[reply]

What is so bleeding-edge about putting unrelated dictionary entries on separate web pages? —Michael Z. 2014-02-09 19:13 z

Bleeding-edginess is determined with respect to the capabilities of the implementers. Global changes that presuppose a high degree of uniformity and discipline among editors will cause lots of aggravation. If the benefits were more obvious and universal among all classes of users, the pain of our customary manner of implementation might be worth it. DCDuring TALK 20:01, 9 February 2014 (UTC)[reply]

Taxonomic names[edit]

Taxonomic names apparently can appear in Latin characters in running text of many languages. Should they be made part of all languages? Are there some languages for which such usage is rare and best ignored, eg, no science writing in the language? DCDuring TALK 01:30, 7 February 2014 (UTC)[reply]

They will be handled the same as the rest of translingual. Which may or may not include transcluding on every language's subpage. --Wiki Tiki 89 01:32, 7 February 2014 (UTC)[reply]

Wow, where did we get to transcluding onto subpages? I only ever thought about transcluding from subpages, onto the headword page as a kind of landing page for search results. Has the proposal expanded / changed substantially in other folks' understanding too? ‑‑ Eiríkr Útlendi │ Tala við mig 01:34, 7 February 2014 (UTC)[reply]

Since "Translingual" applies to all languages, it would only make sense to include it with every language. --Wiki Tiki 89 01:36, 7 February 2014 (UTC)[reply]

Empirically, I wonder whether there are not some languages that have yet to include any taxonomic name in running text. DCDuring TALK 02:24, 7 February 2014 (UTC)[reply]

Probably, but those languages are unlikely to have a word coinciding with the spelling of the taxonomic name. --Wiki Tiki 89 02:28, 7 February 2014 (UTC)[reply]

I was thinking of it from a usability usefulness perspective. For English I'd think we'd want to include them all. For a language that an English speaker was learning, I don't think there is great value and some detriment. Why should the list of proper names be overrun by taxonomic names?

Dictionaries like MW 3rd have lots of taxonomic names, thereby inflating their entry account. DCDuring TALK 03:11, 7 February 2014 (UTC)[reply]

How often does a taxonomic name actually coincide with an unrelated word in another language? --Wiki Tiki 89 03:22, 7 February 2014 (UTC)[reply]

Many are alone anyway, because of our lemmatization habits. For example, Crocus#Translingual is on a separate page from crocus#English. Since they haven’t been systematically or comprehensively grouped with other languages up to this point, there’s no point in adding that new requirement to this proposal. —Michael Z. 2014-02-07 05:17 z

The clutter effect is limited to things like PoS and some topical categories, eg, insects, and consecutive entries, if something like an alphabetical index of entries is created. I suppose if taxonomic names are never categorized with the items from the rest of the language, even that is not a problem. DCDuring TALK 05:34, 7 February 2014 (UTC)[reply]

Opposition[edit]

Oppose --Dan Polansky (talk) 07:07, 1 March 2014 (UTC) Let me conveniently register my opposition to the proposal to create separate pages per language. --Dan Polansky (talk) 07:07, 1 March 2014 (UTC)[reply]
Just because? Or is there a reason? —CodeCa t 13:36, 1 March 2014 (UTC)[reply]

Alternative - default tab[edit]

I found this page trying to work out if it's possible to do exactly what this page describes. The solution I came up with comes in two parts. The first step was to enable the "Tabbed Languages" gadget. The second step, I created a greasemonkey script that sets the anchor to the language I want, in my case "#French". This means that when I open a page it comes up with the french definition of the word if it's present. The script is pretty brute-force (below) and doesn't give any way to set the language. Having some user method to set this would give almost equivalent functionality. That said, I've got no idea how to propose changes to gadgets, so I'm putting the suggestion here.

(function() {
    'use strict';
    if (window.location.hash !== 'French') {
        window.location.hash = 'French';
    }
})();

Alwaysmpe (talk) 17:33, 19 January 2021 (UTC)[reply]

That doesn't address the problem here, which is about the structure of the wiki itself. —Μετάknowledge^{discuss/deeds} 18:12, 19 January 2021 (UTC)[reply]