On Friday, 07 November 2008, at 09:46:09 (+1100), Carsten Haitzler wrote: > possibly - but it's a goo indicator of a system that isnt going to > support translation at all
True. > so when they find their language selector blank and empty and wonder > why input methods throw up and barf and a bunch of other things that > require your locale support to work... the problem will arise > anyway. e lives in an international world - some may like to live in > an "ascii america only" world. I guess I'm not seeing where the problems would arise. Input methods should (ideally) support any locale, even C. But I'm certainly no internationalization guru, so I'll take your word for it. > and posix does not preclude requiring locale support in libc to > support at least one of the translation locales in e. that does not > make a broken app - that makes it have a requirement that is not > met. Again, I don't see why a C -> C translation would break things, but I'm most likely missing something. Just for the record, I'm not speaking for myself here: [EMAIL PROTECTED] ~ #> locale -a | wc -l 702 :-) Michael -- Michael Jennings (a.k.a. KainX) http://www.kainx.org/ <[EMAIL PROTECTED]> Linux Server/Cluster Admin, LBL.gov Author, Eterm (www.eterm.org) ----------------------------------------------------------------------- "Reality makes believers of us all." -- "Enola Gay" ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ enlightenment-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
