[prev in list] [next in list] [prev in thread] [next in thread] 

List:       squirrelmail-devel
Subject:    [SM-DEVEL] Re: CVS: squirrelmail/templates/default page_header.tpl, NONE,
From:       "Fredrik Jervfors" <sqm_admin () fimbul ! net>
Date:       2006-01-30 10:25:00
Message-ID: 26814.193.12.204.98.1138616700.squirrel () webmail ! fimbul ! net
[Download RAW message or body]

>>>>>> // 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');
>>>>>
>>>>> 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.
>
> The "discrimination" is that we *could* conceivably provide translated
> strings, but we choose not to.  It is technically possible that a template
> system may not even be PHP-enabled or for some other reason has no access
> to facilities powerful enough to do on-the-fly string translating.
>
>> we can introduce template configuration variables, that control
>> availability of language, theme, color and font options to end user.
>
> What are you suggesting?  How do we provide a language selection for
> the end-user for a template that has no gettext support if we are not
> doing translations in the core?

I'm no software design wiz, but it's possible to use three or more layers.
First layer would be the core functionality; the second layer would be
putting the data in some structure which is then passed to the third layer
- the UI. gettext functions could be used in the second layer, which is
used for preparing the data from the core to the UI. This would mean that
translations are provided by SquirrelMail and not the template engine,
thus making it possible to provide translations the same way we do today.

If we want SquirrelMail to work with any templating system, we need to
provide the first and second layer, the second layer being a well defined
API which the template engine can use. We also need to provide a default
template system, so SquirrelMail can provide a UI included in the
distribution, but any admin may choose to replace the third layer with the
template engine of their choice.

Or maybe I'm just misunderstanding the topic discussed in this thread.
Shouldn't this discussion be on the DEVEL list instead of CVS list, by the
way?

Sincerely,
Fredrik.



-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642
--
squirrelmail-devel mailing list
Posting Guidelines: http://www.squirrelmail.org/wiki/MailingListPostingGuidelines
List Address: squirrelmail-devel@lists.sourceforge.net
List Archives: http://news.gmane.org/thread.php?group=gmane.mail.squirrelmail.devel
List Archives: http://sourceforge.net/mailarchive/forum.php?forum_id=7139
List Info: https://lists.sourceforge.net/lists/listinfo/squirrelmail-devel
[prev in list] [next in list] [prev in thread] [next in thread]