Page MenuHomePhabricator

Add a {{USERLANGUAGE}}/{{USERLANG}} magic word
Open, LowestPublic

Description

Author: gangleri

Description:
Halló,

The benefits of a variable returning the language code of the selected user interface can not be foreseen and all "applications" can not be described here.

Hopefully it should be easy to implement and be available soon.

Regards Reinhardt


Version: unspecified
Severity: enhancement
URL: https://commons.wikimedia.org/wiki/MediaWiki:Lang?uselang=eo
See Also:

Workarounds available:

Details

Reference
bz2085

Related Objects

Event Timeline

bzimport raised the priority of this task from to Lowest.
bzimport set Reference to bz2085.
bzimport added a subscriber: Unknown Object (MLST).
bzimport created this task.May 6 2005, 3:14 AM
brion added a comment.May 6 2005, 4:21 AM

Content pages are aggressively prerendered and cached, and must be independent of UI options
as much as possible to maintain our performance requirements.

brion added a comment.May 25 2005, 9:00 PM
  • Bug 2246 has been marked as a duplicate of this bug. ***
brion added a comment.Jun 12 2006, 8:15 PM
  • Bug 6283 has been marked as a duplicate of this bug. ***

Wouldn't it be possible to realize this for explicitly multilingual projects
only and create a language-dependant cache?

The cache isn't the only problem; the use of such variables in template selection and conditional text
inclusion would result in massive corruption of link tables, so that templates and other tools don't update
properly.

ayg wrote:

*** Bug 8059 has been marked as a duplicate of this bug. ***

  • Bug 14098 has been marked as a duplicate of this bug. ***

See Bug 14404 for a bug which is, in fact, a way to implement this requested feature :-x

i.am.putnik wrote:

*** Bug 14633 has been marked as a duplicate of this bug. ***

  • Bug 1136 has been marked as a duplicate of this bug. ***
  • Bug 16608 has been marked as a duplicate of this bug. ***

Wiki.Melancholie wrote:

Please see and read bug 16608.

Pro arguments in short:

Wiki.Melancholie wrote:

Note: On Betawiki (translatewiki.net) there is such a magic word; but they call it {{UILANGCODE}}

The functionality is needed and used, when necessary with a (maybe even worse) {{int:.../lang}} method. This magic word would be nothing else but {{int:.../lang}} except that it is much easier to use (as available on every wiki by default, you do not have to set up 250+ lang subpages on every wiki). Just give {{int:.../250+}} a cleaner, single name.

Reclosing as WONTFIX.

As outlined many times before: user-dependent parser functions such as this make the parser cache useless. They also pollute link tables as outlined in comment #5 and in bug 16608 comment #4. While it is true that adding this wouldn't make that situation _worse_, we hardly want to encourage the behavior.

Patiently awaiting a fix for bug 14404.

Note comment 13: it could be enough to enable Translate extension on Commons.

(In reply to comment #14)

Patiently awaiting a fix for bug 14404.

The bug has been fixed, but the current behaviour isn't documented anywhere but https://meta.wikimedia.org/wiki/Help:System_message which should be updated. Even if there isn't a decision about what behaviour is the best and should be kept forever, documenting the current system is necessary, as well as keeping it until we have proper alternatives.

Very support of this request! Current realization of Template:Autotranslate (widely used in the multilanguage sites as Commons and Meta) forced to use a hack with calling MediaWiki:Lang/ sub-messages.

If MediaWiki engine is still defines the user-interface language, there is no valid reason not to return the language through such magic word.

I'm sorry but per comment 14 this is considered a lowest priority bug and nobody is working on it; don't mislead users.
I'd like to have it, too, but voting is how to express it.

By the way:

(In reply to comment #16)

Note comment 13: it could be enough to enable Translate extension on Commons.

That magic word is a local hack, but for templates et al. see:
[[mw:Help:Extension:Translate/Unstructured element translation]]
[[Help:Extension:Translate/Page_translation_administration#Markup_examples]]

(In reply to comment #18)

I'm sorry but per comment 14 this is considered a lowest priority bug and
nobody is working on it; don't mislead users.
I'd like to have it, too, but voting is how to express it.

Hard to argue with the beautiful words of the Brion The Great and Chad H.

But thing is that this feature is _really_ needed, and still _really_ used all these years. Okay, "we hardly want to encourage the behavior" - we want to encourage creating of large sets of faked MediaWiki messages?

(In reply to comment #18)

I'm sorry but per comment 14 this is considered a lowest priority bug and
nobody is working on it; don't mislead users.

Note that the comment was made before the time every page on Commons used the {{int:lang}} hack. After that, and especially after bug 14404 was fixed, I don’t see the reason why the {{int:lang}} hack shouldn’t be implemented properly instead of abusing a different construction. The cache coherence issues should have been resolved by bug 14404, AFAICS. So, there is no need why this should be a WONTFIX. (See also http://lists.wikimedia.org/pipermail/wikitech-l/2012-January/057763.html (corrected link from comment #15).)

As for “nobody is working on it”: this is not difficult to implement, programming-wise. Just to make sure it gets accepted to core.

NB: I inform of Amir E. Aharoni (from Language engineering team) about this issue. He seems willing to do it soon.

(In reply to comment #21)

NB: I inform of Amir E. Aharoni (from Language engineering team) about this
issue. He seems willing to do it soon.

More precisely, I suggested opening a bug about this issue in a private chat. I didn't know that this one is open already, but it makes sense.

That's the kind of thing that the Language engineering team does, but just as Mormegil says: the important part is getting the consensus to accept it into core.

Also one reason for this feature: using in the URLs as in the http://www.wikidata.org/wiki/MediaWiki:Sitesupport-url

In the multilang. Wikimedia projects (Meta, Commons, Wikidata, Wikispecies, Wikimania, WMF wiki, ...), fundraising's URL was generated with English-language option "&uselang=en".

With using {{USERLANG}} variable, will be able to direct users to the donation page on the language that they use in the his interface.

(In reply to comment #23)

Also one reason for this feature: using in the URLs as in the
http://www.wikidata.org/wiki/MediaWiki:Sitesupport-url

In this example, however, you have the non-hacky workaround of creating the subpages with correct uselang. We should do it by bot at least on Meta, Commons and Wikidata, perhaps. (Better to discuss on Meta though.)

  • Bug 46372 has been marked as a duplicate of this bug. ***

ziggy wrote:

For those who'd like this feature, I've hacked a new magic word as part of my copy of UniversalLanguageSelector: {{USERLANG}}

New UniversalLanguageSelector.i18n.magic.php file:
$magicWords = array();
$magicWords['en'] = array('userlang' => array(0,'USERLANG'));

Added to UniversalLanguageSelector.php, below last hook:
$wgHooks['ParserGetVariableValueSwitch'][] =
'UniversalLanguageSelectorHooks::getLanguageMagic';
$wgHooks['MagicWordwgVariableIDs'][] =
'UniversalLanguageSelectorHooks::getLanguageMagicDeclareVarIds';

Added to UniversalLanguageSelector.hooks.php, above getLanguage(...):
public static function getLanguageMagicDeclareVarIds( &$customVariableIds ) {

$customVariableIds[] = 'userlang'; return true; }

public static function getLanguageMagic(&$parser, &$cache, &$magicWordId, &$ret
) { if ( 'userlang' == $magicWordId ) {

  $context = RequestContext::getMain();
  $code = $context->getLanguage()->getCode();
  $ret = self::getLanguage($context->getUser(), $code) ? $code : '';
  if($ret != $wgLanguageCode) $parser->disableCache(); }
return true; }

Works like charm, although heeding the warnings of the previous posters the cache gets disabled if the userlang is different than the wgLanguageCode :-) It now behaves very much like the dynamic results obtained from a database (e.g. WikiDB)

(In reply to ziggy from comment #26)

For those who'd like this feature, I've hacked a new magic word as part of
my copy of UniversalLanguageSelector: {{USERLANG}}

New UniversalLanguageSelector.i18n.magic.php file:
$magicWords = array();
$magicWords['en'] = array('userlang' => array(0,'USERLANG'));

Added to UniversalLanguageSelector.php, below last hook:
$wgHooks['ParserGetVariableValueSwitch'][] =
'UniversalLanguageSelectorHooks::getLanguageMagic';
$wgHooks['MagicWordwgVariableIDs'][] =
'UniversalLanguageSelectorHooks::getLanguageMagicDeclareVarIds';

Added to UniversalLanguageSelector.hooks.php, above getLanguage(...):
public static function getLanguageMagicDeclareVarIds( &$customVariableIds ) {

$customVariableIds[] = 'userlang'; return true; }

public static function getLanguageMagic(&$parser, &$cache, &$magicWordId,
&$ret
) { if ( 'userlang' == $magicWordId ) {

  $context = RequestContext::getMain();
  $code = $context->getLanguage()->getCode();
  $ret = self::getLanguage($context->getUser(), $code) ? $code : '';
  if($ret != $wgLanguageCode) $parser->disableCache(); }
return true; }

Works like charm, although heeding the warnings of the previous posters the
cache gets disabled if the userlang is different than the wgLanguageCode :-)
It now behaves very much like the dynamic results obtained from a database
(e.g. WikiDB)

Could you please commit this to Gerrit?

(In reply to Melancholie from comment #13)

Note: On Betawiki (translatewiki.net) there is such a magic word; but they
call it {{UILANGCODE}}

That's https://git.wikimedia.org/blob/translatewiki.git/HEAD/nikext.php btw.

(In reply to Nemo from comment #28)

(In reply to Melancholie from comment #13)
> Note: On Betawiki (translatewiki.net) there is such a magic word; but they
> call it {{UILANGCODE}}

That's https://git.wikimedia.org/blob/translatewiki.git/HEAD/nikext.php btw.

Does it support caching correctly? Is there any reason not to use this?

(In reply to PiRSquared17 from comment #29)

Does it support caching correctly? Is there any reason not to use this?

It would if it used $parser->getOptions()->getUserLang().

demon removed a subscriber: demon.Dec 8 2014, 10:42 PM
He7d3r updated the task description. (Show Details)Apr 8 2015, 10:49 PM
He7d3r set Security to None.
Nemo_bis updated the task description. (Show Details)Apr 22 2015, 7:02 PM
Rical added a subscriber: Rical.Jul 13 2015, 4:09 PM
Restricted Application added a subscriber: Aklapper. · View Herald TranscriptNov 11 2015, 11:51 AM
kaldari added a comment.EditedFeb 10 2016, 11:35 PM

No one has commented on this bug in a couple years. It was closed twice as WONTFIX and it doesn't seem like there is developer support for implementing it. Is there any reason it should be kept open?

This task is needed as part of central modules T121470#1880317
The goal is to show arguments names, categories, error messages in the helper language when he helps a small wiki which has not enough specialists of modules.
See also T122086

No one has commented on this bug in a couple years. It was closed twice as WONTFIX and it doesn't seem like there is developer support for implementing it. Is there any reason it should be kept open?

All reasons is present. This is still needed. Template "Uselang" (tghrough "hacked" way) is still used widely.

The problem with this task is that it asks for a specific solution (which is unlikely to be implemented) instead of focussing the discussion on what are the use cases and how those cases could be best solved.

@Nikerabbit: That's a good point. The only use cases I know of currently are:

More use cases would be helpful.

V111P added a subscriber: V111P.May 6 2016, 11:25 PM
Rical added a comment.EditedMay 7 2016, 7:42 AM

In at least 3 cases we need adaptations of translations depending not only from the wiki language or the user language :

  • The genre of the user in his preferences
  • The format of date-time in some régions or sub-languages
  • In mw.language.convertPlural() "if your language has several plural forms"

Can we, and is it adapted, to group all these cases in a same translations adapter with some parameters linked to the user : gender, sub-language, rights(sysop, bureaucrat...), plural forms?

Rical added a comment.Aug 15 2017, 1:23 PM

That permit to really try the user language for central modules.
user_lang = modes.frame:preprocess( "{{int:Lang}}" )
creating https://fr.wikisource.org/wiki/MediaWiki:Lang/en
creating https://fr.wikisource.org/wiki/MediaWiki:Lang/es
creating https://fr.wikisource.org/wiki/MediaWiki:Lang/fr
also in some other wikis if needed.
Thanks

Rical added a comment.Aug 15 2017, 2:37 PM

Create a page to permit each language seems to me very strange.
Another way could be to define the basic language of the wiki on the first line.
Then, on the second line, a list of all other languages to permit.
This way could permit to administrators to easy know or change this list without long researches.

Verdy_p added a subscriber: Verdy_p.EditedSep 7 2017, 4:24 PM

Any way used by {{int:Lang}} and implemented internally by the {{int:}} parserfunction that will always need to get the correct user language should be still be made available even if we don't manually create the MediaWiki:Lang/* resources (because the "int:" extension can already internally recognize the resource name and does not need to query the database to retrieve these fake pages, all it has to do is still to get the correct user language code for any kind of {{int:*}} message needed by the Mediawiki core itself; I think it also adds some work to also mark specially the expanded pages so that they will be cached separately according to the user language)
The same should then be made for Lua, by adding into Scribunto supporting the {{#invoke:}} extension a basic module that will do the same thing as what the {{int:}} extension does, using the same logic for cache management and to return the same language code: it should then be exposed into Lua by a "mw:userLanguage()" that won't require any use of "frame:prepropress()" with its unbelieavable, and undocumented side-effects (notably the fact it fully expands prematurely all text in parent frames instead of just the wikitext given in its single string parameter !)

So Scribunto now really needs to be fixed. Demon,station has been done that this was really needed:

  • add "mw:getUserLanguage()" or "frame:getUserLanguage()" : I don't know which class is the best place to add this API.
  • provide immediately a workaround in "frame:preprocess(text)" so that it will not preprocess the given text when it just matches /^\{\{[ *[Ii][Nn][Tn]: *[Ll]ang *\}\}$/ : it will use the previous function instead
  • fix "frame:preprocess(text)" to avoid full expansion of everything in parent frames as much as possible (wikicode parsing and expansion should only be made lazily for only what was demended)
  • investigate the other bugs (related to Wikidata client retrieveing only full objects instead of just the selected properties)
  • other bugs related to exceptions for memory exhaustion in PHP->Lua->PHP is independant but still needs a better fix than what is currently worked on (which is a real hack if it just consist in increasing or relaxing the memory constraints, and will not solve any problem if the exception is handled correctly but it still causes unexpected HTTP 500 failures on the server in other modules not expecting the new exception or if it causes them to return a dummy expanded error text instead)

Now, the page language come from frame:preprocess("{{PAGELANGUAGE}}").
For the same reasons as the user language, the page language could use the new way to give it to Scribunto modules.

Verdy_p added a comment.EditedSep 16 2017, 1:36 PM

PAGELANGUAGE is NOT the correct one. It was the user language that was expected (we won't have per-language categories, category pages won't be translated, the navbox was intended to provide coherent international navigation independantly of the English name of the categories, and without having to create and edit many translations within the page itself (this is about tens of thousands of categories). This PAGELANGUAGE would be a severe return backward where only English will be displayed on Commons.

frame:preprocess( "{{int:Lang}}" ) is far better than frame:preprocess( "{{PAGELANGUAGE}}" ) which is really different. We are still needing a simpler way in Lua to get the user language directly within a variable from the PHP environment (i.e. available as a string property in mw or frame, without needing any additional preprocessing for its expansion).

In summary do not confuse the three distinct languages:

  • default language of the wiki (English only in Commons or Meta or "old Wikisource", or the language of the project wiki when it has separate linguistic editions, such as French for French Wikipedia)
  • page language (only works for pages using the translate extension, or pages that would use some magic keyword to design to indicate in which language a monolingual page is effectively written, or some wiki specific hook parsing some pagename or namespace convention, notably for beta wikis like Incubator, or like OpenStreetMap wiki). Useful for multilingual wikis that still have language-specific pages (possibly translated, but this is not always the case and their language is NOT necessarily the same as the default wiki language; translated pages can come later using some wiki-specific naming convention that "page language" would detect with some hooks, such as the hook used by the "Translate" extension, which expects languages codes to be found as the last subpage name). If a page is not detected by the special hook as being marked/tagged/named to be in a specific language, the page language will be assumed to be the default language of the wiki (not necessarily English as said above). For example an "English Embassy" community page on the French Wikipedia could be marked/tagged as having "page language = en" even if the default language of the wiki is French. The page language also will afftect how the layout will be generated (notably there will be CSS classes or styles for RTL languages, and cells of tables will render in different order, and paragraphs will be aligned on a different margin, thumb images will float by default on another side... The "English Embassy" page on the Arabic Wikipedia would have a radically different layout than most ofther pages of the Arabic wiki; the "side bars" on the opposite will have a layout based on the user language, but will not be affected by the page language or the wiki default language)
  • user prefered language (at set by the Universal Language selector, or in user preferences or when using "uselang=code" in query strings (part of the URL), to be used typically in navboxes transcluded in pages (such as categories) that will never be translated directly. It is the same language used by the Mediawiki UI (translations come from the "int:" parser function that uses translations imported into the special namespace from translatewiki.net or added locally by local wiki admins). This is always independant of the two previous languages, any user can set its own language preference or view any page with "uselang=code" parameter in the query string. This means that the same page will render differently depending on language, and MediaWiki already has separate caches for pages rendered with different user language (each version is cached inpendantly, the lifetime of these server-side caches are also independant: you can "purge" the version in English this does not purge the French version, and caches will expire or will be cleaned also independantly of any explicit purge action, if storage space gets exhausted, by using a LRU algorithm where the oldest retreived pages from the cache will be purged first to make space)
Rical added a comment.Sep 16 2017, 2:05 PM

Many thanks for this overview of languages.
For 2 days, I made the function form2en() dedicated to tests many functions, always in english, to increase the stability of central modules, using ClassNameTests.

Kghbln added a subscriber: Kghbln.Jun 19 2018, 8:07 PM

There is the MyVariables extension around which provides the {{USERLANGUAGECODE}} variable. This is only available for third party instances though.

Kghbln updated the task description. (Show Details)Jun 20 2018, 7:21 AM
Kghbln updated the task description. (Show Details)

Why did you cross nikext? It's still available, the vcs link just needs updating.

Why did you cross nikext? It's still available, the vcs link just needs updating.

Sorry, I did not find it so I assumed it is gone. You are welcome to do the honors.