OASIS XML Localisation Interchange File Format (XLIFF) TC

  • 1.  RE: [xliff] Plural forms and XLIFF

    Posted 01-10-2012 17:55
    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    


  • 2.  RE: [xliff] Plural forms and XLIFF

    Posted 01-10-2012 19:00
    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: PRB: key2=Folder {0} contains {1,choice,0#no files 1#one file 1<{2,number,integer} files}. XLIFF (2 options): <source>Folder <ph id="1">{0}</ph> contains <ph id="2">{1,choice,0#<sub>no files</sub>     1#<sub>one file</sub> 1&lt;<sub>{2,number,integer} files</sub>}</ph>. </source> <source>Folder <ph id="1">{0}</ph> contains    <ph id="2">{1,choice,<sub>0#no files 1#one file 1&lt;{2,number,integer} files</sub>}</ph>. </source> I would expect that the proper way to translate this would be as 3 separate segments: Folder {0} contains no files. Folder {0} contains one file. Folder {0} contains {2,number,integer} files. Some languages would need a different number of segments to translate based on their CLDR "Language Plural Rules" ( http://unicode.org/repos/cldr-tmp/trunk/diff/supplemental/language_plural_rules.html ). In the 1st XLIFF example, the translator would basically be translating these words as separate segments, especially if the subflow text were defined as separate <trans-unit> elements. Folder {0} contains no files one file {2,number,integer} files . In the 2nd XLIFF example, I doubt that a translator would be technical enough to handle this subflow text since it is a mixture of code and text:   <sub>0#no files 1#one file 1&lt;{2,number,integer} files</sub> Handling plural situations was important enough that Android XML created unique support (see http://developer.android.com/guide/topics/resources/string-resource.html#Plurals ).  So XLIFF 2.0 should probably consider how plurals could be handled in the future. David Corporate Globalization Tool Development EMail:  waltersd@us.ibm.com           Phone: (507) 253-7278,   T/L:553-7278,   Fax: (507) 253-1721 CHKPII:                     http://w3-03.ibm.com/globalization/page/2011 TM file formats:     http://w3-03.ibm.com/globalization/page/2083 TM markups:         http://w3-03.ibm.com/globalization/page/2071 "Rodolfo M. Raya" ---01/10/2012 11:56:02 AM---Hi again,   Plurals in Java .properties files can be handled via subflows. The proposed mechanism th From: "Rodolfo M. Raya" <rmraya@maxprograms.com> To: xliff@lists.oasis-open.org Date: 01/10/2012 11:56 AM Subject: RE: [xliff] Plural forms and XLIFF Sent by: <xliff@lists.oasis-open.org> 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    


  • 3.  RE: [xliff] Plural forms and XLIFF

    Posted 01-10-2012 19:23
    Hi David,   Getting:   Folder {0} contains no files. Folder {0} contains one file. Folder {0} contains {2,number,integer} files.   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: PRB: key2=Folder {0} contains {1,choice,0#no files 1#one file 1<{2,number,integer} files}. XLIFF (2 options): <source>Folder <ph id="1">{0}</ph> contains <ph id="2">{1,choice,0#<sub>no files</sub>     1#<sub>one file</sub> 1&lt;<sub>{2,number,integer} files</sub>}</ph>. </source> <source>Folder <ph id="1">{0}</ph> contains    <ph id="2">{1,choice,<sub>0#no files 1#one file 1&lt;{2,number,integer} files</sub>}</ph>. </source> I would expect that the proper way to translate this would be as 3 separate segments: Folder {0} contains no files. Folder {0} contains one file. Folder {0} contains {2,number,integer} files. Some languages would need a different number of segments to translate based on their CLDR "Language Plural Rules" ( http://unicode.org/repos/cldr-tmp/trunk/diff/supplemental/language_plural_rules.html ). In the 1st XLIFF example, the translator would basically be translating these words as separate segments, especially if the subflow text were defined as separate <trans-unit> elements. Folder {0} contains no files one file {2,number,integer} files . In the 2nd XLIFF example, I doubt that a translator would be technical enough to handle this subflow text since it is a mixture of code and text:   <sub>0#no files 1#one file 1&lt;{2,number,integer} files</sub> Handling plural situations was important enough that Android XML created unique support (see http://developer.android.com/guide/topics/resources/string-resource.html#Plurals ).  So XLIFF 2.0 should probably consider how plurals could be handled in the future. David Corporate Globalization Tool Development EMail:  waltersd@us.ibm.com           Phone: (507) 253-7278,   T/L:553-7278,   Fax: (507) 253-1721 CHKPII:                     http://w3-03.ibm.com/globalization/page/2011 TM file formats:     http://w3-03.ibm.com/globalization/page/2083 TM markups:         http://w3-03.ibm.com/globalization/page/2071 "Rodolfo M. Raya" ---01/10/2012 11:56:02 AM---Hi again,   Plurals in Java .properties files can be handled via subflows. The proposed mechanism th From: "Rodolfo M. Raya" <rmraya@maxprograms.com> To: xliff@lists.oasis-open.org Date: 01/10/2012 11:56 AM Subject: RE: [xliff] Plural forms and XLIFF Sent by: <xliff@lists.oasis-open.org> 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    


  • 4.  Re: [xliff] Plural forms and XLIFF

    Posted 01-10-2012 19:50
    On Tue, Jan 10, 2012 at 11:22 AM, Rodolfo M. Raya  < rmraya@maxprograms.com >  wrote: Folder {0} contains no files. Folder {0} contains one file. Folder {0} contains {2,number,integer} files.   David, Rodolfo, I don't think this approach actually works.  After these three segments are translated, you need to produce a single java properties resource that correctly encodes the three possibilities.  How would you do this? source .properties file: key2=Folder {0} contains {1,choice,0#no files 1#one file 1<{2,number,integer} files}. -> source XLIFF -> translated XLIFF -> target .properties file: key2=??? Andrew On Tue, Jan 10, 2012 at 11:22 AM, Rodolfo M. Raya < rmraya@maxprograms.com > wrote: Hi David,   Getting:   Folder {0} contains no files. Folder {0} contains one file. Folder {0} contains {2,number,integer} files.   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: PRB: key2=Folder {0} contains {1,choice,0#no files 1#one file 1<{2,number,integer} files}. XLIFF (2 options): <source>Folder <ph id="1">{0}</ph> contains <ph id="2">{1,choice,0#<sub>no files</sub>     1#<sub>one file</sub> 1&lt;<sub>{2,number,integer} files</sub>}</ph>. </source> <source>Folder <ph id="1">{0}</ph> contains    <ph id="2">{1,choice,<sub>0#no files 1#one file 1&lt;{2,number,integer} files</sub>}</ph>. </source> I would expect that the proper way to translate this would be as 3 separate segments: Folder {0} contains no files. Folder {0} contains one file. Folder {0} contains {2,number,integer} files. Some languages would need a different number of segments to translate based on their CLDR "Language Plural Rules" ( http://unicode.org/repos/cldr-tmp/trunk/diff/supplemental/language_plural_rules.html ). In the 1st XLIFF example, the translator would basically be translating these words as separate segments, especially if the subflow text were defined as separate <trans-unit> elements. Folder {0} contains no files one file {2,number,integer} files . In the 2nd XLIFF example, I doubt that a translator would be technical enough to handle this subflow text since it is a mixture of code and text:   <sub>0#no files 1#one file 1&lt;{2,number,integer} files</sub> Handling plural situations was important enough that Android XML created unique support (see http://developer.android.com/guide/topics/resources/string-resource.html#Plurals ).  So XLIFF 2.0 should probably consider how plurals could be handled in the future. David Corporate Globalization Tool Development EMail:   waltersd@us.ibm.com           Phone: (507) 253-7278 ,   T/L:553-7278,   Fax: (507) 253-1721 CHKPII:                     http://w3-03.ibm.com/globalization/page/2011 TM file formats:     http://w3-03.ibm.com/globalization/page/2083 TM markups:         http://w3-03.ibm.com/globalization/page/2071 "Rodolfo M. Raya" ---01/10/2012 11:56:02 AM---Hi again,   Plurals in Java .properties files can be handled via subflows. The proposed mechanism th From: "Rodolfo M. Raya" < rmraya@maxprograms.com > To: xliff@lists.oasis-open.org Date: 01/10/2012 11:56 AM Subject: RE: [xliff] Plural forms and XLIFF Sent by: < xliff@lists.oasis-open.org > 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    


  • 5.  Re: [xliff] Plural forms and XLIFF

    Posted 01-10-2012 20:14

    The target property file would have to contain:

    key2={1,choice,0#Folder {0} contains no files. 1#Folder {0} contains one file. 1<Folder {0} contains {1,number,integer} files.}


    David

    Corporate Globalization Tool Development
    EMail:  waltersd@us.ibm.com          
    Phone: (507) 253-7278,   T/L:553-7278,   Fax: (507) 253-1721

    CHKPII:                     http://w3-03.ibm.com/globalization/page/2011
    TM file formats:     http://w3-03.ibm.com/globalization/page/2083
    TM markups:         http://w3-03.ibm.com/globalization/page/2071


    Andrew Pimlott ---01/10/2012 01:53:32 PM---On Tue, Jan 10, 2012 at 11:22 AM, Rodolfo M. Raya <rmraya@maxprograms.com>  wrote:

    From: Andrew Pimlott <andrew@spartanconsultinginc.com>
    To: "Rodolfo M. Raya" <rmraya@maxprograms.com>
    Cc: xliff@lists.oasis-open.org
    Date: 01/10/2012 01:53 PM
    Subject: Re: [xliff] Plural forms and XLIFF
    Sent by: <xliff@lists.oasis-open.org>



    On Tue, Jan 10, 2012 at 11:22 AM, Rodolfo M. Raya < rmraya@maxprograms.com > wrote:

    Folder {0} contains no files.
    Folder {0} contains one file.
    Folder {0} contains {2,number,integer} files.

     
    David, Rodolfo,

    I don't think this approach actually works.  After these three segments are translated, you need to produce a single java properties resource that correctly encodes the three possibilities.  How would you do this?

    source .properties file:

    key2=Folder {0} contains {1,choice,0#no files 1#one file 1<{1,number,integer} files}.

    -> source XLIFF -> translated XLIFF -> target .properties file:

    key2=???

    Andrew

    On Tue, Jan 10, 2012 at 11:22 AM, Rodolfo M. Raya < rmraya@maxprograms.com > wrote:
    Hi David,
     
    Getting:
     

    Folder {0} contains no files.
    Folder {0} contains one file.
    Folder {0} contains {2,number,integer} files.

     
    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:  


    PRB:  
    key2=Folder {0} contains {1,choice,0#no files 1#one file 1<{2,number,integer} files}.

    XLIFF (2 options):  

    <source>Folder <ph id="1">{0}</ph> contains <ph id="2">{1,choice,0#<sub>no files</sub>
        1#<sub>one file</sub> 1&lt;<sub>{2,number,integer} files</sub>}</ph>.
    </source>

    <source>Folder <ph id="1">{0}</ph> contains
       <ph id="2">{1,choice,<sub>0#no files 1#one file 1&lt;{2,number,integer} files</sub>}</ph>.
    </source>


    I would expect that the proper way to translate this would be as 3 separate segments:

    Folder {0} contains no files.
    Folder {0} contains one file.
    Folder {0} contains {2,number,integer} files.


    Some languages would need a different number of segments to translate based on their CLDR "Language Plural Rules" ( http://unicode.org/repos/cldr-tmp/trunk/diff/supplemental/language_plural_rules.html ).


    In the 1st XLIFF example, the translator would basically be translating these words as separate segments, especially if the subflow text were defined as separate <trans-unit> elements.

    Folder {0} contains
    no files
    one file
    {2,number,integer} files
    .


    In the 2nd XLIFF example, I doubt that a translator would be technical enough to handle this subflow text since it is a mixture of code and text:   <sub>0#no files 1#one file 1&lt;{2,number,integer} files</sub>


    Handling plural situations was important enough that Android XML created unique support (see http://developer.android.com/guide/topics/resources/string-resource.html#Plurals ).  So XLIFF 2.0 should probably consider how plurals could be handled in the future.


    David

    Corporate Globalization Tool Development
    EMail:   waltersd@us.ibm.com           
    Phone: (507) 253-7278 ,   T/L:553-7278,   Fax: (507) 253-1721

    CHKPII:                     http://w3-03.ibm.com/globalization/page/2011
    TM file formats:     http://w3-03.ibm.com/globalization/page/2083
    TM markups:         http://w3-03.ibm.com/globalization/page/2071


    "Rodolfo M. Raya" ---01/10/2012 11:56:02 AM---Hi again,   Plurals in Java .properties files can be handled via subflows. The proposed mechanism th

    From: "Rodolfo M. Raya" < rmraya@maxprograms.com >
    To: xliff@lists.oasis-open.org
    Date: 01/10/2012 11:56 AM
    Subject: RE: [xliff] Plural forms and XLIFF
    Sent by: < xliff@lists.oasis-open.org >




    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
     
       




  • 6.  Re: [xliff] Plural forms and XLIFF

    Posted 01-10-2012 21:23
    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: The target property file would have to contain: key2={1,choice,0#Folder {0} contains no files. 1#Folder {0} contains one file. 1<Folder {0} contains {1,number,integer} files.} David Corporate Globalization Tool Development EMail:   waltersd@us.ibm.com           Phone: (507) 253-7278 ,   T/L:553-7278,   Fax: (507) 253-1721 CHKPII:                     http://w3-03.ibm.com/globalization/page/2011 TM file formats:     http://w3-03.ibm.com/globalization/page/2083 TM markups:         http://w3-03.ibm.com/globalization/page/2071 Andrew Pimlott ---01/10/2012 01:53:32 PM---On Tue, Jan 10, 2012 at 11:22 AM, Rodolfo M. Raya < rmraya@maxprograms.com >  wrote: From: Andrew Pimlott < andrew@spartanconsultinginc.com > To: "Rodolfo M. Raya" < rmraya@maxprograms.com > Cc: xliff@lists.oasis-open.org Date: 01/10/2012 01:53 PM Subject: Re: [xliff] Plural forms and XLIFF Sent by: < xliff@lists.oasis-open.org > On Tue, Jan 10, 2012 at 11:22 AM, Rodolfo M. Raya < rmraya@maxprograms.com > wrote: Folder {0} contains no files. Folder {0} contains one file. Folder {0} contains {2,number,integer} files.   David, Rodolfo, I don't think this approach actually works.  After these three segments are translated, you need to produce a single java properties resource that correctly encodes the three possibilities.  How would you do this? source .properties file: key2=Folder {0} contains {1,choice,0#no files 1#one file 1<{1,number,integer} files}. -> source XLIFF -> translated XLIFF -> target .properties file: key2=??? Andrew On Tue, Jan 10, 2012 at 11:22 AM, Rodolfo M. Raya < rmraya@maxprograms.com > wrote: Hi David,   Getting:   Folder {0} contains no files. Folder {0} contains one file. Folder {0} contains {2,number,integer} files.   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:   PRB:   key2=Folder {0} contains {1,choice,0#no files 1#one file 1<{2,number,integer} files}. XLIFF (2 options):   <source>Folder <ph id="1">{0}</ph> contains <ph id="2">{1,choice,0#<sub>no files</sub>     1#<sub>one file</sub> 1&lt;<sub>{2,number,integer} files</sub>}</ph>. </source> <source>Folder <ph id="1">{0}</ph> contains    <ph id="2">{1,choice,<sub>0#no files 1#one file 1&lt;{2,number,integer} files</sub>}</ph>. </source> I would expect that the proper way to translate this would be as 3 separate segments: Folder {0} contains no files. Folder {0} contains one file. Folder {0} contains {2,number,integer} files. Some languages would need a different number of segments to translate based on their CLDR "Language Plural Rules" ( http://unicode.org/repos/cldr-tmp/trunk/diff/supplemental/language_plural_rules.html ). In the 1st XLIFF example, the translator would basically be translating these words as separate segments, especially if the subflow text were defined as separate <trans-unit> elements. Folder {0} contains no files one file {2,number,integer} files . In the 2nd XLIFF example, I doubt that a translator would be technical enough to handle this subflow text since it is a mixture of code and text:   <sub>0#no files 1#one file 1&lt;{2,number,integer} files</sub> Handling plural situations was important enough that Android XML created unique support (see http://developer.android.com/guide/topics/resources/string-resource.html#Plurals ).  So XLIFF 2.0 should probably consider how plurals could be handled in the future. David Corporate Globalization Tool Development EMail:   waltersd@us.ibm.com            Phone: (507) 253-7278 ,   T/L:553-7278,   Fax: (507) 253-1721 CHKPII:                     http://w3-03.ibm.com/globalization/page/2011 TM file formats:     http://w3-03.ibm.com/globalization/page/2083 TM markups:         http://w3-03.ibm.com/globalization/page/2071 "Rodolfo M. Raya" ---01/10/2012 11:56:02 AM---Hi again,   Plurals in Java .properties files can be handled via subflows. The proposed mechanism th From: "Rodolfo M. Raya" < rmraya@maxprograms.com > To: xliff@lists.oasis-open.org Date: 01/10/2012 11:56 AM Subject: RE: [xliff] Plural forms and XLIFF Sent by: < xliff@lists.oasis-open.org > 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      


  • 7.  Re: [xliff] Plural forms and XLIFF

    Posted 09-14-2012 19:12

    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>



    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:
    The target property file would have to contain:

    key2={1,choice,0#Folder {0} contains no files. 1#Folder {0} contains one file. 1<Folder {0} contains {1,number,integer} files.}


    David

    Corporate Globalization Tool Development
    EMail:   waltersd@us.ibm.com           
    Phone: (507) 253-7278 ,   T/L:553-7278,   Fax: (507) 253-1721

    CHKPII:                     http://w3-03.ibm.com/globalization/page/2011
    TM file formats:     http://w3-03.ibm.com/globalization/page/2083
    TM markups:         http://w3-03.ibm.com/globalization/page/2071


    Andrew Pimlott ---01/10/2012 01:53:32 PM---On Tue, Jan 10, 2012 at 11:22 AM, Rodolfo M. Raya < rmraya@maxprograms.com >  wrote:

    From: Andrew Pimlott < andrew@spartanconsultinginc.com >

    To: "Rodolfo M. Raya" < rmraya@maxprograms.com >
    Cc: xliff@lists.oasis-open.org
    Date: 01/10/2012 01:53 PM
    Subject: Re: [xliff] Plural forms and XLIFF
    Sent by: < xliff@lists.oasis-open.org >



    On Tue, Jan 10, 2012 at 11:22 AM, Rodolfo M. Raya < rmraya@maxprograms.com > wrote:

    Folder {0} contains no files.
    Folder {0} contains one file.
    Folder {0} contains {2,number,integer} files.

     
    David, Rodolfo,

    I don't think this approach actually works.  After these three segments are translated, you need to produce a single java properties resource that correctly encodes the three possibilities.  How would you do this?

    source .properties file:
    key2=Folder {0} contains {1,choice,0#no files 1#one file 1<{1,number,integer} files}.

    -> source XLIFF -> translated XLIFF -> target .properties file:
    key2=???

    Andrew

    On Tue, Jan 10, 2012 at 11:22 AM, Rodolfo M. Raya < rmraya@maxprograms.com > wrote:
    Hi David,  
       
    Getting:
       


    Folder {0} contains no files.
    Folder {0} contains one file.
    Folder {0} contains {2,number,integer} files.

       
    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:  



    PRB:  
    key2=Folder {0} contains {1,choice,0#no files 1#one file 1<{2,number,integer} files}.

    XLIFF (2 options):    

    <source>Folder <ph id="1">{0}</ph> contains <ph id="2">{1,choice,0#<sub>no files</sub>
        1#<sub>one file</sub> 1&lt;<sub>{2,number,integer} files</sub>}</ph>.
    </source>

    <source>Folder <ph id="1">{0}</ph> contains
       <ph id="2">{1,choice,<sub>0#no files 1#one file 1&lt;{2,number,integer} files</sub>}</ph>.
    </source>


    I would expect that the proper way to translate this would be as 3 separate segments:  

    Folder {0} contains no files.
    Folder {0} contains one file.
    Folder {0} contains {2,number,integer} files.


    Some languages would need a different number of segments to translate based on their CLDR "Language Plural Rules" ( http://unicode.org/repos/cldr-tmp/trunk/diff/supplemental/language_plural_rules.html ).


    In the 1st XLIFF example, the translator would basically be translating these words as separate segments, especially if the subflow text were defined as separate <trans-unit> elements.  

    Folder {0} contains
    no files
    one file
    {2,number,integer} files
    .


    In the 2nd XLIFF example, I doubt that a translator would be technical enough to handle this subflow text since it is a mixture of code and text:   <sub>0#no files 1#one file 1&lt;{2,number,integer} files</sub>


    Handling plural situations was important enough that Android XML created unique support (see http://developer.android.com/guide/topics/resources/string-resource.html#Plurals ).  So XLIFF 2.0 should probably consider how plurals could be handled in the future.


    David

    Corporate Globalization Tool Development
    EMail:   waltersd@us.ibm.com           
    Phone: (507) 253-7278 ,   T/L:553-7278,   Fax: (507) 253-1721

    CHKPII:                     http://w3-03.ibm.com/globalization/page/2011
    TM file formats:     http://w3-03.ibm.com/globalization/page/2083
    TM markups:         http://w3-03.ibm.com/globalization/page/2071


    "Rodolfo M. Raya" ---01/10/2012 11:56:02 AM---Hi again,   Plurals in Java .properties files can be handled via subflows. The proposed mechanism th

    From: "Rodolfo M. Raya" < rmraya@maxprograms.com >
    To: xliff@lists.oasis-open.org
    Date: 01/10/2012 11:56 AM
    Subject: RE: [xliff] Plural forms and XLIFF
    Sent by: < xliff@lists.oasis-open.org >  




    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