OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

xliff message

[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


Inactive hide details for Andrew Pimlott ---01/10/2012 01:25:52 PM---You're right, I misunderstood how this worked.  So it lookAndrew 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>





You're right, I misunderstood how this worked.  So it looks like this approach would work with no special support from XLIFF, with a few drawbacks:

- Translators have to enter some duplicate text ("Folder") between the cases.  On the other hand, they also have more control, as they can adjust text outside of the {choice} to suit each case if necessary.

- Translator can't add additional cases to accommodate the target language.  The filter needs to know ahead of time what cases to use.  That's not a show-stopper, because the cases for different languages are documented.

- Translators can't easily see which case is which.  This may not be a problem if they are always presented in a conventional order, from fewest to most.  Also, you could give a 

Do I have this right?  I think I like Rodolfo's position that plurals don't require special support in XLIFF 2.0.  Do you have some case where it's really necessary?

Andrew

On Tue, Jan 10, 2012 at 12:12 PM, David Walters <waltersd@us.ibm.com> wrote:



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]