> 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.
Sorry, but since I am new to e-devel, could you please tell me what
was the need to allow arbitrary search paths for messages, rather than
allowing a choice of a single base dir. If there is a genuine need, I
think we should inform the gettext people of the problem. The only
hackish solution I could think of is to generate a symlink directory
tree somewhere in .e at runtime, everytime we set the language,
incorporating all the mo files we gathered from the search path, and
then use it as our base directory.
Is this a problem with E alone? What about third party modules? Should
we be somehow exposing the load path for them as well, so that they
could use the search path as well?
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_idv37&alloc_id865&op=click
_______________________________________________
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
