Ramkumar
Thank you for your clarification. I will just not set any env vars if we
pass NULL. I have already commited the code for that.
Also, I understand the limitation for my validation function and of
setlocale with compound locales (colon separated lists). Supporting
these kinds of locales is not currently supported by enlightenment and
probably will not be for some time. The reason being that the
bindtextdomain function can only bind one directory at a time. In
enlightenment message files may be in any directory in the messages
path. If we want to set the locale to zh_CN:zh_TW and zh_CN is installed
in a user path and zh_TW is in a system path there would be no way (that
I know of) to bind to both paths and get the correct behavior.
So the validation function currently rejects those types of paths. I
suppose I could validate compound locales and bind to the path of the
first locale. If you can help with any suggestions please let me know.
-shorne
On Sat, 2005-12-03 at 16:57 +0530, Ramkumar R wrote:
> > Can you explain why you do not want e to set any environment variables?
>
> Atleast it is counter-intuitive to say that the function restores env
> vars to their original values and then modify an env var. Secondly,
> LANGUAGE is expressly meant for users, and I doubt if it is a good
> thing for an app to set it, especially when it forks... well... the
> user meant it to be unset, so be it! As you said, E_LANG seems to be a
> better idea, but well... if something really wants to know E's
> language, it can use the much superior IPC mechanism.
>
> On a related note, should we be using LANGUAGE as an argument to
> setlocale, when LANGUAGE can use an extended syntax (colon separated
> list of locales) not understood by setlocale? In fact, I think even
> your validation function doesn't take the extended syntax into
> account. May be we should not be using LANGUAGE at all (gettext anyway
> references it if needed, even when only the default locale is set)
>
> Ramkumar
>
> --
> WARN_(accel)("msg null; should hang here to be win compatible\n");
> -- WINE source code
-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
_______________________________________________
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
