MultiPage 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.
Contents
- 1 Uselang vs Subpage
- 2 Adding Esperanto as a language
- 3 Mess
- 4 Short pages with MultiPage are listed under Special:ShortPages
- 5 Translations appear along with English versions
- 6 Where are the page action strings located?
- 7 removal of base page from the English category
- 8 Multipage breaking Editor?
- 9 Incredibly bizarre bug
Uselang vs Subpage
uselang is just an interface language setting, not a link. There is also a {{uselang}} template on the site, which allows you to determine which interface language the user has. When opening a page that uses {{MultiPage}}, a user will see this page in the language of his interface, if this article is of course translated into it. If not, it will display a small message about this and show the English version of the article. The English language also has its own subpage, because if you put the text in the main article, you won’t be able to remove it to replace it with the translated article.
For example, this method will remove the need for suffixes in all links. The language subpages will be exclusively technical pages that will already be displayed on the target page, depending on the interface language specified in the user settings.
So far, this template is not fully completed, so some things may not be very convenient right now. At the moment, there is an idea to add instead of an edit button, a small drop-down list with all the necessary buttons to work with pages (edit, purge, etc.).
[[Page]]. In the case of subpages, you will have to add the language code for each language individually, for example [[Page/es]], [[Page/ja]], etc. It will also help to better sort these pages into categories, as language subpages won’t be counted, meaning there won’t be a need for hundreds of variations of the same category for different languages. Also, this method will simplify some things, for example, you don’t have to use the {{sdktools}} template on all language subpages, for example Hammer++ pages, you can simply place it on the final page at the end and it will be displayed in any interface language on this page.
/ for the subpage instead of the
?
{{#explode:}}), then switching to slashes would not be necessary.
Adding Esperanto as a language
Mi faros nur minimajn kaj planecajn ŝanĝojn en okazo de ebla reversiĝo do tiu ago ne estos tro atentantan.
Pri Esperanto / About Esperanto: https://lernu.net/esperanto.
Mess
Also this method of localization presents a big problem: data separation. One language page can add information, that will not be transferred to other localized pages automatically. Right now the other page (chineese or whatever zh stands for) hasn’t been updated and i doubt it ever will. Documentation needs to stay a documentation, that is, have one exact data set without the need for others to transfer data between pages. Otherwise, people will stick to the most complete version (which is English right now) and multipage functionality will become just a major annoyance (which it is right now).
So, is it really worth the complications to have a localization mechanism that violates the main requirement of the documentation – to be accurate? I fail to see the real usefulness of the change.
I have already explained most of the reasons why this way is better here. But the main ones are: almost complete elimination of work with suffixes in links/templates, titles of articles and categories (no more links like [[Page:es]] on the Spanish page, only [[Page]] everywhere and no more hundreds of thousands of categories and templates in different languages); the ability to use, for example, {{sdktools}} on all pages, specifying it only on the main one.
What about data separation is that it has always existed. If you have edited an English page, pages in other languages will not be edited by themselves. A huge number of pages in other languages have not been updated for a long time and this template has nothing to do with it. On the other hand, if this template helps to fix… I think I have an idea how to at least partially correct this situation. The idea is quite complex, so it may not be possible to implement it on this wiki, but it’s worth a try. I will try to do something about it soon.
Except this isn’t even true; many large projects have translations for technical documentation. Also, acting like English is the “international language” is straight up Anglocentrism (and to begin with the internet and tech industry is heavily Anglocentric). See: https://thepolyglotfiles.com/2018/10/29/should-english-be-the-official-language-of-the-world for more info.
The only reason for this is because most developer tools are only developed for English speakers, which is again a result of Anglocentrism. There are already programming languages with foreign languages.
We bother with localization so that other people can play. Now of course, the way localization was handled (from the start) on this wiki is IMO just horrible. The best solution (if one wanted to use English as a base) would have to been to do what Wikipedia does: Setup different subdomains for each language and to default to English.
The key word here is LARGE. And by LARGE i mean projects/organizations that have both money and resources to maintain the documentation in several languages. They do not outsource it to a wiki and say “here, translate it yourself”. And while i understand your political view on things, i disagree with English being a problem (even though English is not my native language).
But that is not the point. My point was mainly about the inconvenience this mechanism is providing without actually being useful. In my opinion machine translation with user corrections would be much better, than turning documentation into a Wikipedia clone.
If this feature is not going away, is there any way to at least get rid of the requirement to manually purge the main page? Because people do not visit localized pages – they are usually satisfied with what they already see on the root page (which is outdated, unless you purge it manually). Also a good idea would be locking the ability to edit the main page, so people cannot accidentally edit it. Otherwise – i can live with having to press 2 links instead of one.
We sacrifice the convenience of editors for the convenience of users. If it’s so lazy for you to press two additional buttons, then this is not our problem. As soon as it becomes possible to get rid of them without losing functionality, we will do it.
I didn’t know that when I make a map, I do coding 
.
When did it become so called and since when should I use English if I have a native language that I initially understand better? Also, there are many people who do not know English for various reasons and who want to read the correct translation. Translation software cannot satisfy the desire of such people to the fullest.
This is a problem for any wiki. Wikipedia also does not shine with articles perfectly translated into all languages. There are hundreds or even thousands of garbage pages on it. That is why there are templates that allow you to find such articles and correct them. Btw, doesn’t {{Lang}} have this problem? It creates a ton of useless links, categories, articles and much more that we have to delete, which is what {{MultiPage}} will help us with.
Like Valve? https://levvvel.com/valve-statistics.
{{Lang}} have this problem? It creates a ton of useless links, categories, articles…Ugh, no? What useless stuff does it create exactly? And how is {{MultiPage}} any different?
Like, for example of useless stuff: Why have an {{Emoji}} template, when Unicode Emojis already have existed for years in UTF-8? (This site already uses UTF-8 btw!) Not many Pages even use it.
I was talking about convenience of the user here! I am not lazy to click buttons – there are NO instructions for new editors like “Please, press this button to refresh the cache after you finished your editing”. And had to learn to do it the hard way, which is why i feel irritated. And, in my opinion, users suffer too because of that – somebody changes something and forgets to refresh the cache. In the end users lose more than editors.
Thank you, that was all i wanted to hear. Just that, without any personal attacks. I have no further questions – have a nice day, everyone.
Thanks to {{Lang}}, we have language categories, language links, suffixes in templates and many other things that we need to remove. I wasn’t speaking literally when I called {{Lang}} the creator of all these problems. This template is one of the parts of this deprecated page translation system, which gave rise to the Main Page:de, Category:Level Design:zh, |suf=de and much more.
It seems that I said a lot without thinking about it for a long time, while I was hurriedly going to leave. Basically, I said what I wanted, but not in the way I wanted it.
{{Emoji}} template, when Unicode Emojis already have existed for years in UTF-8?I don’t consider them useless and that’s why:
- The emoji design will be the same for all OS;
- They work on Windows XP, Windows 7 and other systems that generally do not support modern emojis, since they do not have the right font.
Oh, sorry about that. A lot of work has been done recently. At the moment there is not enough free time to write good documentation for newly created heavy templates 
.
{{Lang}}, we have language categories, language links, suffixes in templates and many other things that we need to remove. I wasn’t speaking literally when I called {{Lang}} the creator of all these problems. This template is one of the parts of this deprecated page translation system, which gave rise to the Main Page:de, Category:Level Design:zh, |suf=de and much more.
So why even mention {{Lang}} then? Also, there wasn’t much discussion on the translation method to begin with, leading the method to be unrefined.
- The emoji design will be the same for all OS;
- They work on Windows XP, Windows 7 and other systems that generally do not support modern emojis, since they do not have the right font.— THE OWL
The same can be said for UTF-8 Emojis. e.g 😀😃😄
.I understand. Is there anything i can do to help improve the situation? Maybe play with the template somewhere and document it somewhere?
We need a page in the Valve Developer Community namespace that briefly and clearly describes the entire process of managing the user’s page, as well as the process of communicating with other users.
Actually, there are quite a few problems with the documentation of various heavy templates, but I can’t say for sure yet what should be improved right now, and what can wait. Probably in the future I will somehow add editor requests to the main page for such cases, but for now this is not a priority.
Short pages with MultiPage are listed under Special:ShortPages
See 31. (hist) VPK [13 bytes] for example.
Lxm6 (talk) 19:51, 10 April 2023 (PDT)
Translations appear along with English versions
See Special:PrefixIndex/trigger for example.
Lxm6 (talk) 19:55, 10 April 2023 (PDT)
Where are the page action strings located?
{{int:<message>}} (short for interface). These are system messages which, in most cases, are translated into all possible languages (a list of all messages can be found at Special:AllMessages). In the case of “Purge this page”, this is {{int:confirm-purge-title}}. In fact, it really should be replaced with a manual translation, since in other languages this text is too long, for example in Polish.
removal of base page from the English category
Multipage breaking Editor?
So how to edit the language subpages? This can be easy to do by clicking the edit button on the right top (
). Then, you will be redirected to the editing UI interface of the corresponding language subpage. After saving your contributions, you can see a message box at the beginning of the page, and there's a blue button in it, which is written "Purge the base" (Purge the base). Click it and purge the main page, and then your work is done.
