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

Targetname

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)