On 23 Feb, Sven Neumann wrote:
> The core would then have to try to bindtextdomain() to all
> possible paths until success (or total failure if no message
> catalog was found).
You can't find out whether bindtextdomain failed or not. The only
way to get the information whether a catalog is available in a path
or not is to find the files yourself and then register them with the
right path. :(
Welcome to the nice world of gettext.
Anyway, I'd really like to leave the decision where to install a
catalog to the plugin. Considering that most of the external plugins
will get their own configure script it would be simple to find a
convinient place for the catalog, assign it to a #define and use this
define in the sourcecode of the plugin.
--
Servus,
Daniel
- Re: PROPOSAL: New i18n solution Glyph Lefkowitz
- PROPOSAL: New i18n solution (2nd try) Daniel . Egger
- Re: PROPOSAL: New i18n solution Marc Lehmann
- Re: PROPOSAL: New i18n solution Jon A. Cruz
- Re: PROPOSAL: New i18n solution Sven Neumann
- Re: PROPOSAL: New i18n solution Daniel . Egger
- Re: PROPOSAL: New i18n solution Sven Neumann
- Re: PROPOSAL: New i18n solution Daniel . Egger
- Re: PROPOSAL: New i18n solution Sven Neumann
- Re: PROPOSAL: New i18n solution Sven Neumann
- Re: PROPOSAL: New i18n solution Daniel . Egger
- Re: PROPOSAL: New i18n solution Daniel . Egger
- Re: PROPOSAL: New i18n solution Sven Neumann
- Re: PROPOSAL: New i18n solution Sven Neumann
- Re: PROPOSAL: New i18n solution Daniel . Egger
- Re: PROPOSAL: New i18n solution Sven Neumann
- Re: PROPOSAL: New i18n solution Daniel . Egger
- Re: PROPOSAL: New i18n solution Sven Neumann
- Re: PROPOSAL: New i18n solution Daniel . Egger
- Re: PROPOSAL: New i18n solution Sven Neumann
- Re: PROPOSAL: New i18n solution Daniel . Egger
