Page MenuHomePhabricator

create more complex fallback language rules.
Closed, ResolvedPublic

Description

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.


Version: 1.15.x
Severity: enhancement

Details

Reference
bz17608

Related Objects

Event Timeline

bzimport raised the priority of this task from to Low.Nov 21 2014, 10:35 PM
bzimport set Reference to bz17608.

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.

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.