We're updating the issue view to help you get more done. 

Currency.getSymbol confusing, change semantics and add getSymbolFormat API


Unlike Java's Currency, ICU's Currency provides support for different symbols depending on the quantity. This is done by returning a pattern suitable for a ChoiceFormat for those currencies that have this information. Unfortunately, this catches some users by surprise who expect to get a symbol and receive a pattern instead.

I propose that when we have a pattern, that getSymbol use a documented default value and return the result of using the ChoiceFormat with that value. This will match the Java API better.

An alternative or addition is to provide a 'getSymbolFormat' API on Currency that takes a locale and a type (symbol or name). This would return a NumberFormat or ChoiceFormat that formats the currency name as appropriate to the value. This behavior would be the same as NumberFormat.getCurrencyInstance except the value itself is not formatted.

ChoiceFormat doesn't accept simple strings to represent a 'fixed choice', but it would be convenient for the getSymbolFormat API if it did. ICU4J would have to add a ChoiceFormat since it currently doesn't have one and change the semantics so it could be constructible from a single string. If we did this then getSymbolFormat could always return a ChoiceFormat using the result from getName, regardless of whether the result was tagged as being a choiceformat or not.



Douglas Felt


Douglas Felt




Time Needed


Start date