[dev] Gettext strings in framework packages
chuck at horde.org
Tue Jul 14 03:33:49 UTC 2009
Quoting Jan Schneider <jan at horde.org>:
>>>> 3.) Keep gettext strings for each framework package inside each package.
>>> I think getting away from gettext in framework libs is the way to
>>> go. It's a not insignificant dependency, and hardcoding it limits
>>> our ability to support other options (we can stub in the
>>> functions, but for framework packages that's not so useful since
>>> the stub becomes a dependency for every library).
>> I agree in general but I see a few packages where it will be hard
>> to remove all use of gettext. One of mine would be Kolab_Filter
>> which is a PEAR package but it is also an application. The Mime
>> viewers look like they need gettext, too.
>> For those packages I think 3) would be the right option.
> I agree with Gunnar. We provide a lot of useful information with the
> gettext strings in the libraries. And it would be very ineffective
> to have to translate library return values to clear text messages in
> each application that uses them.
> 3) would theoretically be the most correct solution solution, but it
> really doesn't work well with the way that gettext works. We would
> have to switch catalogs (.mo files) on and off each time we do a
> method call that uses gettext stings inside a library. Even though
> catalogs are cached in memory, I'm not sure of the performance
What if we kept the strings, but removed the gettext dependency? We
could still use gettext in Horde itself, building the catalogs there?
We could have a simple Horde_Translation framework that the packages
used to manage their strings, and build application-level catalogs for
more traditional Horde usage...
More information about the dev