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

Currency.getSymbol confusing, change semantics and add getSymbolFormat API

Description

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.

Environment

Status

Assignee

Douglas Felt

Reporter

Douglas Felt

Labels

Time Needed

Days

tracCc

sffc@1d5920f4b44b27a8

tracCreated

Jan 15, 2008, 8:32 PM

tracOwner

doug

tracProject

all

tracReporter

doug

tracStatus

accepted

tracWeeks

0.5

Components

Priority

assess