Last modified: 2013-06-18 16:47:05 UTC
Wikipedia Mobile breaks when languages use multiple or different language codes than it expects. Languages where this will probably be an issue: * als/gsw * no/nb * be-x-old/be-tarask * zh-classical/lzh * zh-yue/yue For example, we have a Swiss German translation at "gsw" but the Wikipedia is at "als"... there's no way to view the translation, because gsw.m.wikipedia.org doesn't exist and als.m.wikipedia.org doesn't pull the Swiss German translation at gsw. Wikipedia Mobile should follow the MediaWiki fallback scheme somehow: <http://svn.wikimedia.org/viewvc/mediawiki/trunk/phase3/languages/messages/MessagesAls.php?view=markup>
Does this concern content languages, or interface languages ?
(In reply to comment #1) > Does this concern content languages, or interface languages ? Interface languages. 'als' itself does not have any localisation, because "Allemanisch", aka "Swiss German" has ISO 639-3 code 'gsw'. So it is localised in 'gsw'. zh-yue is localised in 'yue'. So if the Wikimedia Mobile only takes 'als' and 'zh-yue' respectively into account, those versions will not have any localisation. Similarly, 'arz' (Egyptian Spoken Arabic) has a fallback to 'ar' (Arabic). In MediaWiki this means that if Arabic is fully localised, but Egyptian Spoken Arabic is ony partially localised, the missing strings will not be replaced with English, but with Arabic strings. You can grep '$fallback' in http://svn.wikimedia.org/viewvc/mediawiki/trunk/phase3/languages/messages/ for the fallback languages.
Seems not to be an option of the default i18n in ruby. Might be possible to work around with this tool: http://github.com/kipcole9/rails-i18n-translation-inheritance-helper
Actually, this is really just an issue of not having "gsw" being a code setup with the DNS. We'll get that sorted out soon enough. -hampton.
