From srl at icu-project.org Sat Nov 1 23:57:06 2014 From: srl at icu-project.org (Steven R. Loomis) Date: Sat, 01 Nov 2014 21:57:06 -0700 Subject: Looking for a standard on historical countries In-Reply-To: <20141101151050.48c4a871@JRWUBU2> References: <20141101151050.48c4a871@JRWUBU2> Message-ID: <5455B9A2.9030903@icu-project.org> On 11/1/2014 8:10 AM, Richard Wordingham wrote: > On Fri, 31 Oct 2014 20:43:19 +0100 > Philippe Verdy wrote: > >> How is ths related to Unicode ? > One possibility is though the Regional Indicators, but they are defined > by the unstable ISO 3166-1 alpha-2 codes. It was noted as "off topic". It.s relevant because CLDR is relevant. >> May be it's associated to CLDR for former regional classifcation of >> languages, but I doubt this will ever create any standardization for >> historic data that should remain as is without changes in their old >> sources for which there are no more any active maintainers, just >> interested people (basically historians that may comment about them >> the way they want or could invent their new terminology for analysts >> and archivists). > A lot of useful historic information is missing from CLDR. For example, > I believe line-breaking and word-boundary rules are completely missing > for 'Sumero-Akkadian' Cuneiform writing systems. The rules were not > uniform. On the other hand, an entry for the Assyrian for 'English' as > used in the Assyrian homeland would be meaningless. A lot of speculation happened some time back with the assumption that CLDR would a priori reject historic language contributions such as Latin (it wouldn't). Zero bugs were even filed, let alone any data submitted for Latin. Besides Sumero-Akkadian, we could probably add break rules for, say, Oromo, Slovak, Spanish, and Dutch ( http://unicode.org/cldr/trac/ticket/2992 ). > The precise territory covered by a country is not useful within the > Unicode domains, nor are debates about independence, nor whether tribute > was paid regularly. In general, a more useful division may be by date, > but that is barely covered by a system designed for present-day > languages. Sure. It would need to be a differnet namespace from ISO-3166 and probably IETF BCP 47. I wonder if you could use Linked Open Data sets (come hear about it Monday at IUC38!) to look for ontology/Country that doesn't have a 3166 code, something like the following. You could extract start/end date, successor country, etc. > If this thread is of to be of any immediate use, what is the intended > use of the information? The original post made it sound like it was related to book publishing. "all countries where there was a printing press would be optimal coverage". -s -- IBMer but all opinions are mine. // GPG: 9731166CD8E23A83BEE7C6D3ACA5DBE1FD8FABF1 https://www.ohloh.net/accounts/srl295 // https://ssl.icu-project.org/trac/wiki/Srl -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: OpenPGP digital signature URL: From isaac.jurado at roiback.com Wed Nov 5 16:21:51 2014 From: isaac.jurado at roiback.com (Isaac Jurado) Date: Wed, 5 Nov 2014 23:21:51 +0100 Subject: Currency patterns and fraction information Message-ID: Hello, First of all, I want to apologize in advance just in case my question is too dumb. My question is about currency formatting and decimal places. Most of the locale definitions use a currency pattern that ends with "0.00". This means that, at least, one integer and two decimal digits will be printed along with its decimal separator. However, the supplemental data contains information about decimal digits usage and rounding policies [1, 2]. For those currencies that do not use decimals at all (a.g. COP, the obsolete ESP, JPY, etc.), the currency format pattern still forces a decimal separator followed by two zeroes to be "printed". Is that considered an implementation mistake or the element is completely unrelated to the currency pattern. In other words, is there any implementation deriving from CLDR that makes use of fraction information when formatting a currency value? Thank you. [1] http://www.unicode.org/cldr/charts/26/supplemental/detailed_territory_currency_information.html#format_info [2] http://unicode.org/repos/cldr/trunk/common/supplemental/supplementalData.xml -- Isaac Jurado From mark at macchiato.com Fri Nov 7 09:52:10 2014 From: mark at macchiato.com (=?UTF-8?B?TWFyayBEYXZpcyDimJXvuI8=?=) Date: Fri, 7 Nov 2014 07:52:10 -0800 Subject: Currency patterns and fraction information In-Reply-To: References: Message-ID: The currency data overrides the pattern decimals completely. You can look at ICU for an example. {phone} On Nov 7, 2014 7:49 AM, "Isaac Jurado" wrote: > Hello, > > First of all, I want to apologize in advance just in case my question is > too dumb. My question is about currency formatting and decimal places. > > Most of the locale definitions use a currency pattern that ends with > "0.00". This means that, at least, one integer and two decimal digits > will be printed along with its decimal separator. However, the > supplemental data contains information about decimal digits usage and > rounding policies [1, 2]. > > For those currencies that do not use decimals at all (a.g. COP, the > obsolete ESP, JPY, etc.), the currency format pattern still forces a > decimal separator followed by two zeroes to be "printed". Is that > considered an implementation mistake or the element is > completely unrelated to the currency pattern. > > In other words, is there any implementation deriving from CLDR that > makes use of fraction information when formatting a currency value? > > Thank you. > > [1] > http://www.unicode.org/cldr/charts/26/supplemental/detailed_territory_currency_information.html#format_info > [2] > http://unicode.org/repos/cldr/trunk/common/supplemental/supplementalData.xml > > -- > Isaac Jurado > _______________________________________________ > 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 isaac.jurado at roiback.com Fri Nov 7 11:49:52 2014 From: isaac.jurado at roiback.com (Isaac Jurado) Date: Fri, 7 Nov 2014 18:49:52 +0100 Subject: Currency patterns and fraction information In-Reply-To: References: Message-ID: On Fri, Nov 7, 2014 at 4:52 PM, Mark Davis ?? wrote: > > The currency data overrides the pattern decimals completely. That's good to know, thanks. Although it makes me wonder why have currency data instead of just defining a currency pattern such as: #,##0 ? in case no decimals should be used. > You can look at ICU for an example. I've downloaded the Java source, but I will need some time to find the right spot. I'll take a look this weekend. Thanks again for the information. Best regards. -- Isaac Jurado From emmo at us.ibm.com Fri Nov 7 12:07:29 2014 From: emmo at us.ibm.com (John Emmons) Date: Fri, 7 Nov 2014 12:07:29 -0600 Subject: Currency patterns and fraction information In-Reply-To: References: Message-ID: Isaac, the reason is that the currency pattern can more generally apply to ANY currency, not just the one that is most commonly used in the country. For example, in the Japanese locale, I have the default currency pattern of "?#,##0.00" which would apply as "?1,234.56" for euros, or "?1,235" for yen. Regards, John C. Emmons Globalization Architect & Unicode CLDR TC Chairman IBM Software Group Internet: emmo at us.ibm.com From: Isaac Jurado To: Mark Davis ?? Cc: cldr-users at unicode.org Date: 11/07/2014 11:54 AM Subject: Re: Currency patterns and fraction information Sent by: "CLDR-Users" On Fri, Nov 7, 2014 at 4:52 PM, Mark Davis ?? wrote: > > The currency data overrides the pattern decimals completely. That's good to know, thanks. Although it makes me wonder why have currency data instead of just defining a currency pattern such as: #,##0 ? in case no decimals should be used. > You can look at ICU for an example. I've downloaded the Java source, but I will need some time to find the right spot. I'll take a look this weekend. Thanks again for the information. Best regards. -- Isaac Jurado _______________________________________________ CLDR-Users mailing list CLDR-Users at unicode.org http://unicode.org/mailman/listinfo/cldr-users -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: graycol.gif Type: image/gif Size: 105 bytes Desc: not available URL: From isaac.jurado at roiback.com Sun Nov 9 13:01:50 2014 From: isaac.jurado at roiback.com (Isaac Jurado) Date: Sun, 9 Nov 2014 20:01:50 +0100 Subject: Currency patterns and fraction information In-Reply-To: References: Message-ID: On Fri, Nov 7, 2014 at 7:07 PM, John Emmons wrote: > > Isaac, the reason is that the currency pattern can more generally > apply to ANY currency, not just the one that is most commonly used in > the country. For example, in the Japanese locale, I have the default > currency pattern of "?#,##0.00" which would apply as "?1,234.56" for > euros, or "?1,235" for yen. I understand. Following Mr. Davis' suggestion, I've been reviewing the ICU code and I can see how currency data overrides the pattern. If I was not mistaken, the bulk of the logic is implemented within the DecimalFormat class: http://source.icu-project.org/repos/icu/icu/tags/release-52-1/source/i18n/decimfmt.cpp When using the ".setCurrency()" method, the currency pattern is applied, but then the MaxFractionDigits and MinFractionDigits are overriden by currency data. However, when only ".applyPattern()" is used, the fraction digit bounds are those from the given pattern. Therefore, currency data can still be programatically overriden by a call to ".applyPattern()" after calling ".setCurrency()". This particular scenario has been trigerring a sort of inconsistency alarm in my personal reasoning, hence the initial motivation of my question. In the end, I drew the following conclusions: 1. By default, currency data completely overrides currency pattern in terms of number of decimal/fraction digits (as Mr. Davis wrote). 2. Nevertheless, libraries still offer ultimate flexibility so a pattern can override currency data, and this should be interpreted as a feature, not a bug For the record, my original intention is to patch the Python Babel [1] package in order to comply with currency data obtained from CLDR. Thank you both Mr. Emmons and Mr. Davis for your answers. Kind regards. [1] http://babel.pocoo.org/ -- Isaac Jurado From verdy_p at wanadoo.fr Sun Nov 9 19:43:10 2014 From: verdy_p at wanadoo.fr (Philippe Verdy) Date: Mon, 10 Nov 2014 02:43:10 +0100 Subject: Currency patterns and fraction information In-Reply-To: References: Message-ID: But there's a caveat: the precision of currency amounts is varaible depending on usage or currency form. - There's a legal precision used for accounting (bank accounts, billing, transfers, checks, credit card), usually 2 decimals in most countries. It is used for electronic payments. - There's a legal precision for the usable coins (soon, some countries will abandon the physical money for only electronic currencies, that precision is lower. - There's a precision (sometimes legal) for currency conversion (e.g. 6 significant digits for converting former currencies to a new one, like the transition to the Euro) - There's a variable precision for pricing (notably price per unit) : oil, phone fees per minute which is often higher. As long as the traded things are not cumulated on a legal bill, the precision is kept (the small differences are then discarded and not reported in the legal accounting records, only the amount that will be effectively payed/transfered matters, and it is rounded; intermediate amounts may also be rounded, such as when computing applicable taxes). - For some procedures such as fiscal declarations, it is often requested to round the amounts or discard decimals (differences are "offered' by the administration and not taxable), simply because it avoids handling errors (such as forgetting to input a decimal separator, causing taxes to be computed on amounts 100 times higher than expected : recovering these errors costs much more than offering these small fiscal exemptions) For CLDR data we should limit ourself to only two kind of usage : - electronic money transfers and legal accounting - physical legal currency (cash) 2014-11-09 20:01 GMT+01:00 Isaac Jurado : > On Fri, Nov 7, 2014 at 7:07 PM, John Emmons wrote: > > > > Isaac, the reason is that the currency pattern can more generally > > apply to ANY currency, not just the one that is most commonly used in > > the country. For example, in the Japanese locale, I have the default > > currency pattern of "?#,##0.00" which would apply as "?1,234.56" for > > euros, or "?1,235" for yen. > > I understand. Following Mr. Davis' suggestion, I've been reviewing the > ICU code and I can see how currency data overrides the pattern. If I > was not mistaken, the bulk of the logic is implemented within the > DecimalFormat class: > > > http://source.icu-project.org/repos/icu/icu/tags/release-52-1/source/i18n/decimfmt.cpp > > When using the ".setCurrency()" method, the currency pattern is applied, > but then the MaxFractionDigits and MinFractionDigits are overriden by > currency data. However, when only ".applyPattern()" is used, the > fraction digit bounds are those from the given pattern. > > Therefore, currency data can still be programatically overriden by a > call to ".applyPattern()" after calling ".setCurrency()". This > particular scenario has been trigerring a sort of inconsistency alarm in > my personal reasoning, hence the initial motivation of my question. > > In the end, I drew the following conclusions: > > 1. By default, currency data completely overrides currency pattern in > terms of number of decimal/fraction digits (as Mr. Davis wrote). > > 2. Nevertheless, libraries still offer ultimate flexibility so a > pattern can override currency data, and this should be interpreted > as a feature, not a bug > > For the record, my original intention is to patch the Python Babel [1] > package in order to comply with currency data obtained from CLDR. > > Thank you both Mr. Emmons and Mr. Davis for your answers. > > Kind regards. > > [1] http://babel.pocoo.org/ > > -- > Isaac Jurado > > _______________________________________________ > 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 aaharoni at wikimedia.org Tue Nov 11 02:04:39 2014 From: aaharoni at wikimedia.org (Amir E. Aharoni) Date: Tue, 11 Nov 2014 10:04:39 +0200 Subject: =?UTF-8?Q?declination_of_CLDR_language_names=E2=80=8F?= Message-ID: Hi, CLDR has lists of language names. This is useful for displaying language names to users in lists or menus, but less useful for displaying them in full sentences. For example, it can work for displaying a sentence like "This page is not available in $language" in English, where the language name is unchanged by morphology, but it won't work for Russian and many other languages where the language name must change according to grammatical case (or something along these lines). The above can also apply to currency names and so on. For fun, I already started implementing a relevant automatic grammar transformation for language names in Russian for my project (MediaWiki), but before I dive too deeply into this, I wanted to ask: is there an existing solution for this anywhere? Thanks! -- Amir Elisha Aharoni? ? ?????? ????????? ?????????? Language Engineering? ? ?????????? ?????????? Wikimedia Foundation? ? ????? ????????????? -------------- next part -------------- An HTML attachment was scrubbed... URL: From jkorpela at cs.tut.fi Tue Nov 11 02:43:58 2014 From: jkorpela at cs.tut.fi (Jukka K. Korpela) Date: Tue, 11 Nov 2014 10:43:58 +0200 Subject: declination of CLDR language =?UTF-8?B?bmFtZXPigI8=?= In-Reply-To: References: Message-ID: <5461CC4E.6090709@cs.tut.fi> 2014-11-11 10:04, Amir E. Aharoni wrote: > CLDR has lists of language names. This is useful for displaying language > names to users in lists or menus, but less useful for displaying them in > full sentences. Similar considerations apply to CLDR data in general. It is primarily useful for lists, menus, tables, and isolated expressions, less suitable for texts in sentence contexts. The reason is that the latter involves much more difficult linguistic issues and is more complex?and also less often needed. > For example, it can work for displaying a sentence like > "This page is not available in $language" in English, where the language > name is unchanged by morphology, but it won't work for Russian and many > other languages where the language name must change according to > grammatical case (or something along these lines). This is a case where localization needs to involve real translation of text, not just construction of localized expressions using data like CLDR. > For fun, I already started implementing a relevant automatic grammar > transformation for language names in Russian for my project (MediaWiki), > but before I dive too deeply into this, I wanted to ask: is there an > existing solution for this anywhere? There must be existing solutions, since the problem is common and needs to be solved somehow, but I would expect the solutions to be simplistic and clumsy, often leading to non-idiomatic constructs. For example, much of the Facebook localization uses approaches that would in this case mean using ?This page is not available in the language $language.? (e.g., ???? ???????? ?? ???????? ?? ????? ???????????), which is understandable but sounds as artificial as it is, and also often ungrammatical; to make it grammatical, at the cost of making it even more clumsy, you could use ?This page is not available in the following language: $language.? Any general solution to the problem would be very complicated, because in different languages, different types of inflection information are needed in order to use (e.g.) language names in sentence context. This means that a CLDR entry would need to contain structured data with a structure that depends on the language. A way to deal with this would be to represent that data as a string (say, "5*J"), to be interpreted according to conventions defined separately for each language by the language experts (e.g., ?5? might be a number of declination type and ?*J? would indicate that special rule J is to be applied). But such conventions do not usually exist, as well-defined sets of rules. Of course, to the extent that the inflected forms can be created from the base form alone, with no extra information, the problem becomes pure language technology (of varying difficulty by language). Yucca From patrick.andries at xcential.com Tue Nov 11 06:55:13 2014 From: patrick.andries at xcential.com (Patrick Andries) Date: Tue, 11 Nov 2014 07:55:13 -0500 Subject: declination of CLDR language =?UTF-8?B?bmFtZXPigI8=?= In-Reply-To: <5461CC4E.6090709@cs.tut.fi> References: <5461CC4E.6090709@cs.tut.fi> Message-ID: <54620731.1010800@xcential.com> Does anybody know what is happening/hashappened with L20n which tried, I believe, to address challenges like declension ? https://developer.mozilla.org/en-US/docs/Mozilla/Projects/L20n/Localization_Use_Cases P. A. --- Ce courrier ?lectronique ne contient aucun virus ou logiciel malveillant parce que la protection avast! Antivirus est active. http://www.avast.com From verdy_p at wanadoo.fr Tue Nov 11 08:13:50 2014 From: verdy_p at wanadoo.fr (Philippe Verdy) Date: Tue, 11 Nov 2014 15:13:50 +0100 Subject: =?UTF-8?Q?Re=3A_declination_of_CLDR_language_names=E2=80=8F?= In-Reply-To: <54620731.1010800@xcential.com> References: <5461CC4E.6090709@cs.tut.fi> <54620731.1010800@xcential.com> Message-ID: Don't forget other contextual forms, such as mutations of initials or finals depending on the preceding or following words, or the alternation of these words. For example with - contraction of articles like ? le ? vs ? l? ? or ? de l? ? vs. ? de la ? (typical for French of Italian) - the required contraction of ? de le ? to ? du ? (French, Italian...), - adverbs like ? ne ? vs. ? n? ?, in French, or the ?-n?t ? suffix vs ? not ? word, or ?-not? gluing after ? can ? verb in English - verbs or auxiliaries like ? am ? vs. ??m ?, or ??s ? vs. ? is ?, or ??re ? vs. ? are ?, or ??ve ? vs. ? have ?, or ??d ? vs. ? would ? in English - particles like the genitive suffix ? ?s ? in English... - contextual mutation of capitals over articles that are part of a proper name (e.g. ? ? ? + ? Le Mans ? -> ? au Mans ?) - orthographic addition of particles between words only for phonologic purpose (like "-t-" in French between a conjugated verb with final vowels and a subject pronoun also starting by a vowel like ? il ? in French) These mutations/contractions/additions are very language-specific and require specific lookup rules. 2014-11-11 13:55 GMT+01:00 Patrick Andries : > Does anybody know what is happening/hashappened with L20n which tried, I > believe, to address challenges like declension ? > > https://developer.mozilla.org/en-US/docs/Mozilla/Projects/ > L20n/Localization_Use_Cases > > P. A. > > > --- > Ce courrier ?lectronique ne contient aucun virus ou logiciel malveillant > parce que la protection avast! Antivirus est active. > http://www.avast.com > > > > _______________________________________________ > 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 patrick.andries at xcential.com Tue Nov 11 08:21:57 2014 From: patrick.andries at xcential.com (Patrick Andries) Date: Tue, 11 Nov 2014 09:21:57 -0500 Subject: declination of CLDR language =?UTF-8?B?bmFtZXPigI8=?= In-Reply-To: References: <5461CC4E.6090709@cs.tut.fi> <54620731.1010800@xcential.com> Message-ID: <54621B85.1040202@xcential.com> Je n'oubliais pas, je connais bien ce sujet. Le 11/nov./2014 09:13, Philippe Verdy a ?crit : > Don't forget other contextual forms, such as mutations of initials or > finals depending on the preceding or following words, or the > alternation of these words. > > For example with > - contraction of articles like ? le ? vs ? l? ? or ? de l? ? vs. ? de > la ? (typical for French of Italian) > - the required contraction of ? de le ? to ? du ? (French, Italian...), > - adverbs like ? ne ? vs. ? n? ?, in French, or the ?-n?t ? suffix vs > ? not ? word, or ?-not? gluing after ? can ? verb in English > - verbs or auxiliaries like ? am ? vs. ??m ?, or ??s ? vs. ? is ?, or > ??re ? vs. ? are ?, or ??ve ? vs. ? have ?, or ??d ? vs. ? would ? in > English > - particles like the genitive suffix ? ?s ? in English... > - contextual mutation of capitals over articles that are part of a > proper name (e.g. ? ? ? + ? Le Mans ? -> ? au Mans ?) > - orthographic addition of particles between words only for phonologic > purpose (like "-t-" in French between a conjugated verb with final > vowels and a subject pronoun also starting by a vowel like ? il ? in > French) > > These mutations/contractions/additions are very language-specific and > require specific lookup rules. > > > 2014-11-11 13:55 GMT+01:00 Patrick Andries > >: > > Does anybody know what is happening/hashappened with L20n which > tried, I believe, to address challenges like declension ? > > https://developer.mozilla.org/en-US/docs/Mozilla/Projects/L20n/Localization_Use_Cases > > P. A. > > > --- > Ce courrier ?lectronique ne contient aucun virus ou logiciel > malveillant parce que la protection avast! Antivirus est active. > http://www.avast.com > > > > _______________________________________________ > CLDR-Users mailing list > CLDR-Users at unicode.org > http://unicode.org/mailman/listinfo/cldr-users > > > Aucun virus trouv? dans ce message. > Analyse effectu?e par AVG - www.avg.fr > Version: 2015.0.5557 / Base de donn?es virale: 4213/8552 - Date: > 11/11/2014 > --- Ce courrier ?lectronique ne contient aucun virus ou logiciel malveillant parce que la protection avast! Antivirus est active. http://www.avast.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From rxaviers at gmail.com Fri Nov 28 14:56:38 2014 From: rxaviers at gmail.com (Rafael Xavier) Date: Fri, 28 Nov 2014 18:56:38 -0200 Subject: Formatting currencies Message-ID: Hello friends, hope you had a blessed thanksgiving (if you happen to celebrate it). Follow a couple of questions I had interpreting 4 Currencies , for which I'd very much appreciate your replies. *name currency formatting* (displayName) To format a particular currency value "ZWD" for a particular numeric value > *n*: > ... > 5. The numeric value, formatted according to the locale with the number > of decimals appropriate for the currency, is substituted for {0} in the > unitPattern, while the currency display name is substituted for the {1}. > What does "formatted according to the locale" mean? To use locale's decimal standard pattern (for example, #,##0.### --- "69,900 US dollars" in *en*)? Any other pattern instead? What does "with the number of decimals appropriate for the currency" mean? To use the supplemental currency data `digits` and `rounding` values to override the above pattern (for example, "69,900.00 US dollars" in *en*)? *supplemental currency data* > *digits: *the number of decimal digits normally formatted. The default is > 2. > Are "number of decimal digits" the minimum fraction digits or the maximum fraction digits? I'd assume the minimum. Thanks, Rafael Xavier CurrencyFormat -- +55 (16) 98138-1582, +1 (415) 568-5854, skype: rxaviers http://rafael.xavier.blog.br -------------- next part -------------- An HTML attachment was scrubbed... URL: From srl at icu-project.org Fri Nov 28 15:46:12 2014 From: srl at icu-project.org (Steven R. Loomis) Date: Fri, 28 Nov 2014 13:46:12 -0800 Subject: Formatting currencies In-Reply-To: References: Message-ID: <81E51250-6C5E-40CC-BBC4-C8A6D8843DD1@icu-project.org> Enviado desde nuestro iPhone. > El nov 28, 2014, a las 12:56 PM, Rafael Xavier escribi?: > > Hello friends, hope you had a blessed thanksgiving (if you happen to celebrate it). > > Follow a couple of questions I had interpreting 4 Currencies, for which I'd very much appreciate your replies. > > > name currency formatting (displayName) > >> To format a particular currency value "ZWD" for a particular numeric value n: >> ... >> 5. The numeric value, formatted according to the locale with the number of decimals appropriate for the currency, is substituted for {0} in the unitPattern, while the currency display name is substituted for the {1}. > > What does "formatted according to the locale" mean? To use locale's decimal standard pattern (for example, #,##0.### --- "69,900 US dollars" in en)? Any other pattern instead? No, the currency pattern. > What does "with the number of decimals appropriate for the currency" mean? To use the supplemental currency data `digits` and `rounding` values to override the above pattern (for example, "69,900.00 US dollars" in en)? > > > supplemental currency data > > >> digits: the number of decimal digits normally formatted. The default is 2. > > Are "number of decimal digits" the minimum fraction digits or the maximum fraction digits? I'd assume the minimum. Min and max. So USD and EUR=2, so 0.99, 1.00, 1.01, etc > > Thanks, > Rafael Xavier > > CurrencyFormat > -- > +55 (16) 98138-1582, +1 (415) 568-5854, skype: rxaviers > http://rafael.xavier.blog.br > _______________________________________________ > 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 rxaviers at gmail.com Fri Nov 28 16:08:28 2014 From: rxaviers at gmail.com (Rafael Xavier) Date: Fri, 28 Nov 2014 20:08:28 -0200 Subject: Formatting currencies In-Reply-To: <81E51250-6C5E-40CC-BBC4-C8A6D8843DD1@icu-project.org> References: <81E51250-6C5E-40CC-BBC4-C8A6D8843DD1@icu-project.org> Message-ID: On Fri, Nov 28, 2014 at 7:46 PM, Steven R. Loomis wrote: > > > Enviado desde nuestro iPhone. > > El nov 28, 2014, a las 12:56 PM, Rafael Xavier > escribi?: > > Hello friends, hope you had a blessed thanksgiving (if you happen to > celebrate it). > > Follow a couple of questions I had interpreting 4 Currencies > , for > which I'd very much appreciate your replies. > > > *name currency formatting* (displayName) > > To format a particular currency value "ZWD" for a particular numeric value >> *n*: >> ... >> 5. The numeric value, formatted according to the locale with the number >> of decimals appropriate for the currency, is substituted for {0} in the >> unitPattern, while the currency display name is substituted for the {1}. >> > > What does "formatted according to the locale" mean? To use locale's > decimal standard pattern (for example, #,##0.### --- "69,900 US dollars" > in *en*)? Any other pattern instead? > > > No, the currency pattern. > What to do with the symbol from the currency pattern? Ignore/Drop it? Or we'd have "?69,900 US dollars". > > What does "with the number of decimals appropriate for the currency" mean? > To use the supplemental currency data > > `digits` and `rounding` values to override the above pattern (for example, > "69,900.00 US dollars" in *en*)? > > > > > *supplemental currency data* > >> *digits: *the number of decimal digits normally formatted. The default >> is 2. >> > > Are "number of decimal digits" the minimum fraction digits or the maximum > fraction digits? I'd assume the minimum. > > > Min and max. So USD and EUR=2, so 0.99, 1.00, 1.01, etc > Actually, I wasn't sure if it was: - Min and max (e.g., f(1) = "$1.00", f(1.123) = "$1.12"), or - Max only (e.g., f(1) = "$1", f(1.123) = "$1.12"). > > Thanks, > Rafael Xavier > > CurrencyFormat > -- > +55 (16) 98138-1582, +1 (415) 568-5854, skype: rxaviers > http://rafael.xavier.blog.br > > _______________________________________________ > CLDR-Users mailing list > CLDR-Users at unicode.org > http://unicode.org/mailman/listinfo/cldr-users > > -- +55 (16) 98138-1582, +1 (415) 568-5854, skype: rxaviers http://rafael.xavier.blog.br -------------- next part -------------- An HTML attachment was scrubbed... URL: From srl at icu-project.org Fri Nov 28 18:03:40 2014 From: srl at icu-project.org (Steven R. Loomis) Date: Fri, 28 Nov 2014 16:03:40 -0800 Subject: Formatting currencies In-Reply-To: References: <81E51250-6C5E-40CC-BBC4-C8A6D8843DD1@icu-project.org> Message-ID: Too much turkey i guess. Sorry, I was responding for "normal " currency format not plural name. For currency name format it does look like it should be better specified. I'd expect "3 dollars" not "3.00 dollars". Anyways, I'll check on this next week. Enviado desde nuestro iPhone. > El nov 28, 2014, a las 2:08 PM, Rafael Xavier escribi?: > > > >> On Fri, Nov 28, 2014 at 7:46 PM, Steven R. Loomis wrote: >> >> >> Enviado desde nuestro iPhone. >> >>> El nov 28, 2014, a las 12:56 PM, Rafael Xavier escribi?: >>> >>> Hello friends, hope you had a blessed thanksgiving (if you happen to celebrate it). >>> >>> Follow a couple of questions I had interpreting 4 Currencies, for which I'd very much appreciate your replies. >>> >>> >>> name currency formatting (displayName) >>> >>>> To format a particular currency value "ZWD" for a particular numeric value n: >>>> ... >>>> 5. The numeric value, formatted according to the locale with the number of decimals appropriate for the currency, is substituted for {0} in the unitPattern, while the currency display name is substituted for the {1}. >>> >>> What does "formatted according to the locale" mean? To use locale's decimal standard pattern (for example, #,##0.### --- "69,900 US dollars" in en)? Any other pattern instead? >> >> No, the currency pattern. > > What to do with the symbol from the currency pattern? Ignore/Drop it? Or we'd have "?69,900 US dollars". > >> >>> What does "with the number of decimals appropriate for the currency" mean? To use the supplemental currency data `digits` and `rounding` values to override the above pattern (for example, "69,900.00 US dollars" in en)? >>> >>> >>> supplemental currency data >>> >>> >>>> digits: the number of decimal digits normally formatted. The default is 2. >>> >>> Are "number of decimal digits" the minimum fraction digits or the maximum fraction digits? I'd assume the minimum. >> >> Min and max. So USD and EUR=2, so 0.99, 1.00, 1.01, etc > > Actually, I wasn't sure if it was: > - Min and max (e.g., f(1) = "$1.00", f(1.123) = "$1.12"), or > - Max only (e.g., f(1) = "$1", f(1.123) = "$1.12"). >>> >>> Thanks, >>> Rafael Xavier >>> >>> CurrencyFormat >>> -- >>> +55 (16) 98138-1582, +1 (415) 568-5854, skype: rxaviers >>> http://rafael.xavier.blog.br >>> _______________________________________________ >>> CLDR-Users mailing list >>> CLDR-Users at unicode.org >>> http://unicode.org/mailman/listinfo/cldr-users > > > > -- > +55 (16) 98138-1582, +1 (415) 568-5854, skype: rxaviers > http://rafael.xavier.blog.br -------------- next part -------------- An HTML attachment was scrubbed... URL: From rxaviers at gmail.com Sat Nov 29 15:03:57 2014 From: rxaviers at gmail.com (Rafael Xavier) Date: Sat, 29 Nov 2014 19:03:57 -0200 Subject: Formatting currencies In-Reply-To: References: <81E51250-6C5E-40CC-BBC4-C8A6D8843DD1@icu-project.org> Message-ID: Thank you ver much so far Steven. On Friday, November 28, 2014, Steven R. Loomis wrote: > Too much turkey i guess. Sorry, I was responding for "normal " currency > format not plural name. > > For currency name format it does look like it should be better specified. > I'd expect "3 dollars" not "3.00 dollars". Anyways, I'll check on this next > week. > > Enviado desde nuestro iPhone. > > El nov 28, 2014, a las 2:08 PM, Rafael Xavier > escribi?: > > > > On Fri, Nov 28, 2014 at 7:46 PM, Steven R. Loomis > wrote: > >> >> >> Enviado desde nuestro iPhone. >> >> El nov 28, 2014, a las 12:56 PM, Rafael Xavier > > escribi?: >> >> Hello friends, hope you had a blessed thanksgiving (if you happen to >> celebrate it). >> >> Follow a couple of questions I had interpreting 4 Currencies >> , for >> which I'd very much appreciate your replies. >> >> >> *name currency formatting* (displayName) >> >> To format a particular currency value "ZWD" for a particular numeric >>> value *n*: >>> ... >>> 5. The numeric value, formatted according to the locale with the number >>> of decimals appropriate for the currency, is substituted for {0} in the >>> unitPattern, while the currency display name is substituted for the {1}. >>> >> >> What does "formatted according to the locale" mean? To use locale's >> decimal standard pattern (for example, #,##0.### --- "69,900 US dollars" >> in *en*)? Any other pattern instead? >> >> >> No, the currency pattern. >> > > What to do with the symbol from the currency pattern? Ignore/Drop it? Or > we'd have "?69,900 US dollars". > > >> >> What does "with the number of decimals appropriate for the currency" >> mean? To use the supplemental currency data >> >> `digits` and `rounding` values to override the above pattern (for example, >> "69,900.00 US dollars" in *en*)? >> >> >> >> >> *supplemental currency data* >> >>> *digits: *the number of decimal digits normally formatted. The default >>> is 2. >>> >> >> Are "number of decimal digits" the minimum fraction digits or the maximum >> fraction digits? I'd assume the minimum. >> >> >> Min and max. So USD and EUR=2, so 0.99, 1.00, 1.01, etc >> > > Actually, I wasn't sure if it was: > - Min and max (e.g., f(1) = "$1.00", f(1.123) = "$1.12"), or > - Max only (e.g., f(1) = "$1", f(1.123) = "$1.12"). > >> >> Thanks, >> Rafael Xavier >> >> CurrencyFormat >> -- >> +55 (16) 98138-1582, +1 (415) 568-5854, skype: rxaviers >> http://rafael.xavier.blog.br >> >> _______________________________________________ >> CLDR-Users mailing list >> CLDR-Users at unicode.org >> >> http://unicode.org/mailman/listinfo/cldr-users >> >> > > > -- > +55 (16) 98138-1582, +1 (415) 568-5854, skype: rxaviers > http://rafael.xavier.blog.br > > -- +55 (16) 98138-1582, +1 (415) 568-5854, skype: rxaviers http://rafael.xavier.blog.br -------------- next part -------------- An HTML attachment was scrubbed... URL: