WeblateOrg / weblate

Web based localization tool with tight version control integration.
https://weblate.org/
GNU General Public License v3.0
4.48k stars 994 forks source link

Feature request: Custom Plural forms #1555

Closed yarons closed 7 years ago

yarons commented 7 years ago

I'll start by presenting the lingual necessity and move on to the technical details:

Lingual

In Hebrew there are special cases where more than 2 plural forms are needed, mostly when the terms are time related, first we'll see the regular form and then the expanded plural form requirement -

Here we can see a change in position between the singular and plural and also a change in the plural definition of House, the words in bold are all nouns.

Let's look at a similar example but this time with years -

As you can see in this example the 2nd line is an exception, the dual form is incorporated within the word year while affecting the word itself.

Technical

In order to predefine an exception we need to have a method to uniquely identify strings so we can keep the special Plural Forms formula for this string specifically. This is where the Portable Object (PO) by GNU is lacking, there is no way to uniquely identify strings this we have to declare a default for the document and we must follow this formula throughout the entire document regardless of the noun or lingual necessity.

Few of the formats that allow us to break the Plural Forms rules are: Android Strings XML, XLIFF and L20n by Mozilla.

Part of this change was not only to change the Plural Forms on the file but also to create a method to specifically assign a gender to a string, this is especially important for platforms such as Facebook which incorporated Gender and Quantity definition for several cases:

So we ask the translator question about the different possible variations of the string, we have some general questions such as:

Now we can ask the translator about the variations according to the arguments:

In Facebook there's a very simple interface allowing you to break the string into conditional destination strings according to a unique specification based on the identification of the source string.

The only problem I can think of is that if we'll need to save the file to PO than the structure will flatten or all the simple Plural Forms will expand and cause a major headache for the translator, another option could be that if the translator has expanded the Plural Forms there will be no option to export to PO.

Hoping that was clear enough.

Thanks.

nijel commented 7 years ago

I think this is (again) pretty much same issue as https://github.com/WeblateOrg/weblate/issues/1550...

yarons commented 7 years ago

Looks similar, in XLIFF and L20n there's also gender fields so it's a little different after all.

nijel commented 7 years ago

L20n has quite complex expression language and I don't think we will ever support this completely. For XLIFF the gender choice AFAIK has to be defined in the file, so it's nothing you could add afterwards. The same applies for plurals - you can use whatever is supported by the format (eg, stick with CLDR for Android Strings, or what matches the plural formula as defined in Gettext PO), AFAIK none of them allows to specify this per string. I really don't see need to provide more fine grained support in Weblate as there is probably the only file format which can utilize this (L20n) and that is currently not supported by Weblate anyway (and nobody requested that so far).

yarons commented 7 years ago

IIRC in XLIFF you can define the gender and plural form on a string basis.

nijel commented 7 years ago

Can you point to some reference about that? All XLIFF files I've seen so far defined no plural rules at all and Googling really doesn't show anything useful on this topic...

nschonni commented 7 years ago

http://docs.oasis-open.org/xliff/v1.2/xliff-profile-po/xliff-profile-po-1.2-cd02.html#s.detailed_mapping.tu.plural

Edit: also https://wiki.oasis-open.org/xliff/XLIFF2.0/Feature/Plural%20Entries

nijel commented 7 years ago

The XLIFF 1.2 relies on Gettext, so uses plural form defined in x-gettext-domain-header, so it's per file not per string.

The XLIFF 2.0 thing is state: under-evaluation and doesn't (yet) have a specification...