View source for Template talk:Language/archives/MultiPage

{{Discussion page}}

==uselang vs subpage==
{{Message
| user = Pee
| time = 0:00, 16 Feb 2023
| 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.
}}

{{Message
| user = Max34
| time = 1:58, 16 Feb 2023
| {{code|style=1|uselang}} is just an interface language setting, not a link. There is also a {{code|style=2|&#123;&#123;[[Template:uselang|uselang]]&#125;&#125;}} template on the site, which allows you to determine which interface language the user has. When opening a page that uses {{code|style=2|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.<br>
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.<br>
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.).
}}

{{Message
| user = Pee
| time = 21:30, 22 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.
}}

{{Message
| user = Max34
| time = 21:48, 22 Feb 2023
| You can access any language subpage using the drop-down list (+), 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.
}}

{{Message
| user = Pee
| time = 22:09, 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.
}}

{{Message
| user = Max34
| time = 22:30, 22 Feb 2023
| Avoiding language subpages as the main ones will eliminate any need to add language code to links on pages. Since there is a one main page, you can link to it from all languages, for example {{Code|style=2|<nowiki>[[Page]]</nowiki>}}. In the case of subpages, you will have to add the language code for each language individually, for example {{Code|style=2|<nowiki>[[Page/es]]</nowiki>}}, {{Code|style=2|<nowiki>[[Page/ja]]</nowiki>}}, 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 {{Code|style=2|{{tl|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.
}}

{{Message
| user = Amicdict
| time = 15:55, 01 Apr 2023
| I agree with your reasoning, but why use an {{code|/}} for the subpage instead of the {{code|:}}?
}}

{{Message
| user = Max34
| time = 18:23, 1 Apr 2023
| MediaWiki (what this wiki is based on) does not know how to work with colons, but it knows how to work with slashes. If text separation worked on this wiki, relative to the selected character (in MediaWiki it is called {{code|style=1|<nowiki>{{#explode:}}</nowiki>}}), then switching to slashes would not be necessary.}}

==Adding Esperanto as a language==
{{Message 
| user = Amicdict
| time = 21:43, 31 Mar 2023
| 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}}

==Mess==
{{Message
| user = Xandros
| time = 16:31, 3 Apr 2023
| 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 documenation – to be accurate? I fail to see the real usefulness of the change.
}}

{{Message
| user = Amicdict
| time = 22:32, 3 Apr 2023
| {{quote|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?}}

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.)

{{quote|To code things you need to know English anyway.}}

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.
}}

{{Message
| user = Max34
| time = 21:54, 3 Apr 2023
| I agree about the inconvenience of switching to editing. I think this problem can be partially solved by making the edit button as a separate one, so that you do not have to open the drop-down list every time.

I have already explained most of the reasons why this way is ''better'' [[Template talk:MultiPage#uselang_vs_subpage|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 {{Code|<nowiki>[[Page:es]]</nowiki>}} on the Spanish page, only {{Code|<nowiki>[[Page]]</nowiki>}} everywhere and no more hundreds of thousands of categories and templates in different languages); the ability to use, for example, {{Code|style=2|<nowiki>{{sdktools}}</nowiki>}} 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.
}}

{{Message
| user = Xandros
| time = 02:21, 4 Apr 2023
| Sorry, i didn't noticed how my message has been transfered here (no notification on e-mail either).

{{quote|Except this isn't even true; many large projects have translations for technical documentation.}}
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.
}}