MediaWiki talk:Lang

Regarding the definition of the interface language

Right now the site uses {{Uselang}} and {{Intlang}} templates to define the interface language. This is not implemented in the best way: by checking certain interface messages for specific text. But this is the only way to properly implement a language definition. This option is not ideal, since if the interface is not translated into some language, it will be impossible to determine it (for example aa lang). There are only two options on what to do to solve this problem:

Create MediaWiki:Lang which will store all the language codes (MediaWiki:Lang/es = es, MediaWiki:Lang/ca = ca, MediaWiki:Lang/ru = ru, etc.), so it will be enough to enter {{int:lang}} to get the interface language.

Or add a MediaWiki extension that adds a magic word that displays the interface language code: mw:Extension:UILangCode. —Max34 (talk) 7:32, 15 June 2024 (UTC)

Extensions are a no-go since I presently don't have access to the server containing the wiki. I can do the first option, but I'd have to do it later. —PabloS (talk) 18:38, 15 June 2024 (UTC)

As I've noticed, people have moved away from {{Uselang}} and {{Intlang}} in favor of checking a single interface message (MediaWiki:Img-lang-go), but this method still requires converting from text to language code, which is bad. Furthermore, this isn't done with a single simple switch, but with a bunch of templates, which is even worse. This format adds these templates to the templates used on the pages, which means more unnecessary dependencies.

Moreover, this format might be difficult to scale, because if two languages ​​have the same translation, they won't be distinguishable. I understand that this is not the most necessary thing, but it is better to do it right from the start so that you don't have to fix it later. Creating this interface message is the best solution to all these problems. —Max34 (talk) 04:34, 5 October 2025 (PDT)

It’s faster way to not have switch but bunch of templates. If conflict arises switch can be added to the conflicting languages. Of course this solution is simpler but the current one is already close to this. —Nescius (talk) 06:54, 5 October 2025 (PDT)

The switch option is better. And not because I think so, but because I tested it before writing about it, including in different languages ​​and usage scales. It also eliminates one expensive function usage and the sub-template is no longer called, eliminating the dependency on multiple templates.

However, the interface message option is the best because it eliminates the need to rely on any templates at all. You won't have to worry about someone breaking them, either accidentally or on purpose. —Max34 (talk) 09:03, 5 October 2025 (PDT)

How much faster ? It's probably negligible. Also what do you mean by unnecessary dependencies ? The templates aren't even shown as linked by any page and list of used templates at the bottom of the page only shows the english one. Either way the current way is already way faster than whatever the uselang/intlang of the past was and there really isn't much activity outside of zh, ru and hr translations so it's quite low priority —Nescius (talk) 12:08, 5 October 2025 (PDT)

I could be wrong, but as far as I remember, expensive functions take longer to process. The Switch variant doesn't win in other values (they're more or less equal), but it should have faster load times, since there's no need for an expensive function in its case. I agree that the topic of translations is not such a priority and that there are few active translators, but I can’t just leave it in a half-finished state. I have some ideas I'd like to try out, because they may have potential. And no, this isn't an attempt to bring back {{MultiPage}} and ruin everything again. I'd really like to discuss this and what the language system has become, but I'd suggest continuing this conversation in a more appropriate place. —Max34 (talk) 12:53, 5 October 2025 (PDT)

It is not in half finished state. It’s in a state that works with minimal interference to the english side of the wiki which is the highest priority. 1 expensive function is non issue for this and also haven't noticed any slowdown from using ifexist and checking the cpu time shown at the bottom so not sure what it exactly means for the wiki that a function is expensive other than there being the limit. —Nescius (talk) 14:18, 5 October 2025 (PDT)