Only complex for developers. The actual need is that translators start translating one form then later realize that they need another form and be able to specify for which case/number they want to specialize a variant.
The interface can then propose a "detailled" view summarizing how the various forms are mapped, including their fallback. Translators can then just click and confirm the proposed fallbacks or copy-paste another existing translated form for the same base resource.
All forms should be grouped and a si,ple view could just list those that are different; and summarize the list of cases/numbers to which they apply.
Internally the fallback mappings is part of the support code, and translators won't have to focus on it.
And in the simplest case, they'll start by translating the default plural rule ("other" in CLDR) for used for undetermined numbers and the nominative case (or the effective case when translating full sentences).
The internal Gettext numbering of forms (plural, case...) is technical and should not be exposed to translators but they should have a clear labelling of these cases and possible test cases for various numbers in the detailed view. Adding variant forms should remain optional and should not impact the language fallbacks (language fallbacks should never be used as soon as there's the default "other" form translated).

2014-10-29 10:21 GMT+01:00 Niklas Laxström <>:
2014-10-29 10:58 GMT+02:00 Philippe Verdy <>:
> I'd then suggest that the trnaslation interface allows selecting BOTH the number and grammatial case to map them to one of the possible forms, and then let the adapter interface mame the necessary mapping to the precise symbolic forms or one of its fallbacks.

I18n and l10n is complex topic. We are trying to keep it as simple as
possible for translators and developers. What you propose does not
bring more power to the system, only makes it more complex.