[dev] Gettext strings in framework packages

[Jan Schneider]

Zitat von Gunnar Wrobel <p at rdus.de>:

> Quoting Chuck Hagenbuch <chuck at horde.org>:
>
>> Quoting Michael M Slusarz <slusarz at horde.org>:
>>
>>> What is the strategy for gettext strings in framework packages.    
>>> AFAICT, these are our options:
>>>
>>> 1.) Keep current strategy (when building gettext strings for  
>>> horde,  incorporates all framework packages). This has the major  
>>> drawback  of not allowing true upgrades of framework packages,  
>>> since a horde  upgrade would be needed instead.
>>> 2.) Like #1, but keep all framework gettext strings in its own   
>>> package (Framework_GettextStrings or something similar).
>>> 3.) Keep gettext strings for each framework package inside each package.
>>> 4.) No gettext strings in framework at all.  This is the PEAR-ish   
>>> way of doing things.  Instead of returning/using gettext strings,   
>>> you pass back a placeholder (i.e. a constant) and it is the apps   
>>> job to do the gettext string generation.
>>
>> 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.

Jan.

-- 
Do you need professional PHP or Horde consulting?
http://horde.org/consulting/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: Digitale PGP-Unterschrift
URL: <http://lists.horde.org/archives/dev/attachments/20090712/f7fd681b/attachment.bin>