[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [xliff] Plural forms and XLIFF
Re: (S24) Representation of plural entries
https://wiki.oasis-open.org/xliff/XLIFF2.0/Feature/Plural%20Entries
Summary:
* We [IBM] do not think anything needs to be done for core.
* A module (non-core) feature could include embedding pluralization rules.
-----------------
We also discussed this issue.
However, we think that this would not be a core XLIFF feature.
The approach of using specialized (app dependent) syntax works without any explicit support from XLIFF. However, the ChoiceFormat structure mentioned below is NOT sufficient for real language plurals. Instead we would use the ICU format, as below:
There {num_files,plural, one{is one file} other{are # files}}.
Or better yet, have the sentence duplicated (easier to translate, and programmatically split/join):
{num_files,plural, one{There is one file.} other{There are # files.}}
which an editor could split to:
(one:) There is one file.
(other:) There are # files.
where "one" and "other" are defined
One thought was to include the cases in the XLIFF file itself. The " cases for different languages are documented" as was noted, however, these are (like any locale dependent data) changeable over time. So the cases could be embedded for consistency downstream.
This would be a module feature though, and not core.
References:
https://docs.google.com/present/view?id=ddsrrpj5_68gkkvv6hs - presentation on inadequacy of ChoiceFormat
http://cldr.unicode.org/index/cldr-spec/plural-rules - CLDR plural rules
Andrew Pimlott ---01/10/2012 01:25:52 PM---You're right, I misunderstood how this worked. So it looks like this approach would work with no sp
From: Andrew Pimlott <andrew@spartanconsultinginc.com>
To: David Walters/Rochester/IBM@IBMUS,
Cc: "Rodolfo M. Raya" <rmraya@maxprograms.com>, xliff@lists.oasis-open.org
Date: 01/10/2012 01:25 PM
Subject: Re: [xliff] Plural forms and XLIFF
Sent by: <xliff@lists.oasis-open.org>
Getting:
from :
key2=Folder {0} contains {1,choice,0#no files|1#one file|1<{2,number,integer} files}.
is something that belongs to extraction tools domain, not to XLIFF 2.0 standard. A perfect filter for Java .properties files should be able to parse the _expression_ and generate three segments from the given key.
The elements we have defined so far for XLIFF 2.0 can handle very well the representation of those 3 segments inside a <unit> element.
The specification for XLIFF 2.0 doesn’t need to cover handling plurals in Java .properties files. This is something that could be covered in a best practices document after XLIFF 2.0 is published.
Regards,
Rodolfo
--
Rodolfo M. Raya rmraya@maxprograms.com
Maxprograms
http://www.maxprograms.com
From: xliff@lists.oasis-open.org [mailto:xliff@lists.oasis-open.org] On Behalf Of David Walters
Sent: Tuesday, January 10, 2012 4:54 PM
To: Rodolfo M. Raya
Cc: xliff@lists.oasis-open.org
Subject: RE: [xliff] Plural forms and XLIFF
The "XLIFF 1.2 Representation Guide for Java Resource Bundles" (http://docs.oasis-open.org/xliff/v1.2/xliff-profile-java/xliff-profile-java-v1.2-cd02.html) has this PropertyResourceBundle example:
Hi again,
Plurals in Java .properties files can be handled via subflows. The proposed mechanism that you included in the specification draft is fine for me.
Plurals in PO files are rare; files that use plural forms are a very small minority in a Linux distribution. They can be handled properly in XLIFF 1.2 and support for this feature has been implemented in XLIFF 1.2 based tools.
Linux developers have not opted for using XLIFF in their localization workflow. They still rely on PO and the myriad of free tools that handle PO, including plurals. I don't expect Linux localization workflow to be based on PO -> XLIFF 2.0 -> PO transformations.
IMHO, I would not include support for plural forms in XLIFF 2.0. Those that need it can keep using XLIFF 1.2.
Regards,
Rodolfo
--
Rodolfo M. Raya
Maxprograms http://www.maxprograms.com
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]