Template talk:Language/archives/Page

This is the discussion page of Template:Language/archives/Page. To add a comment, use the Edit button near the headline of the appropriate section. To create a new section, you can use the Add topic button at the top of this page.
Comments on talk pages should be signed with "~~~~", which will be converted into your signature and a timestamp.

What to do

I have recently got WisdomBot working again, and one of the main goals of the bot is updating pages using {{Lang}} to {{MultiPage}}. However, now with this template being in the works I am unsure whether or not to continue updating pages to MultiPage, as this template would render all of that work useless.
I am not completely sure what why I am posting this message but I guess I’m kind of interested in what your plans for this are and what progress is currently at. --Wisdurm (talk) 17:24, 17 Apr 2024

Thanks for worrying about this. When I was creating the {{MultiPage}} template there were a lot of controversial issues:

• Due to the fact that the main page most often contained only a MultiPage, this made it a very short page and this had a bad effect on Special:ShortPages;
• Viewing the history of changes has become not very convenient, because you are looking at the history of changes to the main page, but it turns out you need to look at the history of the English subpage;
• There is some confusion with the editing buttons. I'm still not used to clicking the edit button in the right panel and constantly click on the standard button.
• Expensive functions: Each language uses an expensive function, which is why this template immediately takes 33 out of 100 expensive functions (at the time of writing this message) and increases page loading time. When adding a new language, another expensive function is added to all pages that use MultiPage;
• Indexing of pages other than English in Internet search engines is not very good, since the text itself is not written on the main page, but on subpages, so you get a link to a subpage, but this should not happen.

However, when we got access to editing the Main Page and began to actively improve it, THE OWL decided to do something similar as with templates: he made a strings subpage and put all the translations there, and just linked the lang subpages to the English subpage. When I saw this, I felt that there was a lot to work with, but after I told THE OWL the idea, he said, “Why complicate the editing process even more? Wiki is already battered by such a number of changes in translation methods… First we completely switched to Lang, now we are switching to MultiPage, and at the same time, another idea looms on the horizon” and I replied to him, “Forget it, I don’t like this idea anymore” (we talked about it almost a year ago) and actually I still liked this idea, but it went in the box of ideas for a long time. And quite recently, I decided to try to implement it.

The whole idea is that everything will be on the same page: the main content of the page is the construction of the page itself, and the second content is all possible translations. This turned the page into the real multi-page, saving us from all the problems I listed earlier and saving us from the need for many subpages. But there is a new problem: if you write everything on one page, it will be very inconvenient, since editing the page becomes a real pain. Therefore, I decided to try to make invisible headers and make two separate buttons: one for editing the page design, the other for editing translations. I assumed that editing by individual sections would work, but alas, this idea was not successful and therefore I deleted both buttons.

At the moment, while I was writing the entire previous part of this message, I checked how much worse it would be if I moved all the translations to the strings subpage… and it turned out that this option is better: it separates the translations from the main page making editing normal again, as well as this option.. is almost equal in processing, as if everything was on one page (and it’s even just a little bit better). It will also solve the problem with templates, making the Page template suitable for use in templates. Although for them it is better to make a separate template similar to Page, but with a documentation style and taking translations not from the strings subpage, but from the documentation subpage, in order to separate the documentation strings and template strings from each other, otherwise each use of the template will load its documentation, which will load pages using this template even more.

Right now I’m working on an improved version of the Main Page (including some visual improvements and optimizations) and am going to apply this template to it. Obviously, I won’t do this until this template is more or less complete. For example, I also want to add icons in the form of TopIcons, because this template uses <indicator>, which is why we will have to remove the direct use of the tag.

While I was making the {{Page}} template, I also made these templates, which will also be used in the new page system:

• {{Intlang}}: a more optimized replacement for the {{Uselang}} template.
• {{String}}: a more advanced version of the {{Autolang}} template (and with a normal name). It also contains a new ability to link one translation to another, as if it were {{#switch:}} (only the style of writing is different).
• {{Str}}: simplification in order not to write continuously {{:{{FULLPAGENAME}}|<textId>}}.
• {{Strc}}: A simple template for a small system inside the {{Page}} for (almost) automatic counting of the number of strings and how many of them are translated.
• {{Strings}}: a special template to replace the terrible {{#switch:}} structure that is used on all strings subpages. --Max34 (talk) 9:25, 18 Apr 2024

Damn, if VDC had the ability to detect your nickname when entering a page, it would be possible to implement so many things using custom settings from the user’s Settings subpage. It would even be possible to add your own useful buttons to the {{Page}} template and thereby make working with articles much better. But these are all just dreams, in reality it is impossible to do . --Max34 (talk) 9:52, 18 Apr 2024

I like the idea of keeping the English page on the base page, but I think it will become quite messy if every single other page is compressed into one. I'd be interested in keeping the subpages separate. To combat the expensive functions, I propose that the template on the base page should have parameters that are specified when a certain subpage exists. All together, it would look something like this:

{{Page |eo=1|es=1|ru=1 |contents = English text here }}

As for search engines indexing these pages, I think we could help web crawlers by switching the URL that {{flag}} uses from /w/index.php?title=Main_Page&uselang=es to /wiki/Main_Page?uselang=es. Currently, web crawlers are not indexing these links because robots.txt does not allow them to. However, replacing it with the latter allows them to index these pages. --Pee (talk) 22:27, 19 Apr 2024

es=1}} instead of using an expensive function is good, but in this template this will not happen at all; in the drop-down list next to each language the number of translated strings will be indicated, thanks to which you can understand where the translation is and where it is not. If some string is not translated into the language, its English version will be displayed.

The point of the new page system is to separate the text from the page design. Main advantages:

• Relevance: allows you to supplement the article with new text (in English), which will be displayed when you turn on any language. Any user who visits such a page will see both the text that was there before (and which has already been translated) and completely new text. This is also a plus for translators, because they will see that something new has been added to the page and it can be translated.
• Shared style: if you want to change the style on an English article, you will have to do this in all other languages. The same SDK Docs as an example (this is a very tedious task). In this case, this will not happen, since the page structure is separate from the text and therefore does not need to be repeated in each language.

There will also be an implementation of this entire system for templates, but not in this template and for now I do not plan to do this until this template is sufficiently developed. --Max34 (talk) 11:17, 21 Apr 2024

Translation Template Troubles

I figure based on the recent edits you might have already seen some of my thoughts on this template. The idea of a web extension is quite smart since the main problem with this template currently is how slow and difficult it is to use, which would more or less be eliminated with a custom editor. I personally still feel in favor of using {{Lang}}, {{Multipage}} or making a new template more in line with those ones, but I'll still see where you go with this since the whole custom editor could theoretically fix all of this template's problems if it's done right.

My main criticism with this template essentially is just that all other wikis, from the TF2 one to Wikipedia itself, have obviously found great success in treating different translations of pages as completely different articles. While the idea of keeping all languages as a single page is novel, I do think that it is fundamentally unsustainable on a wiki as small as this. The idea that all translations have to be constantly updated since someone added a small note to the English page just doesn't seem like something that any editors would have the motivation for.

I feel some parts of the page I wrote may have come across as a little spiteful, so I want to say that I do really appreciate the idea behind this. While I'm still in favor of separate pages for different languages in large essay like pages, this template, even in it's current state, is definitely advantageous on pages like the main page for example. --Wisdurm (talk) 15:15, 27 May 2024

Making translations

I'm not sure if i should keep creating Croatian translations / pages. I stopped translating since i saw this new template.

On your message (large one) you said:

The whole idea is that everything will be on the same page: the main content of the page is the construction of the page itself, and the second content is all possible translations. This turned the page into the real multi-page, saving us from all the problems I listed earlier and saving us from the need for many subpages.

that makes me question if i should keep creating Croatian pages. --N0one (talk) 19:07, 2 Jun 2024

Nobody forbids you to create new pages. This template is still not fully developed and has many shortcomings, so for now, it should not be taken as a full-fledged replacement for the MultiPage template. The whole problem is that if this template really becomes a full-fledged replacement for MultiPage, then all translations will be transferred to one subpage, and the history of changes in this language will simply be lost.

The message I left on the MultiPage template page was made more to ensure that users do not have to move the main page to a subpage, but do it manually by cutting the text and pasting it into the subpage. This way we can preserve the original history of page changes, although this will only work with the English version.

I'm still working on the VDCEditor extension and plan to release it soon. The first version will just have an improved editor, and in the next version I will start trying to implement a simpler way of editing using this new template, but it will take some time. --Max34 (talk) 7:46, 4 Jun 2024

Bug

Today I added a categorytree to my user page. It's one of these things

IO System

AddOutput

Entity parameters inputs outputs

Inputs and Outputs

Logic auto

Logic branch

Logic case

Logic case (Source 2)

Logic compare

Logic multicompare

Logic playerproxy

Logic relay

Logic timer

Making lights turn on and off with a "trigger multiple"

Opening doors with func button

Porting GoldSrc content (maps, models, etc.) to Source

Porting Source content to GoldSrc

Script trigger multiple

Script trigger once

Script trigger push

Setting up an Output

Trigger look

Trigger multiple

Trigger once

Trigger proximity

Troubleshooting Outputs

User Inputs and Outputs

I also, bizarrely, found out that this template for whatever reason blocks the buttons on the categorytree. Looking through the html of the page I found that {{page}} for whatever reason removes the CategoryTreeToggleHandlerAttached class from the expand button, though even adding it back manually doesn't fix it so there's other stuff broken elsewhere I guess. Not really sure what's going on. --Wisdurm (talk) 14:53, 6 Jun 2024

I didnt realize there was the <categorytree> extension, i read it on Special:Version (about yesterday or 2 days ago). --N0one (talk) 17:57, 6 Jun 2024

The whole situation with translation templates

During the existence of the site there were many templates for translating pages and they all differed to one degree or another.

One of the first templates was {{Otherlang2}} (were there other templates before it? Maybe, but this can only be found out through a wayback machine). It was extremely simple and worked according to the usual scheme: each language has its own separate page. The name of such pages was the same as the original, but with the addition of a colon and language code. The disadvantage of this template was that it was necessary to manually enter the full name of each translation page:

Example

{{Otherlang2 |noborder=true |cs=Main_Page:cs |es=Main_Page:es |de=Main_Page:de |fr=Main_Page:fr |ka=Main_Page:ka |nl=Main_Page:nl |ru=Main_Page:ru |sv=Main_Page:sv |zh-cn=Main Page:zh-cn }}

After this, a new template appeared – {{Lang}}. Its goal was to make the detection of translated pages automatic and eliminate the need to write page titles for each language. The structure of the translated pages did not change, they also used a colon in their titles. However, because of this, the name of the page itself still had to be written, because on this site there is no way to separate the text by a specific character (this can only be done with the / character through the #titleparts: function).

This template was made and worked quite well, however it had its downsides:

• For each language it used the expensive #ifexist: function to check the page for its existence. There is a limit of 100 of these expensive functions, and this template used 22 expensive functions (at the beginning of its existence, then there were even more of them). The problem was also that if there was no translated page, it was placed in Special:WantedPages, thereby clogging up this special page.
• It was unclear how exactly to work with subpages: do page/sub1/sub2:ru or page:ru/sub1:ru/sub2:ru.
• All links on translated pages should have led not to somepage, but to somepage:ru, somepage:es, etc.
• The same story with categories: each category had a translated version into which the translated pages were supposed to be placed. But very often the translated pages were placed in the main category rather than the translated one, thereby creating a mess.
• And the same thing with templates: each template had its own translated version, so on the English page you could find the {{Note}} template, and on the Spanish page – {{Note:es}}.

Over time, of course, these shortcomings were corrected as much as possible, but this template was clearly far from the “good solution”.

Then {{MultiPage}} came along, which was supposed to make everything even more automatic, which it did, but it introduced a huge amount of inconvenience for editors. The page structure was changed with the expectation that it would be better, but this did not happen.

Shortly before the election of new moderators, work began on the {{Page}} template, which was supposed to simplify everything to two pages: a design page and a subpage of all strings. Oddly enough, this idea turned out to be even more inconvenient for editing, almost without fully correcting all the previous problems. However, after people finally began to speak out en masse about the whole situation with the site, the {{Page}} template was redesigned.

As a result, the template itself is essentially just buttons at the beginning of the page and an automatic inserter of translation progress categories.

The whole idea of ​​the new translation scheme is to get rid of any subpages and use {{Page}} for the header buttons and {{String}} for direct translations of strings.

You see, this whole system in which translations have their own separate pages brings various problems. Pages with translations are not considered a separate type of page; they are the same full-fledged pages as regular pages. This leads to many problems:

• Editing
  • If you want to replace some template on one page, you will have to edit all the language subpages of that page.
  • Pages do not synchronize their content in any way. If we have a page that contains a table with special codes (which do not require translations), then updating it on the main page will not change it on the language subpages, which will lead to the irrelevance of information in other languages.
  • In the case of {{MultiPage}}, you need to clear the main page cache after any edits, which is very annoying.
• Searching
  • If you use the search engine on the site and enter, let’s say, “Main Page” then you will see the main page in the drop-down list of results and everything else will be its language subpages. This makes using Quick Search very difficult.
  • When searching for a page in external search engines, they very often show language subpages in their results, which should not be the case.
• Random page
  • Since translation subpages are regular pages, they may be encountered when using Special:Random. The random page button located in the left panel of the site, however, uses Special:RandomRootpage, which fixes the situation a little. However, I tried to click on it and was immediately redirected to the "Path corner:ko" page.
• Categorization
  • A situation may arise when some template on a page places it in some category. Using this template on language subpages will result in them being added, which should not happen.
• Technical part
  • Because of the language subpages, we do not see the actual number of pages on the site.
  • Many special pages with lists of pages will be overwhelmed with these language subpages and it will be difficult to work with such a lists.
  • Each page occupies its own separate place, is indexed, processed, and much more, separately from other pages. And the more language subpages there are, the more crowded the site will be. I’m talking more about the fact that the site (as a data storage) will be filled with unnecessary data, which makes the site heavier in weight and processing.

Despite the simplicity of the new {{Page}}-{{String}} format, there are only one big problem that should be dealt with before attempting to use this template:

• Due to the fact that everything will be on one page, this will lead to the fact that such pages will be difficult to work with and navigate due to the large amount of code.

This problem can be solved if we all come up with a competent way of writing pages to increase the readability of the code.

If you are not indifferent to the situation with all this chaos of translations, help solve this problem. --Max34 (talk) 11:08, 21 June 2024 (PDT)

What disadvantages did {{Otherlang2}} have other than typing in page names (is that even a disadvantage? sounds very minor)? Was it also expensive and forbid special characters? Cvoxalury (talk) 11:45, 21 June 2024 (PDT)

This template used the old system of subpages which used the : symbol. This made it hard to work and develop this template properly, since you could not separate the page title from the language code. In addition, the page display did not depend on the interface language when using this template.

As I already wrote in my comment, this whole system with separate pages for translations does not interact very well with the site. That’s the point. --Max34 (talk) 12:05, 21 June 2024 (PDT)

Why work on this, exactly?

Title says it. We're going to eventually switch back to using Lang and have separate translation pages. Why are you spending time refining this when its concept is hopelessly flawed?

Putting all the text (eng + translations) into the page body is a horribly bad idea. I don't understand how you can't see it, how you for a minute thought "wait, this can actually work".

• Bloats every page.
• If someone is actively translating a page, it blocks other people from editing (conflict of editing, you won't be able to save an edit).
• Looking into page code becomes absolutely painful.
• If someone makes a single mistake in their translation it can affect everyone else.
• Using strings is proving to be a bad mechanism each day, fitting only for small repetetive elements.

You just won't be allowed to put it into motion. Why not direct these efforts into improving pages that need it? This is a pipe dream with no prospects. Cvoxalury (talk) 09:54, 26 June 2024 (PDT)

Although I say that I plan to replace {{MultiPage}} and {{Lang}} with {{Page}}, this does not mean that I will begin a full-scale replacement without any preparation. I’m still working and trying to find the optimal solution that will help fix most of the problems.

By the way, this template has nothing related to the content of the page, it is literally three buttons and an area for icons. If we talk fully, then we are talking about a new page format.

Let's look at your arguments:

Bloats every page

Yes it is. This is one of those problems that can be solved either by competent design, or by another option that is still at the testing stage (it is not on the site yet, it is too raw).

… (conflict of editing, you won't be able to save an edit).

This is a case in which we are powerless. But to be honest, I don’t think that this will be some kind of catastrophic problem. There are not many active editors on the site for this to happen all the time (especially editors who do translations).

Looking into page code becomes absolutely painful.

The answer to this is the same as to the first argument.

If someone makes a single mistake in their translation it can affect everyone else.

Yes, but mistakes can be made by anyone, anywhere, anytime. This problem has always been and will always be, because there are always those who will edit a site blindly without reading the documentation. And don’t forget about the human factor. If we are talking about an error in the content of the text itself, then this is also not such a serious problem. As I wrote earlier, there are not many people on this site who are actively translating the site. Moreover, this problem will exist in any case, even if all languages ​​have their own pages.

If we are to describe the {{String}} template specifically, then:

• If suddenly a user uses the = symbol, nothing will break, since all translations, even English, have the language code and = symbol written at the beginning;
• If the user uses the | in the text, then it will be clearly noticeable on the page that the text simply cuts off;
• If the user uses closing curly braces in the text, then everything that comes after them (within this template) will be displayed as text and this will also be quite noticeable on the page.

Using strings is proving to be a bad mechanism each day, fitting only for small repetetive elements

Sorry, but I don’t fully understand what you mean here.

Anyway, there is no way I will implement or even promote this whole new format until it is perfected. That's why I'm working on this.

Of course, if in the end this whole idea fails, then I will not continue it. It’s all about learning. I have been on this site for more than 3 years and have not stopped studying this terrifying MediaWiki engine. --Max34 (talk) 00:48, 27 June 2024 (PDT)

I don't follow this too much but if I understand correctly and you want all the translated text within a single page then that's horrible and it definitely shouldn't be done that way Nescius (talk) 01:41, 27 June 2024 (PDT)

"Sorry, but I don’t fully understand what you mean here." - I mean that using the String to describe a snippet of text that's used on many, many pages (such as describing (and internally translating on the spot) a template like Stub), that's okay, because it's a little bit of text and it's universal.

But to use String to describe an individual page's elements quickly turns editing into such a mess, not only it becomes a text that's something somewhere, you need to hunt it down, find it with your eyes among sea of translated versions, edit it on *that* spot (without preview for non-eng, it seems?), then go back to your page, and update it to see the result. How tedios! Why did anyone want it in the first place? Why is Main Page full of strings?

If this is the future that Page prepares for us... just no. If it's going to be strings in the body of the page, that's bloat. If it's going to be strings hosted elsewhere (like for main page), that's tedium.

"Yes, but mistakes can be made by anyone, anywhere, anytime." - and this design makes it exponentially worse. This doesn't answer it. "Mistakes can be made by anyone" isn't an answer to "your system is inherently flawed because it's much less error-proof".

"If the user uses closing curly braces in the text, then everything that comes after them (within this template) will be displayed as text and this will also be quite noticeable on the page." - you're not trying to make it sound okay, right? What this means, is someone can utterly wreck a page with a single mistake, for everyone to see, to fish it out would consume plenty of time just to scroll through all the text before it and proceed to find the exact spot of the mistake (which can be in another language filled with non-latin characters), it can stay unnoticed on a low-usage page for indeterminate time, and if it's a popular page, several people at once can try and fix it, only to interfere with each other. It's simply a broken idea. (also the mistake can turn out to be inside some tempalte. How friggin fun are those!)

"there are not many people on this site who are actively translating the site" - any time you edit a page and someone edited it during that, even previewing makes you lose your edit form, and you have to fish out your changes from a 'changes' view. That's again tedious and putting all text, with translations, into one page, increases the chances of it. Why increase the chances? It's like saying "in my quiet town, car collisions don't happen that often. So it's fine to make every street half as narrow, there's not that many collisions".

Besides, it works both ways. If someone's been translating the page (with the added tedium of the proposed design), and someone else edited the page for whatever other reason, that first person can lose their edits and have to fish them out of the changes view. (that's applicable to those translating right in the wiki and not a separate document. But these people exist. I'm one of them myself)

"Yes it is. This is one of those problems that can be solved either by competent design" - what does that mean? What "competent design"? Take any big page like Prop_static. Can you even imagine making that page 10 times bigger (for 10 languages)?

"another option that is still at the testing stage" - ah yes, more experiments, lovely.

"Of course, if in the end this whole idea fails, then I will not continue it. It’s all about learning." - this wiki is not for your personal training and experiments.

So my five points (1. bloat 2. edit collisions 3. code spaghetti 4. fragility 5. tedium of using strings) all seem to stand.

To be blunt, I don't really see you guys (you and Owl) making a lot of edits to the content. You don't seem to be engaged in working with articles so maybe you're not that aware just how tedious your experiments have made the wiki. And in before "it's too raw, we'll make it better" - it doesn't really fly - something like Software page had been worked on for over a year constantly, and still didn't become good, it made it hard for everyone and now it's been thrown out. Cvoxalury (talk) 02:54, 27 June 2024 (PDT)

Okay, I understand you. All these “experiments” are just an attempt to make the site better. When I said about learning, I meant that everything that was done and every comment that was written for and against this or that idea acts as material for which option can lead to what. Take the same sites with questions about programming. People have been asking questions for years to solve their problems, and now it’s like a knowledge base for everyone.

The same principle works here: all the templates, pages and formats, no matter how unsuccessful and bad they were, led to knowledge that anyone can use. For example, if suddenly the same editors appear on the site who want to reformat everything, they can be poked into those templates, messages and “ideas” that were not successful, so that all this chaos does not repeat itself forever.

I already realized that everyone doesn’t like this idea of ​​putting everything on just one page. I won’t try to continue the idea of ​​this format.

However, thanks to all these (and other) comments, I came to some conclusions that can be used for another idea. Yes, another idea. You may not like that me (and Owl) are constantly doing some experiments that are unsuccessful, but this is the price of evolution, which is inevitable.

Based on everything that has happened in recent weeks, it has become very noticeable that people want to return to the {{Lang}} template, which I generally agree with them, however, user Nescius has pointed out many times the problems of language subpages by suggesting the idea of ​​​​languages ​​as prefixes rather than suffixes. To translate this into more understandable language, it is essentially an attempt to implement language domains. This wouldn’t be a good idea if we didn’t have the ability to create redirects.

As I said, the {{Page}} template is just three buttons, so I’m using it as something that will be very similar to {{Lang}}, but with a language domains implementation (if it needs it at all). --Max34 (talk) 04:24, 27 June 2024 (PDT)

"This wouldn’t be a good idea if we didn’t have the ability to create redirects" Don't quite understand what do you mean by this sentence. How does ability to create redirects affect whether language pages should use prefix vs suffix? Pee also suggested in this discussion Template_talk:MultiPage#anything_that_can_be_done_with_this_.3F something about having translated pages under a Template: instead which sounds good to me too. And to be clear my issue with language pages being a simple suffix is this. The search suggestion become useless after you have lot of translations. Nescius (talk) 04:54, 27 June 2024 (PDT)

"However, thanks to all these (and other) comments, I came to some conclusions that can be used for another idea. Yes, another idea. You may not like that me (and Owl) are constantly doing some experiments that are unsuccessful, but this is the price of evolution, which is inevitable." - this is irrelevant to this wiki. A couple aspiring editors who want to turn everything upside down just because they see something in a particular way, shouldn't, and hopefully won't be allowed to turn everything upside down (for the Nth time). Fantasising about evolution and doing all this high speech, is irrelevant. Either work on improving the contents of the wiki, or stay away. Simple as that.

There is no need for a better, cooler template. There is only a need to 1) fix editing of pages 2) not need purging to see edits 3) move /en pages to base while preserving their history 4) do all that in minimum amount of extra work. Making a new template that'll need to be put on every page, is extra work that isn't needed.

And this is beside the point that translations are... kind of irrelevant at this point. If they're going to be as automatically and badly translated as the russian versions of the pages already are, then built-in browser translations can already take care of that. Translating pages is secondary to making them good in the first place.

"they can be poked into those templates, messages and “ideas” that were not successful, so that all this chaos does not repeat itself forever" - obviously this isn't working, as you're not listening when I point out why your experiments are irrelevant and misleading. Cvoxalury (talk) 01:20, 3 July 2024 (PDT)

uselang should be abandoned

seems to be very expensive Template_talk:Uselang Nescius (talk) 06:55, 3 July 2024 (PDT)

tested some stuff Template:Ru/Test/sandbox here and {{ROOTPAGENAME}} could be a way to avoid uselang if I understand corrently. It would require all translated pages to be under a language page like ru for example and then {{ROOTPAGENAME}} will return ru on all subpages of ru. Is this usable ? Assuming content of of Template:Uselang was changed to simply {{ROOTPAGENAME}} how much would need to be changed other than moving translated pages under respective <lang-shortcut>/ pages ? Nescius (talk) 08:23, 3 July 2024 (PDT)

Actually, I made a new template called {{Intlang}} which is a much lighter version of {{Uselang}}, but yes, if the site really switches to the format of prefix languages ​​​​for each page, then it will be possible to use {{ROOTPAGENAME}} which will be much better. There are some issues with the format of language prefixes (or language domains as I call them) that should be carefully considered first before rushing to change the entire site to this format. For example, this format will affect the categories and search engine on the site.

I also want to answer your question in the previous thread: redirects are very important, since the format of languages ​​as prefixes will break a quick search, because it looks for what begins with what you wrote. Due to the language prefix, it simply will not produce this list. You will need to first enter en/ and only then the page name. A random person visiting the site is unlikely to understand that they will need to first write en/. And this is where redirects come into play. For example, we have pages en/Page and ru/Page, and we also have redirects Page (redirect to en/Page) and Страница (redirect to ru/Page). This option will not only correct the situation with the need to write a prefix language, but will also allow users to use their native languages ​​to search for pages. --Max34 (talk) 13:01, 3 July 2024 (PDT)

en/ obviously wouldn't be needed as english would be default and there is no need for en/ domain so search would work fine Nescius (talk) 13:18, 3 July 2024 (PDT)

What I think should be done

Moving all pages ending with language suffix i.e. <page_name>[:/]<lang_suffix> to <lang_suffix>/<page_name> and also change all links on the given pages (other than en) to be [[<lang_suffx>/<page_name>]]. That way Template:Uselang which is currently extremely slow can be rewritten to simply {{ROOTPAGENAME}} because the root page would become the <lang_suffix> for all non english pages and templates like KV,IO etc. can keep working properly and remain universal. It would fix this clutter File:Language_suffix_clutter.png and make loading faster by optimizing uselang which I think needs to be done one way or another. Can also start undoing multipage after that but that's another topic Nescius (talk) 06:44, 6 July 2024 (PDT)

Any concerns about this ? I am able to start moving the pages in few days Nescius (talk) 03:52, 7 July 2024 (PDT)

Would using <lang_prefix>/<page_name> interact with the 'back' function (when /subpages of pages have a < Page link under their title) in any kind of unusual way? Because then all pages in a language technically be subpages of that language? So would it make every page under a prefix have a back link to the prefix's root page (if that'll even exist)? And would using : instead of / make a difference in this? Cvoxalury (talk) 06:50, 7 July 2024 (PDT)

Don't think it would interact in any unusual way. But you would simply see that back link to language shortcut root page at the start on all translated pages (if it's created). Half-Life: Alyx Workshop Tools/Modding/Source2mod/Chapter creation example how it looks with multiple subpages. Reason to use / instead of : is to have easy way to determine language in this case just using the {{ROOTPAGENAME}} while under <lang_shortcut>/<page_name> will give us the language shortcut. And {{SUBPAGENAME}} would give us page name. Some tests regarding these magic words here and here - Nescius (talk) 07:14, 7 July 2024 (PDT)