Language::fetchLanguageNames should not call LanguageGetTranslatedLanguageNames for invalid language codes
Open, NormalPublic


This is reproducible 100% of the time by visiting .

Clearly somehow a variant of the uniq/qinu placeholder ends up getting treated as a language code. I'm not sure whether the root cause is a bug in Translate or core. However, Translate is not catching the MWException Message->inLanguage throws (it is documented to throw, though it's not documented *when* it throws).

Sample backtrace below. This seems similar to, but not the same as, bug 44608.

2013-07-02 19:56:48 mw1044 commonswiki: [b172dcac] /wiki/Commons:Mus%C3%A9e_des_Augustins/test2 Exception from line 217 of /usr/local/apache/common-local/php-1.22wmf8/languages/Language.php: Invalid language code "[[:#if:]]uniq9aec59bbd6046bae-item-248--qinu"
#0 /usr/local/apache/common-local/php-1.22wmf8/languages/Language.php(196): Language::newFromCode('[[:#if:]]uniq9...')
#1 /usr/local/apache/common-local/php-1.22wmf8/includes/Message.php(381): Language::factory('[[:#if:]]uniq9...')
#2 /usr/local/apache/common-local/php-1.22wmf8/extensions/Translate/TranslateHooks.php(254): Message->inLanguage('[[:#if:]]uniq9...')
#3 [internal function]: TranslateHooks::translateMessageDocumentationLanguage(Array, '[[:#if:]]uniq9...')
#4 /usr/local/apache/common-local/php-1.22wmf8/includes/Hooks.php(196): call_user_func_array('TranslateHooks:...', Array)
#5 /usr/local/apache/common-local/php-1.22wmf8/includes/GlobalFunctions.php(3834): Hooks::run('LanguageGetTran...', Array)
#6 /usr/local/apache/common-local/php-1.22wmf8/languages/Language.php(873): wfRunHooks('LanguageGetTran...', Array)
#7 /usr/local/apache/common-local/php-1.22wmf8/languages/Language.php(918): Language::fetchLanguageNames('[[:#if:]]uniq9...', 'all')
#8 /usr/local/apache/common-local/php-1.22wmf8/includes/parser/CoreParserFunctions.php(770): Language::fetchLanguageName('fr', '[[:#if:]]uniq9...')
#9 [internal function]: CoreParserFunctions::language(Object(Parser), 'fr', '[[:#if:]]UNIQ9...')
#10 /usr/local/apache/common-local/php-1.22wmf8/includes/parser/Parser.php(3560): call_user_func_array(Array, Array)
#11 /usr/local/apache/common-local/php-1.22wmf8/includes/parser/Parser.php(3278): Parser->callParserFunction(Object(PPTemplateFrame_DOM), '#language', Array)
#12 /usr/local/apache/common-local/php-1.22wmf8/includes/parser/Preprocessor_DOM.php(1085): Parser->braceSubstitution(Array, Object(PPTemplateFrame_DOM))
#13 /usr/local/apache/common-local/php-1.22wmf8/includes/parser/Parser.php(3432): PPFrame_DOM->expand(Object(PPNode_DOM))
#14 /usr/local/apache/common-local/php-1.22wmf8/includes/parser/Preprocessor_DOM.php(1085): Parser->braceSubstitution(Array, Object(PPTemplateFrame_DOM))

Version: 1.22.0
Severity: normal


T28213: Strip marker issues (tracking)
bzimport added a subscriber: Unknown Object (MLST).
bzimport set Reference to bz50606.
Spage added a comment.Jul 2 2013, 9:22 PM

We noticed this monitoring the ganglia graph for fatals and exceptions, , it causes a steady stream of them, perhaps as bots visit that test page on Commons.

The page is a series of transclusions followed by the same transclusion nested in a pre tag inside a {{collapse} template. Individually they work fine; bigger chunks are extremely slow to preview and save, often leading to timeouts. When I pasted the first half into a page and saved, I got an "Our servers are currently experiencing a technical problem" error, but the save did finally complete. So the problem seems to be a "quantity not quality".

See bug 49423 for similar case. I vouch that MediaWiki should not relay invalid language codes to hooks.

In this case I think there should be a check for valid language code either in the magic word or in the fetchLanguageNames method.

(In reply to comment #2)

In this case I think there should be a check for valid language code either
in the magic word or in the fetchLanguageNames method.

Seems reasonable. I've updated the summary.

Add Comment