In general adding such support is great. The only issue is if it is in code we get from upstream musl, in which case we would need to coordinate with them, we don't want to diverge more than we have to.
- Alon On Sat, Nov 15, 2014 at 2:06 PM, Nicholas Wilson < [email protected]> wrote: > Hi, > > Emscripten currently supports only the C locale (and its "POSIX" alias), > and doesn't even have "C.UTF-8" (emscripten's "C" locale claims its codeset > is ASCII, although actually its functions like printf and strftime are > already completely UTF-8-safe). We ship complete translations for several > languages in our products, and will soon have to have multi-language > support in our emscripten product. > > Really, it's just the date and time that we need from C, when it comes > down it. If I submitted support for just this, would that be OK, or would > you want "complete" support for all the odd number-parsing and monetary > functions too? > > These are the functions that are locale-dependent: > * atoi/atol/sscanf/printf/strtol and all the other digit-parsing and > printing functions > These can be supported using Intl.NumberFormat in browsers to output nice > Arabic digits; there isn't a handy ECMAScript function for parsing though, > oddly. Getting the currency symbol for strfmon is also possible using > NumberFormat. > * strftime > This can be implemented using Intl.DateTimeFormat > * strcoll, isupper, etc (character functions) > Intl.Collator should be helpful here > * nl_langinfo > Some of the things like D_FMT are a right nuisance to scrape from > Intl.DateTimeFormat but should probably be possible. > > I don't know much about C++ locale stuff, never had need for it (I stick > to the C functions that work, plus bits of ICU to replace broken ISO > functions). > > Maybe struggling to retro-fit the ECMAScript functions into the C ones is > just too error-prone though? Another alternative I'd be happy to code up > would be an Emscripten-specific set of date/time functions to go in > <emscripten.h> that expose the browser's locale functions without munging > them into a legacy C interface. You already have to call platform-specific > functions on Mac and Windows already, because the C strftime is buggy and > incomplete, so having a solid set of emscripten functions might be both > easier and preferable to trying to make setlocale+strftime work just like > on Linux. > > Any thoughts on these possibilities? > > Nick > > -- > You received this message because you are subscribed to the Google Groups > "emscripten-discuss" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "emscripten-discuss" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
