If the bundles are produced in different countries, it may be more convenient to allow the producers to use the charset most convenient to them. If however, a single charset could be imposed, say UTF-8, we could simplify the expression to: @LocaleNames(charset="UTF-8", values={"en_UK", "fr", "tr_TR", "el_GR"}) instead of @LocaleData( defaultCharset="UTF8", value = { @Locale("en_UK"), @Locale("fr_FR"), @Locale(value="tr_TR", charset="ISO8859_3"), @Locale("el_GR") } ) However, between an inelegant syntax targeted at developers and imposing to a charset to translators, well, the former seems as the lesser weevil. If I understand you correctly, the spreadsheet would be used to transform a resource bundle from one encoding to another? It would read in one encoding and write in another. Right? Rick Beton wrote:
2009/9/4 Ceki Gulcu <ceki@qos.ch <mailto:ceki@qos.ch>>
<snipped>
Can you think of a more elegant approach which still allows the user to designate the charset for a given locale? <http://qos.ch/mailman/listinfo/cal10n-dev>
Hmm - it has become rather messy. Can I suggest an alternative tack: require the properties files to be always UTF-8 (or UTF-16 with a BOM). Then the original simple syntax is viable. KISS principle.
As far as producing UTF-8 files is concerned, I imagine a spreadsheet 'compiler' that will take a CSV, ODS or XLS file and extract the necessary separate properties files bundle. The spreadsheet would be a simple single sheet containing the keys in the first column and any number of translation strings in the following columns, each of which has the locale name as its header (e.g. "en_UK ").
Rick
-- Ceki Gülcü Logback: The reliable, generic, fast and flexible logging framework for Java. http://logback.qos.che