Re: How to avoid hard-coding site-visible message strings in skin files

["Pedro I. Sanchez" <ps...@colcan.biz>]

On Thu, 2005-02-06 at 10:34 +0100, Ross Gardler wrote:
> 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.
> 
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.
 
> 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?
> 
> Ross
> 

Re: How to avoid hard-coding site-visible message strings in skin files

["Pedro I. Sanchez" <ps...@colcan.biz>]

On Thu, 2005-02-06 at 19:30 +0200, Thorsten Scherler wrote:
> Hola Pedro,
> 
> I can understand that i18n scares you a bit but I reckon it is the
> simplest solution. If you are willing to finish my job I will start it
> for the "old fashion" skins with the setup of sitemap, *one/two* props
> and you would finish the work. We are talking about 3 -6 stylesheets (3
> common/3 pelt) where you need to add <i18n:text>Published</i18n> and
> then add this key in the message catalog. I do not have enough time to
> finish that but if you want I add a patch to the issue and you can
> finish it.
> 
> salu2

I will set aside some time this weekend to read about the i18n stuff and
to try to understand what exactly has to be done. Anything you can add
is certainly welcome.

I'll be glad to help, but as I guess everyone else, I can only do it in
my spare time. So don't expect things to be done over night :|

Cheers,

-- 
Pedro

Re: How to avoid hard-coding site-visible message strings in skin files

[Thorsten Scherler <th...@apache.org>]

On Thu, 2005-06-02 at 13:12 -0400, 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.
> 
> 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.
> 
> > Am I missing something about the use case here?
> 
> Not at all. My motivation for the skin-based suggestion is just to make
> it available without having to plugin into the i18n stuff which is alien
> to me. It just seems to be a small improvement over the current
> uni-lingual Forrest code.
> 
> But certainly, if i18n is the way to go, or the "views" thing you
> mentioned before, then I'm all for it. I'm just thinking about
> possibilities.
> 

Hola Pedro,

I can understand that i18n scares you a bit but I reckon it is the
simplest solution. If you are willing to finish my job I will start it
for the "old fashion" skins with the setup of sitemap, *one/two* props
and you would finish the work. We are talking about 3 -6 stylesheets (3
common/3 pelt) where you need to add <i18n:text>Published</i18n> and
then add this key in the message catalog. I do not have enough time to
finish that but if you want I add a patch to the issue and you can
finish it.

salu2
-- 
thorsten

"Together we stand, divided we fall!" 
Hey you (Pink Floyd)

Re: How to avoid hard-coding site-visible message strings in skin files

[Ross Gardler <rg...@apache.org>]

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

Re: How to avoid hard-coding site-visible message strings in skin files

["Pedro I. Sanchez" <ps...@colcan.biz>]

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.

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.

> Am I missing something about the use case here?

Not at all. My motivation for the skin-based suggestion is just to make
it available without having to plugin into the i18n stuff which is alien
to me. It just seems to be a small improvement over the current
uni-lingual Forrest code.

But certainly, if i18n is the way to go, or the "views" thing you
mentioned before, then I'm all for it. I'm just thinking about
possibilities.


-- 
Pedro

> 
> Ross
> 

Re: How to avoid hard-coding site-visible message strings in skin files

[Ross Gardler <rg...@apache.org>]

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.

Am I missing something about the use case here?

Ross