[dev] Gettext strings in framework packages

[Gunnar Wrobel]

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.

Cheers,

Gunnar

> --
> Horde developers mailing list - Join the hunt: http://horde.org/bounties/
> Frequently Asked Questions: http://horde.org/faq/
> To unsubscribe, mail: dev-unsubscribe at lists.horde.org
>




-------------- 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/7365ff34/attachment.bin>