[dev] Gettext strings in framework packages

[Chuck Hagenbuch]

Quoting Jan Schneider <jan at horde.org>:

> Zitat von Chuck Hagenbuch <chuck at horde.org>:
>
>> Quoting Jan Schneider <jan at horde.org>:
>>
>>>> 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...
>>>
>>> We would lose one of the major benefits of using gettext if we did  
>>> this, unless I misunderstood you. If we don't use gettext calls  
>>> inside the code, all the gettext tools that extract strings from  
>>> the files, and link strings in po files back to the source code,  
>>> stop working.
>>
>> What about standardizing on a short shim function like t() or _t(),  
>> and then passing that to xgettext's --keyword argument?
>
> I still don't see using gettext a high barrier. It's easier for  
> folks to create aliases for _() and ngettext() if they don't have  
> gettext compiled in, than changing the whole toolchain and  
> introducing yet another function wrapper. Where would that function  
> go anyway, if everything is packaged in classes now?

The barrier with gettext *especially* when we're talking about making  
framework packages usable outside of Horde is that it introduces a  
hard dependency on a PHP extension that isn't available by default -  
it's not in the build that ships with Mac OS X, for example.

Your point about where the shim function would go is fair, though.  
What I'd prefer to to is to inject a translation object into packages  
that need one.

I just tested, and you can pass --keyword=t to xgettext and it will  
recognize calls like:

return $this->dict->t("foo");

-chuck