Template talk:Language/archives/MultiPage
![Icon-message-48px.png](/w/images/thumb/9/9a/Icon-message-48px.png/32px-Icon-message-48px.png)
Template:Language/archives/MultiPage
.
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.
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
- 10 anything that can be done with this ?
- 11 =PROTECTIONEXPIRY
Uselang vs Subpage
I don’t understand why this template is designed to link to some strange “uselang” page rather than a language subpage as documented. Also, if it was done as documented, why is English a subpage of an English title main page? Just curious. Great work on the template, and general site maintenance, by the way, we’ve needed it. --Pee (talk) 0:00, 16 Feb 2023
1|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.). --Max34 (talk) 1:58, 16 Feb 2023
Looking into it, it’s pretty difficult and counterintuitive to temporarily modify the entire page, and it makes it difficult to edit. I think you’d be better off simply linking to language subpages as the wiki currently does (including English, though), but still automatically translate the main page. --Pee (talk) 21:30, 22 Feb 2023
1|}}), and to edit the language subpage without going to it, there is a pencil button for this, it immediately switches to editing the language subpage that is currently displayed relative to the interface language. So far, this whole idea may not seem the most convenient, but that’s because it’s not yet complete. The idea of using language subpages as the main ones is not considered, since this is exactly what we are trying to get away from. It is planned to add a separate kind of flags directly on the language subpages so that you can switch between them without using the main page. --Max34 (talk) 21:48, 22 Feb 2023
Why avoid subpages? it seems that nothing gets accomplished by avoiding them, other than requiring a second UI menu, and changing the UI language for the duration that someone’s on a page. --Pee (talk) 22:09, 22 Feb 2023
2|[[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. --Max34 (talk) 22:30, 22 Feb 2023
I agree with your reasoning, but why use an /
for the subpage instead of the
1|{{#explode:}}}}), then switching to slashes would not be necessary. --Max34 (talk) 18:24, 1 Apr 2023
Adding Esperanto as a language
I will only make bare minimum and schematic changes, so if they need to be reversed, it won’t take long.
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. --Amicdict (talk) 21:42, 31 Mar 2023
Mess
I also want to discuss this thing. Right now editing this wiki page is much more work – you need to click on more interactive elements just to get to the editing. And when you finish editing, results do not appear on a main page – you have to click “Purge” in order to update things. This is really inconvenient and why – just to have a localized help? It is a well established norm to have a technical documentation in English only (since English is the international language), so why bother with localization? This is not a Wikipedia – this is a technical documentation! To code things you need to know English anyway.
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. --Xandros (talk) 16:31, 3 Apr 2023
2|[[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. --Max34 (talk) 21:54, 3 Apr 2023
Xandros }} 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. --Amicdict (talk) 22:32, 3 Apr 2023
Amicdict }} 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. --Xandros (talk) 02:21, 4 Apr 2023
Xandros }} 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. --THE OWL (talk) 11:42, 4 Apr 2023
Xandros }} 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. --Amicdict (talk) 16:33, 4 Apr 2023
THE OWL }} 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. --Xandros (talk) 17:32, 4 Apr 2023
Amicdict}}
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 . --THE OWL (talk) 18:28, 4 Apr 2023
de</nowiki>}} 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 😀😃😄 --Amicdict (talk) 22:15, 4 Apr 2023
THE OWL}} I understand. Is there anything i can do to help improve the situation? Maybe play with the template somewhere and document it somewhere? --Xandros (talk) 18:17, 6 Apr 2023
It’s hard to say, Xandros. I’ll mention one of the problems below, but otherwise, I can only say that here you are free to do what you want. Some of us may have taken the path of cleaning up this wiki, but no one is going to restrict other editors yet.
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. --THE OWL (talk) 18:30, 7 Apr 2023
There is a instruction page about translating in Valve Developer Community namespace, which is Valve Developer Community:Alternative Languages. This page should be improved to indicate others how to do translations with the new translation templates. --1416006136 (talk) 0:23, 8 Apr 2023
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?
I want to change the intimidating “Purge this page” (which sounds like you’re deleting the page’s contents) with the much less threatening and more accurate “Purge Cache”. --SirYodaJedi (talk) 15:01, 31 May 2023
pl}} for example in Polish]. --Max34 (talk) 16:47, 31 May 2023
removal of base page from the English category
It doesn't make sense for Category:English to always be on the base page. The English subpage is already in that category, and it doesn't let us identify uncategorized pages via Special:UncategorizedPages. I think it makes sense to only place the base page in the english category when {{{no-english-subpage}}} is 1. --Pee (talk) 0:11, 13 Sep 2023
Multipage breaking Editor?
On the page for func_physbox, if I try to edit it, the Edit text window shows up as just "\{\{Multipage\}\}
\[\[Category:Physics\]\]" and none of the actual content. Trying to add any text above the MultiPage puts it at the top of the page, anything after it putting text at the bottom, but there's seemingly no way to edit the content of the page itself. The only reason I can think for this is that MultiPage inlines the page content from somewhere else, but it's not really doing a good job of explaining how I could contribute to it. --Phoenixwhitefire2000 (talk) 5:35, 17 Nov 2023
The editor isn't broken, because the {{MultiPage}}
will load the corresponding language subpages based on the UI language. Actually, the content of the page is from the language subpages. So you need to edit the language subpage instead of editing the main page. Then, you should purge the main page and your contributions will take effect.
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 base's cache). Click it and purge the main page, and then your work is done. --1416006136 (talk) 8:36, 18 Nov 2023
Incredibly bizarre bug
At the beginning of the article for Item_healthcharger and Item_suitcharger (and probably other pages as well), it just has the name of the page as text at the beginning? From some testing it seems multipage adds this. I'm not sure what causes it, as there's no extra parameters or anything. Maybe some recent updates caused this? --Wisdurm (talk) 13:52, 7 Jan 2024
Reason of this {{langsp|item healthcharger}}, it's should be title. {{langsp|title=item healthcharger}} or on main page {{multipage|title=item_healthcharger}} if name of page is same for different languages. Or just delete it. --NOUG4AT (talk) 13:55, 7 Jan 2024
anything that can be done with this ?
So when typing something in the search bar it gives quick links under it and it becomes lot less useful when like 6 of those are just language variations that have /ru or :fr etc. at the end. For example when I start typing L4D2 in the search bar there are 10 quick links but from which 6 are just same articles with /en /zh /ru :ru suffix and it's quite annoying. I think all translated pages should be under respective language page so it would be for example ru/info_target instead of info_target/ru. Nescius (talk) 10:53, 18 June 2024 (PDT)
- It might be better to put them in a different namespace (i.e. template:page translations/sv_cheats/ru) instead for 2 reasons:
- They still won't show up in results when searched for on VDC
- The __NOINDEX__ magic word will work on them (it doesn't work on articles), so they won't show up in search engine results. Instead, web crawlers will index the base page with different uselang parameters (so searching for sv_cheats with results set to Russian should link you to sv_cheats?uselang=ru, and you will not get Template:page translations/sv_cheats/ru in your results). ―Pee (talk) 11:07, 18 June 2024 (PDT)
=PROTECTIONEXPIRY
What's this for #if:{{PROTECTIONEXPIRY:edit ? It seems to always return some sort of true value (either infinity or some date). I should be able to remove it safely without it affecting anything right ? I see only when testing non existent page with it then it returns false value. So why is not ifexist used ? Nescius (talk) 01:37, 10 July 2024 (PDT)
- The ifexist function was used before and was replaced by this because if a page didn’t exist, then the ifexist function would put it in Special:WantedPages, making that page a complete nightmare as it would add all the missing translated articles to it. --Max34 (talk) 02:43, 10 July 2024 (PDT)
- But all the flags to show are checked using ifexist here Template:MultiPage/flag so wouldn't PROTECTIONEXPIRY method need to be used there too in that case ? Looking at that page it has more than like 50000 entries anyway. Probably useless to be bothered by that. Nescius (talk) 02:56, 10 July 2024 (PDT)