forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ross Gardler <>
Subject Re: How to avoid hard-coding site-visible message strings in skin files
Date Thu, 02 Jun 2005 09:34:03 GMT
Pedro I. Sanchez wrote:
> Hello,
> A few days ago I added issue FOR-506 on this topic. This is my original
> message:
>   "Text strings like "Copyright", "Published", and "Search" are
>    hardcoded into skin files like site2xhtml.xsl. When creating web
>    sites in languages other than English the web developer is forced
>    to create local versions of these skin files with the appropriated
>    translations.
>    Instead, the DTD for the skinconf.xml should be improved to allow
>    these translations to be specified in this file. This would make
>    Forrest much easier to use."
> Ross suggested the following as an example of a possible solution:
> <i18n lang="en">
>   <token name="lastPublished" value="Last Published"/>
>   <token name="copyright" value="Copyright"/>
> </i18n>
> <i18n lang="??">
>   <token name="lastPublished" value="???????"/>
>   <token name="copyright" value="???????"/>
> </i18n>
> This would work for me as long as I can also specify the language
> manually with something like
> <i18n lan="en" />

I'm not sure how the existing i18n thing works, but there is a way to 
specify what language you want the menus in, so I guess you would use 
the same mechanism.

> And this, because at this moment I am more interested in a uni-lingual
> (non-English) web site rather than in a multi-lingual one. I believe
> the former is by far the most common case.
> Another possibility could be something like this, totally independent
> of a "lang" setting and just driven by the skin:
> <skinlabels name="pelt">
>   <keyword name="lastPublished" value="???????"/>
>   <keyword name="copyright" value="???????"/>
> </skinlabels>

I don't see the value in this. I would imagine that regardless of what 
skin you are using you would want the same values to appear in the 
output site.

One thing we must be sure of is that any solution implemented now can be 
integrated into Thorstens work on views. In fact, it would be better to 
see these changes go directly into views.

Thorsten, what would the equivalent to the above be in views?


View raw message