[cal10n-dev] Better annotations?

[Ceki Gulcu]

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 at qos.ch <mailto:ceki at 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