Re: How to avoid hard-coding site-visible message strings in skin files
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 Published 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
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: > > > > ... > > > > >>> > > >>> > > >>> > > >>> > > >> > > >>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 Published 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
Pedro I. Sanchez wrote: On Thu, 2005-02-06 at 19:04 +0200, Thorsten Scherler wrote: Thorsten, what would the equivalent to the above be in views? I started the work in view on it and it seems to work till the final stage. :( ...but I guess it is a bug that I hope to find quite fast. ;-) I tested with one contract and need to finish the rest. Actually I did not do it like you or Pedro suggested but the "cocoon" way with a simple i18n transformer in the contracts. That means we have a src="org.apache.cocoon.transformation.XIncludeTransformer"/> true in the output.xmap of the viewHelper.xhmtl and nothing in the skinconf.xml. IMO that would be as well the way to implement it for the "old fashion" skins but I do not know how this affect the cli. salu2 Yaick! What does this all mean for me the poor end user? How do I modify the labels? :| Hmmm... my mail in response to this has gone missing. There are some pretty good docs at http://cocoon.apache.org/2.1/userdocs/transformers/i18n-transformer.html Ross
Re: How to avoid hard-coding site-visible message strings in skin files
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: ... 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
On Thu, 2005-02-06 at 19:04 +0200, Thorsten Scherler wrote: > > Thorsten, what would the equivalent to the above be in views? > > I started the work in view on it and it seems to work till the final > stage. :( ...but I guess it is a bug that I hope to find quite fast. ;-) > I tested with one contract and need to finish the rest. > > Actually I did not do it like you or Pedro suggested but the "cocoon" > way with a simple i18n transformer in the contracts. That means we have > a > src="org.apache.cocoon.transformation.XIncludeTransformer"/> >src="org.apache.cocoon.transformation.I18nTransformer"> > >location="messages"/> >location="messages"/> > > true > > in the output.xmap of the viewHelper.xhmtl and nothing in the > skinconf.xml. > > IMO that would be as well the way to implement it for the "old fashion" > skins but I do not know how this affect the cli. > > salu2 Yaick! What does this all mean for me the poor end user? How do I modify the labels? :| -- Pedro
Re: How to avoid hard-coding site-visible message strings in skin files
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: > > ... > > >>> > >>> > >>> > >>> > >> > >>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
Thorsten Scherler wrote: On Thu, 2005-06-02 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." ... Actually I did not do it like you or Pedro suggested but the "cocoon" way with a simple i18n transformer in the contracts. That means we have a src="org.apache.cocoon.transformation.XIncludeTransformer"/> true in the output.xmap of the viewHelper.xhmtl and nothing in the skinconf.xml. IMO that would be as well the way to implement it for the "old fashion" skins but I do not know how this affect the cli. +1 especially if this is the official Cocoon way of doing things, there are some docs at http://cocoon.apache.org/2.1/userdocs/transformers/i18n-transformer.html Pedro, if you need pointers as to where in the sitemap this stuff would go for skins we can help out. Ross
Re: How to avoid hard-coding site-visible message strings in skin files
On Thu, 2005-06-02 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: > > > > > > > > > > > > > > > > > > > > > > This would work for me as long as I can also specify the language > > manually with something like > > > > > > 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: > > > > > > > > > > > > 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? I started the work in view on it and it seems to work till the final stage. :( ...but I guess it is a bug that I hope to find quite fast. ;-) I tested with one contract and need to finish the rest. Actually I did not do it like you or Pedro suggested but the "cocoon" way with a simple i18n transformer in the contracts. That means we have a true in the output.xmap of the viewHelper.xhmtl and nothing in the skinconf.xml. IMO that would be as well the way to implement it for the "old fashion" skins but I do not know how this affect the cli. 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
Pedro I. Sanchez wrote: On Thu, 2005-02-06 at 10:34 +0100, Ross Gardler wrote: ... 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
Re: How to avoid hard-coding site-visible message strings in skin files
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: > > > > > > > > > > > > > > > > > > > > > > This would work for me as long as I can also specify the language > > manually with something like > > > > > > 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: > > > > > > > > > > > > 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 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: This would work for me as long as I can also specify the language manually with something like 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: 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? Ross
How to avoid hard-coding site-visible message strings in skin files
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: This would work for me as long as I can also specify the language manually with something like 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: For a multi-lingual site I would like to have something that dynamically changes the skin and content of the site. But that is a more elaborated solution that is probably being addressed by the i18n team (?). I'm not sure if a solution that simply gets the "hard-coded" labels out of the way has to necessarily be part of the i18n "framework". Anyway, with your help and guidance I'd like to put some effort implementing a solution of some kind. Comments? -- Pedro