Format currency in a language, regardless of country

I want to format an amount of money (in Euros) in the user's language in Java, regardless of the country the user is in:

final NumberFormat currencyFormat = NumberFormat.getCurrencyInstance(loc);
currencyFormat.setCurr开发者_StackOverflow中文版ency(EUR);
currencyFormat.format(new BigDecimal("1.99"));

However, the output for different input locales (loc) is as follows:

• nl_NL: € 1,99
• nl_BE: 1,99 €
• nl_DE: EUR 1,99
• nl (new Locale("nl")): EUR 1,99

So I have two problems

• The output does depend on country, not just language (as the first 2 show), but country shouldn't matter to me. My game can be played for example in Dutch while traveling in Africa.
• When using a locale without a country or with a country that doesn't match the language (second 2), no symbol for the currency is printed.

Note that I'm developing a payment interface for the game, so a locale of nl_DE means that the interface and currencies should be displayed in Dutch, but it shows only payment methods available in Germany.

I am not exactly sure what you are up to, but it seems that you have let's say web application and you need separate pieces of information about language and country. OK, let me clarify that:

1. To correctly format an amount to pay you actually need both the language and the country, meaning the locale as this is what identifies the appropriate format.
2. To offer correct payment system, you only need a country user is currently located.
3. To display appropriate translations you only need the language (at least that is what you think).

Now, on how to do that. The easiest way would be to establish some kind of user profile and let user decide on what would be the best locales for formatting, what for translation and what payment system (s)he want to use. If you are developing some kind of web-based game, you can actually read Locales from HTTP Accept-Language headers (you actually need to set good defaults and this is the best place to find such information). To "separate" language from the country, all you need is to read language and country code from locale, which is as simple as:

Locale locale = request.getLocale(); // the most acceptable Locale using Servlet API
String language = locale.getLanguage(); // gets language code
String country = locale.getCountry(); // gets country code

Now, language is often not enough to read texts from Resource Bundles, as there are Locales (i.e. zh_CN, zh_TW) for which actual language is different depending on the country (in above example Chinese Simplified is used in mainland of China as well as in Singapore, whereas all other Chinese speaking world is using Traditional Chinese). Therefore you still need actual locale.

Country code will give you the selected country, but not the one user currently is in. It might be good or bad, depending on the view. If you need to ensure that the payment happens in the country user is in, I am afraid that you would need to employ Geolocation, with all the consequences...

Does this answer your question, or I misunderstood something...?

I'm thinking I should just split the input locale for my payment screen into:

• Display locale, e.g. nl_NL, nl_BE, fr_FR. Used for, well, displaying stuff. This is a property of user accounts.
• Country of residence, e.g. NL, FR, TR. User to determine the payment methods. This is determined via IP-address but can be manually overridden.

I'm not clear on what you mean by language, regardless of country. The currency denomination itself is obviously independent of language and country, but the formatting conventions vary by culture, not language. Typically we tie these things to something besides local machine settings in our applications because there are always issues of the same language being used in different cultures - for instance Spain uses 9.999,99 and Mexico uses 9,999.99 but both (nominally) speak the Spanish language. And of course, just because someone lives in a particular country does not mean they don't work in a different cultural setting (for instance, telecommuters, or regional managers who cross cultural boundaries).

It's not that simple a problem and can only really be solved by defining the scope of the expectations.

Your payment methods shouldn't be tied to a locale, they should be tied to what you require for the payment processing system. Then you should display that value according to the customs of the selected locale.