Page MenuHomePhabricator

Fix template Template:General_siteinfo and also update
Open, Needs TriagePublic

Description

Hi, could this Template:General_siteinfo template be fixed.

It's breaking at

! Language
| {{#if: {{{Language|}}} | {{#set: Has language={{{Language}}}}} {{#languagename:{{{Language}}}|native}} ({{#languagename:{{{Language}}}|en}}) [[Category:{{#languagename:{{{Language}}}|native}}]] [[Category:{{#languagename:{{{Language}}}|en}}]] }}

if you have a look at https://wikiapiary.com/wiki/Miraheze_(Meta) (general tab and Language section)

Also could this https://git.wikimedia.org/commit/mediawiki%2Fcore.git/ be updated to https://gerrit.wikimedia.org/g/mediawiki/core/+/ please.

Event Timeline

Unfortunately with the current display problems on WikiApiary, I can't properly investigate this, though the code pointed to here doesn't look broken to me (no obvious syntax errors, all brackets are properly matched, etc.).

I believe the issue appears to the fact that the site uses Foreground 1 as opposed to Foreground 2

I believe the issue appears to the fact that the site uses Foreground 1 as opposed to Foreground 2

I'm not sure why you think this. In any case, I tried upgrading to the latest and it didn't solve the problem, but it introduced a few of its own problems. So I backed it out.

Could it be a SemanticMediawiki/PageForm issue?

I believe the issue appears to the fact that the site uses Foreground 1 as opposed to Foreground 2

I'm not sure why you think this. In any case, I tried upgrading to the latest and it didn't solve the problem, but it introduced a few of its own problems. So I backed it out.

Just from personal experience, because every wiki I upgraded beyond MW 1.27 using Foreground 1.x broke until I upgraded to Foreground 2.x. However Foreground 2.x means Foundation 5.x which requires the tabs to be re-done. I suppose this is why you saw expected chaos.

The breakage here was actually because of the use of #languagename. I'm not sure what extension that was added by, but the modern function is #language. Unfortunately, though, that exposed another problem: in order for #language to return the name of language A in language B (e.g. {{ #language: fr | en }} to return French), Extension:CLDR must be installed (I have no idea what the replacement for {{ #languagename: lang | native }} would be, nor how it differed from just {{ #languagename: lang }}).

I believe the #languagename parser function is provided by the I18nTags extension. This indeed needs to be installed together with the CLDR extension.

I'd already migrated all uses of #languagename that I could find to #language when I left that comment, so unless there's some other functionality of the I18nTags extension that WikiApiary relies on, it doesn't need to be reinstalled (the CLDR extension does regardless, though).

Ah, ok I get it. About { #languagename: lang | native }}: native refers to the wiki instance language. I think this can be circumvented by using English in the respective spots.

According to the I18nTags extension's documentation, the native codeword causes #languagename to output the language's autonym (e.g. français for French), and outputting in the wiki's content language is achieved by not supplying any second parameter. The autonym behavior can be replicated with #language without any second parameter, and the content-language output behavior could be replicated with something like {{ #language: ... | {{CONTENTLANGUAGE}} }} (though given most wikis don't regularly change their content language,[citation needed] that's probably unnecessary =) ).

Ah, ok. I only had about a minute to look at the extension's docu. So I did not fully grasp the purpose of native. Thanks for your findings!