[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
Re: UU UI organization
So, you are suggesting with using approach (1).
I am also inclined to go that way - simply because it requires
less work from me (no need to modify CSP parser to do funky
things).
Problem here is that we will have concept of "themes", and if any
theme has its own message strings, they'll need an extra translation,
or we'll need an easy way to add message strings to global message
catalogs.
sergey@total-knowledge.com wrote:
> I can comment on the internationalization issue.
> I delt with several online stores where all text strings in templates were
> variables, appropriate language was displayed based on <%=language%>
> parameter which was passed to each template using query string. They
> didn't contain any html in it, all HTML tags were in templates. If I
> needed to modify any text in any language, I changed properties files on
> the server where UI strings were kept(or it could be done in DB, I guess)
>
>> One thing I am currently very unclear about is i18n support
>> for templates: There are two possible approaches to this problem.
>> One is to have all interface strings to be explicitly retrieved using
>> something like _() gettext macro, like this:
>> <HEAD><TITLE><%=_("Moooo")%></TITLE></HEAD>
>> Alternative is to modify CSP parser to do the substitution for us.
>>
>> In both cases though there is still a problem: we cannot allow
>> UI strings in templates. Or rather, we cannot allow modifying them.
>> All templates should retain them exactly the same. It's somewhat easier
>> for the first case - HTML formatting will not have to be absolutely
>> identical.
>> At the same time, second case is lot easier to read.
>>
>> Any comments/ideas will be appreciated.
>>
>> --
>> Ilya A. Volynets-Evenbakh
>> Total Knowledge. CTO
>> http://www.total-knowledge.com
>>
>>
>>
>
>
--
Ilya A. Volynets-Evenbakh
Total Knowledge. CTO
http://www.total-knowledge.com