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 <niklas.laxstrom(a)gmail.com>om>:
2014-10-29 10:58 GMT+02:00 Philippe Verdy
<verdy_p(a)wanadoo.fr>fr>:
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.
-Niklas