Last modified: 2013-06-18 16:57:42 UTC
bug 17592 lends itself towads the idea that the fallback language for both nds-NL and nds-DE localizations could or should become nds rather than current nl and de. Discussion also revealed that indeed: nds-NL → nds → nl → (en) and nds-DE → nds → de → (en) was the best possible choice. This is backed by the recent two decades of assement in scientific literature of the language groups involved, which is also reflected at least in the corresponding articles in the German Wikipedia (did not check any other ones) (By the way, we have, or shall likely soon encounter, similar complexities with other language groups) Such fallback paths are currently impossible, since we have only one single fallback language per language. Yet, the concept can pretty easily be expanded by allowing fallback languages to be given as an array of language codes, too, which we should do. Array members are to be checked in the given order, before any of their own fallback languages are, and this may recurse. No language is to be checked a second time, obviously, and we can still keep the limit of at most 5 languages (imho), thus not sacrificing any processing time.
IMO this is a problem created by a proposed solution. If the solution for named bug were changed, the problem raised here would not exist. This is however on 'the list' for translatewiki.net for another reason, too. We would like users to be able to choose their own fallback languages, because they know best which languages their wiki UI should fall back to.
The latter is a "well accepted" side effect that I had in mind, too :-) Similar problems exist with other languages as well, so we cannot blame nds.
This is what some modern applications offer. To me it remains questionable how much benefit it would have, since we already have default fallbacks which cover most of the cases, and the translation coverages for languages vary.
Bug 11267 related.
I think this bug is fixed par user specific fallback sequences, which are topic for another bug.
The user specific fallback sequences alone do not really solve all possible problem aspects mentioned here. And yes, it will provide a framework that makes the needed per langauge adjustments possible.
