Last modified: 2013-11-12 08:45:09 UTC
This is reproducible 100% of the time by visiting https://commons.wikimedia.org/wiki/Commons:Mus%C3%A9e_des_Augustins/test2 . 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))
We noticed this monitoring the ganglia graph for fatals and exceptions, http://tinyurl.com/n3twd8k , 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 https://commons.wikimedia.org/wiki/User:S_Page_%28WMF%29/test2, 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.
