Last modified: 2014-09-20 20:10:41 UTC
It would be nice to avoid huge switches like on [[:m:Template:Other languages]] or [[:wm2012:Template:AddLanguageCategory]], and in general to maintain language codes centrally and ensure proper input of other parser functions such as #language. Note that the example template can't be replaced by the tools in the Translate extension where the source language is not English. Still, it can be argued that this feature is not worth a function and we should find a better way to do the things it would be used in. Compare bug 28596.
Could be a use case for Lua, but not as a parser function. Wikitext is not PHP.
Of course, actually implementing this is rather easy... Something like: /** * {{#validlanguage:string}} * * Reports whether language code is valid. * @param $parser Parser * @param $inStr string * @return bool */ public static function runValidLanguagecode ( $parser, $inStr = '' ) { wfProfileIn( __METHOD__ ); $inStr = self::killMarkers( $parser, (string)$inStr ); $valid = Language::isValidCode( $inStr ); wfProfileOut( __METHOD__ ); return $valid; } It could go in string functions and it could also go into core... That's the hard part
(In reply to comment #2) > Of course, actually implementing this is rather easy... I'm not sure it was, but it should be now that bug 41477 was fixed.
(In reply to Siebrand Mazeland from comment #1) > Could be a use case for Lua, but not as a parser function. Wikitext is not > PHP. Indeed. In fact, Lua already has mw.language.isValidCode (and a few variants) designed to do just this, so I see no reason we should add a parser function to do it.
(In reply to Jackmcbarn from comment #4) > I see no reason we should add a > parser function to do it. Well, the reason is explained in comment 0. :-) However the use case was covered in Translate with bug 68385 now and templates based on this implementation would be hacky anyway, so thanks for closing this.
