Page discussion page.To add a new message, click on "Add Topic/Reply" button below, and set the "Subject".
To add a Reply, do the same as above, but leave the "Subject" blank.
What to do
{{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.
- 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.
.
/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.Also, this method will finally allow us to determine how complete translations into certain languages are, because when everything was on one page there were problems and it was possible to determine only the language that was currently selected. This will also save us from unnecessary work on the main page, since initially it was necessary to write all strings “id” in a separate parameter of the Page template, but now this will be done in the Strings template on the corresponding subpage (and the writing process can be simplified by my future idea with a special substitution of huge code structures using short writing, but these are not redirects or templates that refer to others).
The idea of adding existing translations as 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.
