Re: [SM-CVS] CVS: squirrelmail/templates/default page_header.tpl, NONE,1.1 footer.tpl,1.3,1.4 message_list.tpl,1.24, 1.25 stylesheet.tpl,1.4,1.5

[Tomas K. <to...@us...>]

>>>>

>>>> // Define our default link text.
>>>> $signout_link_default = _('Sign Out');
>>>> $compose_link_default = _('Compose');
>>>> $address_link_default = _('Addresses');
>>>> $folders_link_default = _('Folders');
>>>> $options_link_default = _('Options');
>>>> $search_link_default = _('Search');
>>>> $help_link_default = _('Help');
>>>>
>>>>
>>>
>>> <snip>
>>>
>>>
>>>
>>> I think we need to answer questions about where strings are best
>>> placed (and other design questions) before we continue adding new code
>>> to the templating system...  I am not convinced that gettext should be
>>> used in the template context.
>>
>> If gettext calls are not part of display code, it makes harder to
>> maintain them or read code. With gettext transition from one language to
>> many languages is simple enough - English strings are wrapped with
>> gettext calls.
>
> Agreed.  Any other context makes translation a lot more obscure.
> However...
>
>
>> Some template systems don't support PHP calls in template files. Such
>> system have bad i18n support and can't use full power of gettext tools.
>
> The original idea I believe was not to discriminate between templating
> engines.  If that is still a desired goal, I think we need to talk about
> other ways to deliver (pre)translated strings to the template. One
> possibility is creating a section in the parent PHP file of all strings
> used in the corresponding template, which loses some context, but might be
> manageable.  I'm sure there are other (more) creative ideas out there too.
>
>
> If we are now going to start a conversation about inferior templating
> systems, let's have it in a broader context.  This has never been raised
> before.  I'm personally OK with being more limited, since most people will
> just use Smarty if they don't use pure PHP anyway.

I don't see any discrimination. If template does not support i18n or has
broken i18n design, it will remain in English or any other language
selected by template designer.

we can introduce template configuration variables, that control
availability of language, theme, color and font options to end user.

-- 
Tomas