[dev] Gettext strings in framework packages

[Chuck Hagenbuch]

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  
> implications.

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...

-chuck