Last modified: 2014-08-03 09:20:41 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T4085, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 2085 - Add a {{USERLANGUAGE}}/{{USERLANG}} magic word
Add a {{USERLANGUAGE}}/{{USERLANG}} magic word
Status: REOPENED
Product: MediaWiki
Classification: Unclassified
Internationalization (Other open bugs)
unspecified
All All
: Lowest enhancement with 12 votes (vote)
: ---
Assigned To: Nobody - You can work on this!
http://commons.wikimedia.org/wiki/Med...
: i18n, performance, platformeng
: 1136 2246 6283 8059 14098 14633 16608 46372 (view as bug list)
Depends on: 14404
Blocks: 66051
  Show dependency treegraph
 
Reported: 2005-05-06 03:14 UTC by lɛʁi לערי ריינהארט
Modified: 2014-08-03 09:20 UTC (History)
27 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments

Description lɛʁi לערי ריינהארט 2005-05-06 03:14:31 UTC
Halló,

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

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

Regards Reinhardt
Comment 1 Brion Vibber 2005-05-06 04:21:07 UTC
Content pages are aggressively prerendered and cached, and must be independent of UI options 
as much as possible to maintain our performance requirements.
Comment 2 Brion Vibber 2005-05-25 21:00:21 UTC
*** Bug 2246 has been marked as a duplicate of this bug. ***
Comment 3 Brion Vibber 2006-06-12 20:15:25 UTC
*** Bug 6283 has been marked as a duplicate of this bug. ***
Comment 4 Marcus Buck 2006-09-19 19:09:09 UTC
Wouldn't it be possible to realize this for explicitly multilingual projects
only and create a language-dependant cache?
Comment 5 Brion Vibber 2006-09-20 12:01:21 UTC
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.
Comment 6 Aryeh Gregor (not reading bugmail, please e-mail directly) 2006-11-28 03:56:00 UTC
*** Bug 8059 has been marked as a duplicate of this bug. ***
Comment 7 Raimond Spekking 2008-05-12 21:29:01 UTC
*** Bug 14098 has been marked as a duplicate of this bug. ***
Comment 8 Mormegil 2008-06-04 13:00:09 UTC
See Bug 14404 for a bug which is, in fact, a way to implement this requested feature :-x
Comment 9 Sergey Leschina 2008-06-24 20:59:03 UTC
*** Bug 14633 has been marked as a duplicate of this bug. ***
Comment 10 Mormegil 2008-09-11 16:36:42 UTC
*** Bug 1136 has been marked as a duplicate of this bug. ***
Comment 11 Mormegil 2008-12-10 10:14:08 UTC
*** Bug 16608 has been marked as a duplicate of this bug. ***
Comment 12 Melancholie 2008-12-10 10:38:54 UTC
Please see and read bug 16608.

Pro arguments in short:

* {{CONTENTLANGUAGE}} & {{CONTENTLANG}} thus call it {{USERLANGUAGE}} & {{USERLANG}} (as {{USERIFCODE}} is too weird)
* as a workaround {{int:.../lang}} (e.g. see [[commons:MediaWiki:Lang]]) is used already
* example:
** http://als.wikiquote.org/wiki/Example?uselang=de
** http://als.wikiquote.org/wiki/Example?uselang=en
* furthermore there also is wgUserLanguage = "UIlang" in output
* see https://bugzilla.wikimedia.org/show_bug.cgi?id=16608#c5
Comment 13 Melancholie 2008-12-10 10:58:23 UTC
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.
Comment 14 Chad H. 2009-07-16 00:59:39 UTC
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.
Comment 15 MZMcBride 2012-01-27 00:16:50 UTC
Re-opening due to this thread: <http://lists.wikimedia.org/pipermail/wikitech-l/2012-January/057836.html>.
Comment 16 Nemo 2012-01-27 10:06:18 UTC
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.
Comment 17 Paul Kaganer 2013-01-17 14:45:59 UTC
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.
Comment 18 Nemo 2013-01-17 15:06:38 UTC
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]]
Comment 19 Paul Kaganer 2013-01-17 15:53:48 UTC
(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?
Comment 20 Mormegil 2013-01-17 16:18:07 UTC
(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.
Comment 21 Paul Kaganer 2013-01-17 17:26:49 UTC
NB: I inform of Amir E. Aharoni (from Language engineering team) about this issue. He seems willing to do it soon.
Comment 22 Amir E. Aharoni 2013-01-17 20:59:59 UTC
(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.
Comment 23 Paul Kaganer 2013-03-08 21:04:17 UTC
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.
Comment 24 Nemo 2013-03-08 21:12:52 UTC
(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.)
Comment 25 Nemo 2013-03-20 17:53:05 UTC
*** Bug 46372 has been marked as a duplicate of this bug. ***
Comment 26 ziggy 2013-03-21 01:47:20 UTC
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)
Comment 27 PiRSquared17 2014-03-17 22:59:55 UTC
(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?
Comment 28 Nemo 2014-03-17 23:03:28 UTC
(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.
Comment 29 PiRSquared17 2014-03-17 23:25:39 UTC
(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?
Comment 30 Niklas Laxström 2014-03-18 07:53:22 UTC
(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().

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links