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="???????"/>
</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.
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.
Ross