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 17:40:47 GMT
Pedro I. Sanchez wrote:
> On Thu, 2005-02-06 at 15:27 +0100, Ross Gardler wrote:
>>Pedro I. Sanchez wrote:
>>>On Thu, 2005-02-06 at 10:34 +0100, Ross Gardler wrote:
>>>>><skinlabels name="pelt">
>>>>> <keyword name="lastPublished" value="???????"/>
>>>>> <keyword name="copyright" value="???????"/>
>>>>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.
>>>Skins will have different set of labels. "copyright" might be in all of
>>>them but "lastPublished" probably not. Hence the need to differentiate
>>>by skin name.
>>True. But what is the advantage of doing it this way over the other 
>>proposal (define by language). I see a disadvantage, that is it requires 
>>lots of duplication if we want multiple languages, whereas splitting by 
>>language only results in the odd unused element for occasional skins/views.
> You say right, "If we want multiple languages". But in the current
> setting of supporting a single language, even if it is not English, then
> the skin-based approach could make sense. And as I said before,
> uni-lingual web sites are by far more common than multi-lingual ones.
> But I have no problem with the i18n-based approach as long as I can
> manually specify the target language. I'm just trying to avoid having to
> rely on the i18n framework to get a solution going.

OK, I understand now.

> I don't have the insight into the development effort that this implies
> since I am new to Forrest. But certainly, if this would mean a
> duplication of work then it is a bad suggestion.

No, I was thrown off by the fact that you were defining tokens for each 
  skin, this made me think that there would need to be a duplication of 
tokens for skins. In fact there would be no need for this, your solution 
is identical to mine in concept if we remove my i18n attribute 
(uni-lingual site) and your skin attribute. In this case, if a skin 
doesn't understand a token it simply ignores it, so no duplication.

However, consider Thorstens overlapping mail regarding the i18n 
transformer, could that do what you need with as little effort?

I had a cursory glance and felt it probably could. Don't be thrown off 
with the talk of multi-lingual sites, it looks like it will do the kind 
of token replacement we have talked about, but will also bring with it 
the further use case of full i18n. Better yet, it already implements 
most of the logic and work on language catalogues now would be reusable 
in views since that is how they will work.


View raw message