From mark at macchiato.com Mon Feb 22 01:59:26 2016 From: mark at macchiato.com (=?UTF-8?B?TWFyayBEYXZpcyDimJXvuI8=?=) Date: Mon, 22 Feb 2016 08:59:26 +0100 Subject: CLDR v29 Beta available for review Message-ID: The CLDR v29 beta is available for review. Information on the release and a summary of the main changes are available at http://cldr.unicode.org/index/downloads/cldr-29. Mark -------------- next part -------------- An HTML attachment was scrubbed... URL: From greenmr at gmail.com Fri Feb 26 14:11:18 2016 From: greenmr at gmail.com (Martin Green) Date: Fri, 26 Feb 2016 15:11:18 -0500 Subject: Confusion about Significant Digits patterns Message-ID: <56D0B166.3000708@gmail.com> The Unicode LDMR reference says this about Significant Digits patterns: "Any number of '#' characters may be prepended to the left of the leftmost '@' character. These have no effect on the minimum and maximum significant digits counts, but may be used to position grouping separators. For example, "#,#@#" indicates a minimum of one significant digits, a maximum of two significant digits, and a grouping size of three." I'm not sure I understand this, but I read this example pattern to mean that 1234 would be formatted as "1,200" Is this correct? Thanks. -------------- next part -------------- An HTML attachment was scrubbed... URL: From greenmr at gmail.com Fri Feb 26 14:52:51 2016 From: greenmr at gmail.com (Martin Green) Date: Fri, 26 Feb 2016 15:52:51 -0500 Subject: Confusion about Significant Digits patterns (cont...) Message-ID: <56D0BB23.7000803@gmail.com> I forgot to ask the second half of my question... The example I referenced from the Unicode LDMR reference used the pattern ""#,#@#"". Is "#,##@,@##" a valid patterm format too, and if so, does it mean that 1234567 would be formatted as "1,234,000"? Thanks. From greenmr at gmail.com Fri Feb 26 15:13:27 2016 From: greenmr at gmail.com (Martin Green) Date: Fri, 26 Feb 2016 16:13:27 -0500 Subject: Scientific Notation question Message-ID: <56D0BFF7.8020308@gmail.com> Unicode LDMR reference says this about Scientific Notation patterns: * When using scientific notation, the formatter controls the digit counts using significant digits logic. The maximum number of significant digits limits the total number of integer and fraction digits that will be shown in the mantissa; it does not affect parsing. For example, 12345 formatted with "##0.##E0" is "12.3E3". See the section on significant digits for more details. I don't understand how they arrive at this. From the result of "12.3E3" I assume they have determined the maximum significant digits in the pattern to be three, but I just don't see that. My expectation would be that "##0.##E0" would format 12345 as "123E2". The only thing I can think of is that perhaps scientific notation MUST have a fractional part, which would mean that the result for "E2" would be "123.0E2" which is FOUR significant digits. Since I don't see what made them decide there can only be three significant digits I don't get why "123.0E2" would be an invalid result. What am I missing? -------------- next part -------------- An HTML attachment was scrubbed... URL: From greenmr at gmail.com Fri Feb 26 15:13:27 2016 From: greenmr at gmail.com (Martin Green) Date: Fri, 26 Feb 2016 16:13:27 -0500 Subject: Scientific Notation question Message-ID: <56D0BFF7.8020308@gmail.com> Unicode LDMR reference says this about Scientific Notation patterns: * When using scientific notation, the formatter controls the digit counts using significant digits logic. The maximum number of significant digits limits the total number of integer and fraction digits that will be shown in the mantissa; it does not affect parsing. For example, 12345 formatted with "##0.##E0" is "12.3E3". See the section on significant digits for more details. I don't understand how they arrive at this. From the result of "12.3E3" I assume they have determined the maximum significant digits in the pattern to be three, but I just don't see that. My expectation would be that "##0.##E0" would format 12345 as "123E2". The only thing I can think of is that perhaps scientific notation MUST have a fractional part, which would mean that the result for "E2" would be "123.0E2" which is FOUR significant digits. Since I don't see what made them decide there can only be three significant digits I don't get why "123.0E2" would be an invalid result. What am I missing? -------------- next part -------------- An HTML attachment was scrubbed... URL: From felipe at felipegasper.com Sat Feb 27 19:17:08 2016 From: felipe at felipegasper.com (Felipe Gasper) Date: Sat, 27 Feb 2016 19:17:08 -0600 Subject: Ordinal endings Message-ID: <56D24A94.6030600@felipegasper.com> Hello, I?m wanting to make a function that takes in an integer and a locale tag and spits out the ordinal form of that integer in the given locale. For example: to_ordinal( 5, 'en' ) => '5th', to_ordinal( 1, 'fr' ) => '1er', I know this is tricky because in many cases (e.g., the second example that I posted!) the ordinal form will depend on more context--for example, in French it could be (something like) ?1er? or ?1?re?. Only English seems to have the actual text of the ordinal endings in CLDR ? is that because there are but few languages whose ordinal forms are simple enough to require no additional context? Thank you! -Felipe Gasper Houston, TX From mark at macchiato.com Sun Feb 28 14:16:38 2016 From: mark at macchiato.com (=?UTF-8?B?TWFyayBEYXZpcyDimJXvuI8=?=) Date: Sun, 28 Feb 2016 21:16:38 +0100 Subject: Ordinal endings In-Reply-To: <56D24A94.6030600@felipegasper.com> References: <56D24A94.6030600@felipegasper.com> Message-ID: The primary function of the ordinal categories is to be used as "switch" selectors in messages, where the UI supplies the whole message with the ending (as you mention) that is appropriate for the . CLDR doesn't supply text for "1st", "2nd", etc for languages precisely for the reason you mention; the inflections vary by the rest of the sentence. There are RBNF ordinal rules for some languages, but the RBNF rules are not complete for all languages; and for some languages that have them, they are not complete for all of the inflected forms. Mark On Sun, Feb 28, 2016 at 2:17 AM, Felipe Gasper wrote: > Hello, > > I?m wanting to make a function that takes in an integer and a > locale tag and spits out the ordinal form of that integer in the given > locale. For example: > > to_ordinal( 5, 'en' ) => '5th', > to_ordinal( 1, 'fr' ) => '1er', > > I know this is tricky because in many cases (e.g., the second > example that I posted!) the ordinal form will depend on more context--for > example, in French it could be (something like) ?1er? or ?1?re?. > > Only English seems to have the actual text of the ordinal endings > in CLDR ? is that because there are but few languages whose ordinal forms > are simple enough to require no additional context? > > Thank you! > > -Felipe Gasper > Houston, TX > _______________________________________________ > CLDR-Users mailing list > CLDR-Users at unicode.org > http://unicode.org/mailman/listinfo/cldr-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From verdy_p at wanadoo.fr Sun Feb 28 15:49:39 2016 From: verdy_p at wanadoo.fr (Philippe Verdy) Date: Sun, 28 Feb 2016 22:49:39 +0100 Subject: Ordinal endings In-Reply-To: <56D24A94.6030600@felipegasper.com> References: <56D24A94.6030600@felipegasper.com> Message-ID: For the feminine French form of "1er" the recommended typography is "1re" not "1?re" (actually with the suffix "re" in superscript style). Same remark about "2?me" (deuxi?me) preferably "2e", except when this this the second and **last** in a pair, in which case the translation is "second(e)" and the abbreviation is "2nd" or "2de", not to be used if there are more than two items in the series; example : "Seconde Guerre mondiale" and not "Deuxi?me Guerre mondiale", with the expressed hope this is the last World War... [But we've already heard in various medias that the current situation in the Middle East is already now a Third World War as it involves so many countries of the world and the conflict has already spread in various forms through all continents and has already impacted the politics and public freedoms in many countries, with active deployment of armies in everyday civil life all around the world...]. These are cases where many people (including you visibly) don't know the recommendations and may use alternate abbreviations or the incorrect term. 2016-02-28 2:17 GMT+01:00 Felipe Gasper : > Hello, > > I?m wanting to make a function that takes in an integer and a > locale tag and spits out the ordinal form of that integer in the given > locale. For example: > > to_ordinal( 5, 'en' ) => '5th', > to_ordinal( 1, 'fr' ) => '1er', > > I know this is tricky because in many cases (e.g., the second > example that I posted!) the ordinal form will depend on more context--for > example, in French it could be (something like) ?1er? or ?1?re?. > > Only English seems to have the actual text of the ordinal endings > in CLDR ? is that because there are but few languages whose ordinal forms > are simple enough to require no additional context? > > Thank you! > > -Felipe Gasper > Houston, TX > _______________________________________________ > CLDR-Users mailing list > CLDR-Users at unicode.org > http://unicode.org/mailman/listinfo/cldr-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kent.karlsson14 at telia.com Sun Feb 28 15:51:37 2016 From: kent.karlsson14 at telia.com (Kent Karlsson) Date: Sun, 28 Feb 2016 22:51:37 +0100 Subject: Ordinal endings In-Reply-To: Message-ID: Den 2016-02-28 21:16, skrev "Mark Davis" : > There are RBNF ordinal rules for some languages, but the RBNF rules are not > complete for all languages; and for some languages that have them, they are > not complete for all of the inflected forms. For the short form of ordinals, many languages "duck" that and just put a period after the sequence of digits. That is why that form (".") of short ordinals is default (in root locale) in CLDR/RBNF. /Kent Karlsson -------------- next part -------------- An HTML attachment was scrubbed... URL: