You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@forrest.apache.org by Helena Edelson <he...@greenjaguar.com> on 2005/12/20 19:00:21 UTC
access control - user roles by sitemap
Is there any way using sitemap to manage user roles
via a login to control roles
access to app pages for user_role_a
disallow access for user_role_b type of thing?
anyone done this?
helena
Re: access control - user roles by sitemap
Posted by David Crossley <cr...@apache.org>.
Helena Edelson wrote:
> Is there any way using sitemap to manage user roles
> via a login to control roles
> access to app pages for user_role_a
> disallow access for user_role_b type of thing?
>
> anyone done this?
Use the capablities of the HTTPD server.
If using forrest in static mode then .htaccess etc.
If using forrest in webapp mode then .htaccess
and ProxyPass
http://wiki.apache.org/cocoon/ApacheModProxy
Alternatively use the capabilities of the servlet
container as someone already suggested.
-David
Re: access control - user roles by sitemap
Posted by Gunther Sablon <Gu...@luciad.com>.
Dear Helena,
- the specification of the mechanism for authentication is specified in
server.xml.
In particular, look for the different example realm sections.
- the specification of the authorisation can be specified in web.xml.
In particular, in the security-constraint section you can specify
a) a web-resource-collection section which specifies a url-pattern
b) an auth-constraint section which specifies a sequence of roles.
In login-config you have to specify the authentication method.
In security-roles you have to list the different roles used in the
auth-constraint sections.
Best regards,
Gunther
Helena Edelson wrote:
> That should work,
> are you saying to handle auth in server.xml and parts in web.xml?
>
> thank you.
> helena
>
> Gunther Sablon wrote:
>
>> Hi,
>> we are running forrest as a webapp in Tomcat.
>> We use the authentication mechanisms of Tomcat:
>> - before we had users in tomcat_users.xml; currently they are in
>> LDAP (can be setup in server.xml)
>> - web.xml specifies the parts of the site that need authentication.
>> There is no connection to the sitemap, so maybe I have misunderstood
>> your question...
>> Best regards,
>> Gunther
>>
>> Helena Edelson wrote:
>>
>>> thanks. will do.
>>> i am also working on i18n stuff. when i figure it out,
>>> i was thinking it might be help ful to write a how to.
>>> everything so far seems
>>> fractured in terms of the steps to take to implement.
>>> there are many if then's and info is everywhere, from
>>> docs to jira to cocoon docs..
>>>
>>> helena
>>>
>>> Ross Gardler wrote:
>>>
>>>> Helena Edelson wrote:
>>>>
>>>>> Is there any way using sitemap to manage user roles
>>>>> via a login to control roles
>>>>> access to app pages for user_role_a
>>>>> disallow access for user_role_b type of thing?
>>>>
>>>>
>>>>
>>>> Depends on whether you are running in dynamic mode or not.
>>>>
>>>> In static mode you would have to use the mechanisms provided by
>>>> your web server for protecting access to certain resources. On the
>>>> Apache HTTPD server that would be using .htaccess files.
>>>>
>>>> In this case you simply provide the relevant .htaccess files in
>>>> along with your XDocs and they will (theoretically) be copied over
>>>> when you build the site. I say theoretically because I have not,
>>>> personally, tried this. Let us know if you try it and it works
>>>> (preferably in the form of a contribution to our docs).
>>>>
>>>> If you are running in dynamic mode you can, theoretically, use the
>>>> Cocoon Authentication framework [1]. Again, I say theoretically
>>>> because it I'm not aware of anyone having done this yet. If you
>>>> want to go this route then it is really a dev topic, so please move
>>>> this to the dev list where we can help guide you and (hopefully)
>>>> you can write us a How-To on making it work.
>>>>
>>>> Ross
>>>>
>>>> [1]
>>>> http://cocoon.apache.org/2.1/developing/webapps/authentication.html
>>>>
>>>>
>>
--
Gunther Sablon
Luciad ** Parijsstraat 74 ** 3000 Leuven
tel: +32 / 16 / 26 28 30
mailto:Gunther.Sablon@luciad.com
Re: access control - user roles by sitemap
Posted by Helena Edelson <he...@greenjaguar.com>.
That should work,
are you saying to handle auth in server.xml and parts in web.xml?
thank you.
helena
Gunther Sablon wrote:
> Hi,
> we are running forrest as a webapp in Tomcat.
> We use the authentication mechanisms of Tomcat:
> - before we had users in tomcat_users.xml; currently they are in LDAP
> (can be setup in server.xml)
> - web.xml specifies the parts of the site that need authentication.
> There is no connection to the sitemap, so maybe I have misunderstood
> your question...
> Best regards,
> Gunther
>
> Helena Edelson wrote:
>
>> thanks. will do.
>> i am also working on i18n stuff. when i figure it out,
>> i was thinking it might be help ful to write a how to.
>> everything so far seems
>> fractured in terms of the steps to take to implement.
>> there are many if then's and info is everywhere, from
>> docs to jira to cocoon docs..
>>
>> helena
>>
>> Ross Gardler wrote:
>>
>>> Helena Edelson wrote:
>>>
>>>> Is there any way using sitemap to manage user roles
>>>> via a login to control roles
>>>> access to app pages for user_role_a
>>>> disallow access for user_role_b type of thing?
>>>
>>>
>>>
>>> Depends on whether you are running in dynamic mode or not.
>>>
>>> In static mode you would have to use the mechanisms provided by your
>>> web server for protecting access to certain resources. On the Apache
>>> HTTPD server that would be using .htaccess files.
>>>
>>> In this case you simply provide the relevant .htaccess files in
>>> along with your XDocs and they will (theoretically) be copied over
>>> when you build the site. I say theoretically because I have not,
>>> personally, tried this. Let us know if you try it and it works
>>> (preferably in the form of a contribution to our docs).
>>>
>>> If you are running in dynamic mode you can, theoretically, use the
>>> Cocoon Authentication framework [1]. Again, I say theoretically
>>> because it I'm not aware of anyone having done this yet. If you want
>>> to go this route then it is really a dev topic, so please move this
>>> to the dev list where we can help guide you and (hopefully) you can
>>> write us a How-To on making it work.
>>>
>>> Ross
>>>
>>> [1] http://cocoon.apache.org/2.1/developing/webapps/authentication.html
>>>
>>>
>
Re: access control - user roles by sitemap
Posted by Gunther Sablon <Gu...@luciad.com>.
Hi,
we are running forrest as a webapp in Tomcat.
We use the authentication mechanisms of Tomcat:
- before we had users in tomcat_users.xml; currently they are in LDAP
(can be setup in server.xml)
- web.xml specifies the parts of the site that need authentication.
There is no connection to the sitemap, so maybe I have misunderstood
your question...
Best regards,
Gunther
Helena Edelson wrote:
> thanks. will do.
> i am also working on i18n stuff. when i figure it out,
> i was thinking it might be help ful to write a how to.
> everything so far seems
> fractured in terms of the steps to take to implement.
> there are many if then's and info is everywhere, from
> docs to jira to cocoon docs..
>
> helena
>
> Ross Gardler wrote:
>
>> Helena Edelson wrote:
>>
>>> Is there any way using sitemap to manage user roles
>>> via a login to control roles
>>> access to app pages for user_role_a
>>> disallow access for user_role_b type of thing?
>>
>>
>> Depends on whether you are running in dynamic mode or not.
>>
>> In static mode you would have to use the mechanisms provided by your
>> web server for protecting access to certain resources. On the Apache
>> HTTPD server that would be using .htaccess files.
>>
>> In this case you simply provide the relevant .htaccess files in along
>> with your XDocs and they will (theoretically) be copied over when you
>> build the site. I say theoretically because I have not, personally,
>> tried this. Let us know if you try it and it works (preferably in the
>> form of a contribution to our docs).
>>
>> If you are running in dynamic mode you can, theoretically, use the
>> Cocoon Authentication framework [1]. Again, I say theoretically
>> because it I'm not aware of anyone having done this yet. If you want
>> to go this route then it is really a dev topic, so please move this
>> to the dev list where we can help guide you and (hopefully) you can
>> write us a How-To on making it work.
>>
>> Ross
>>
>> [1] http://cocoon.apache.org/2.1/developing/webapps/authentication.html
>>
>>
--
Gunther Sablon
Luciad ** Parijsstraat 74 ** 3000 Leuven
tel: +32 / 16 / 26 28 30
mailto:Gunther.Sablon@luciad.com
Re: i18n and documentation
Posted by Helena Edelson <he...@greenjaguar.com>.
Is the i8n usage callable or instantiated by multiple init params in
sitemap similar to web.xml servlet init param entries but wrapped in
test's for the selected language?
How do we implement it across the session for all session requests?
Specifically, do we have to set up this logic for each transformed file
in sitemap (xsl:stylesheet) and also for each file of type
document-v20.dtd that is only transformed through the common skins?
Might we create a reusable component or, in sitemap terms, a resource
(?), to run it through? Is this done already?
Helena
Helena Edelson wrote:
> thank you David.
> When I get multiple language support working in one live site i'm
> working on now,
> I'll spend some time writing a how to. I hope to integrate at least ten.
> Will review previously implemented work to date.
> Some time in January a how to should be ready.
>
> Helena
>
> David Crossley wrote:
>
>>Ross Gardler wrote:
>>
>>
>>>Helena Edelson wrote:
>>>
>>>
>>>>i am also working on i18n stuff. when i figure it out,
>>>>i was thinking it might be help ful to write a how to.
>>>>everything so far seems
>>>>fractured in terms of the steps to take to implement.
>>>>there are many if then's and info is everywhere, from
>>>>docs to jira to cocoon docs..
>>>>
>>>>
>>> te a start is what is needed.
>>>
>>>
>>
>>Helena, please ask questions on the mailing list
>>rather than via the issue tracker. Here are some
>>notes that might help you ...
>>
>>Yes, use one catalogue file per language.
>>
>>The map:serialise is an empty element. The patch
>>that you looked at was old and has a syntax error
>>with an extra closing tag for a map:generator.
>>It has already been applied and has some subsequent
>>changes which were done prior to 0.7 release.
>>
>>Anyway you should not need to look at the guts
>>of Forrest just to use i18n.
>>
>>Remember that we only maintain the "pelt" skin.
>>So for the i18n of menus, it might only work for
>>pelt. The i18n of content should be independent
>>of the skin.
>>
>>See the notes in forrest.properties about i18n.
>>
>>See a 'forrest seed site'.
>>
>>See Cheche's blog entry. Google: i18n forrest
>>Beware, some changes have been made since he wrote.
>>
>>There is some recent discussion about i18n in
>>the forrest-dev mailing archives. Guess about
>>three months ago. I tried to explain the processing
>>to Gav and we fixed a bug which produced invalid
>>html output (only fixed in trunk at svn r263870
>>and r264136). The i18n still worked.
>>
>>Yes we do need to bring it all together
>>in the forrest docs.
>>
>>-David
>>
>>
>>
>>
Automatic translation of content (Re: i18n usage)
Posted by Ross Gardler <rg...@apache.org>.
Helena Edelson wrote:
> embarrasing question: Is it the case that if we want multiple languages
> to be supported, we have to supply the
> translations per document page? Nothing will automatically translate for
> the app like how the online
> translation engines do it? Would be great to plug something like that in
> and simply do:
Embarrasing, why? It's a great idea.
Forrest doesn't do this, but an plugin that retrieved the content from a
translation engine would be a great contribution. Of course, the
translations would be less than perfect, but it is better than nothing.
If anyone wants to tackle this it's a great dev topic (and fairly easy
to do with guidance).
Ross
Re: i18n usage
Posted by Torsten Stolpmann <To...@verit.de>.
Helena Edelson wrote:
> I have tabs_(lang-code).xml and menu_(lang-code).xml for each language,
> yet still the index.(lang-code).xml is the only one returned.
> Could my issue lie perhaps in the translations/langcode.xml file?
> I added de,fr,no to what is in the distribution yet even with my browser
> in de, still no luck with menu, tabs or CommonMessages_de.xml for skin.
>
> I must be missing one step?
>
After a good nights sleep I remember some rare cases where restarting
the web-application was actually needed to propagate the changes I made.
Since I don't see anything fundamentally flawed, trying to restart might
be an option here.
Regards,
Torsten
> helena
>
> Torsten Stolpmann wrote:
>
>>
>>
>> Helena Edelson wrote:
>>
>>> With things as they are now in my test, if my browser is on language
>>> n, the document (lang n) is served but I haven't gotten it to also to
>>> tabs and menues yet I see on other forrest sites it is working so I
>>> think I'm missing one thing.
>>>
>> looking at your post again - it is 'menu_es.xml' not 'menus_es.xml'
>> (just to make sure).
>>
>> I'll give an example from our sources (HTH):
>>
>> documentation/content/xdocs/tabs.xml:
>>
>> <tabs ...>
>> <tab label="Products" dir="products" indexfile="index.html"/>
>> ...
>> </tabs>
>>
>> translations/tabs_de.xml:
>>
>> <catalogue xml:lang="de">
>> <message key="Products">Produkte</message>
>> ...
>> </catalogue>
>>
>> translations/tabs_en.xml:
>>
>> <catalogue xml:lang="en">
>> <message key="Produkte">Products</message>
>> ...
>> </catalogue>
>>
>>> In my initial test I used the file naming conv index.es.xml and
>>> changed it not thinking it made a difference but I shall change it
>>> back and see.
>>>
>> Please do so.
>>
>>> *Do you mean you didn't have to modivy or add anything to sitemap?
>>>
>> Exactly.
>>
>>> Thanks,
>>> Helena
>>>
>> No problem.
>>
>> Torsten
>>
>>> Torsten Stolpmann wrote:
>>>
>>>> Hi,
>>>>
>>>> first of all:
>>>>
>>>> Our site at http://www.verit.de is already running in i18n-mode
>>>> (currently only de and en is supported) using the servlet approach
>>>> and dynamic language detection using forrest 0.7.
>>>>
>>>> I think from your description you are almost there:
>>>>
>>>> - Setting project.i18n=true in forrest.properties is the right thing
>>>> to do.
>>>>
>>>> - In contradiction to the documentation try naming your web pages
>>>> index.es.xml instead of index_es.xml. We got that from studying the
>>>> error logs closely and suspect the documentation is plain wrong
>>>> here. Can someone from the dev team comment on this? We also renamed
>>>> our default language files accordingly (index.en.xml in your case).
>>>>
>>>> - You are right about menus_es.xml, languages_es.xml, tabs_es.xml
>>>> this is what we did also and it worked as advertised.
>>>>
>>>> - Yes, to my knowledge all your pages have to be translated
>>>> seperatly. Especially if you want to support 10 or more languages
>>>> this will make structural changes in your pages cumbersome to
>>>> maintain. We already suffer from this with just our two languages.
>>>>
>>>> The above scheme worked for translating almost everything but some
>>>> settings defined in skinconf.xml (e.g. the feedback link).
>>>> Especially we never had to touch anything on the sitemap level.
>>>>
>>>> HTH,
>>>>
>>>> Torsten
>>>>
>>>>
>>>>
>>>>
>>>> Helena Edelson wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>> It doesn't make sense to have to add this:
>>>>> modify |cli.xconf| and add this line:
>>>>> <uri type=”insert” src-prefix=”" src=”index.html”
>>>>> follow-links=”false” dest=”/var/tmp/fs/build/i18n/*.en” />
>>>>> if you are in a live web environment - if you need mulitiple
>>>>> languages.
>>>>>
>>>>> If forrest.properties setting is project.i18n=true,
>>>>> and a user-client browser is language n,
>>>>> is it only that we need to create all the catalogues, menus and
>>>>> tabs for x lanuages we will support and the browser does the rest -
>>>>> i.e. translate the document portion of the page
>>>>> ?
>>>>>
>>>>> Also I can not find anything difinitive on modifying sitemap to
>>>>> handle i18n
>>>>> I see forrest.xmap does a few things, I see the F7 site2html.xsl
>>>>> includes
>>>>> xmlns:i18n="http://apache.org/cocoon/i18n/2.1"
>>>>> exclude-result-prefixes="i18n"
>>>>> in the xsl:stylesheet declaration so I am not sure what a dev needs
>>>>> to do on the config side,
>>>>> as it seems most of the work is done already in the guts of forrest
>>>>> itself.
>>>>>
>>>>> thank you,
>>>>> helena
>>>>>
>>>>> Helena Edelson wrote:
>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> I tested the i18n features of forrest-0.7-dev
>>>>>> - made a new dir
>>>>>> - fresh forrest seed
>>>>>> - turned forrest.i18n on
>>>>>> - added index_es.xml to .../xdocs/
>>>>>> - (menu_es.xml, languages_es.xml, tabs_es.xml in distro)
>>>>>> - index.xml file was renamed index_es.xml
>>>>>>
>>>>>> modified index_es.xml to display some Spanish text
>>>>>> Cheche's blog suggests to do this which I did as well:
>>>>>> |added project.configfile=/var/tmp/fs/cli.xconf| to
>>>>>> |forrest.properties|
>>>>>> modify |cli.xconf| and add this line:
>>>>>> <uri type=”insert” src-prefix=”" src=”index.html”
>>>>>> follow-links=”false” dest=”/var/tmp/fs/build/i18n/*.en” />
>>>>>>
>>>>>> I looked in my build/tmp/projfilters.properties and found that
>>>>>> even though I set project.i18n=true in forrest.properties,
>>>>>> ant projfilters.properties output is project.i18n=false.
>>>>>> Why might this be?
>>>>>>
>>>>>> My index_es.html is served (locale in browser set to 'es') yet the
>>>>>> menu_es.xml does not.
>>>>>> I know from mail-archives and others that translation of both menu
>>>>>> and doc can work.
>>>>>>
>>>>>> embarrasing question: Is it the case that if we want multiple
>>>>>> languages to be supported, we have to supply the
>>>>>> translations per document page? Nothing will automatically
>>>>>> translate for the app like how the online
>>>>>> translation engines do it? Would be great to plug something like
>>>>>> that in and simply do:
>>>>>>
>>>>>> localhost:8888/index.html?locale=es or
>>>>>> localhost:8888/index.html?locale=fr
>>>>>>
>>>>>>
>>>>>>
>>>>>> cheers,
>>>>>> helena
>>>>>>
>>>>>>
>>>>>>> David Crossley wrote:
>>>>>>>
>>>>>>>> Ross Gardler wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>>> Helena Edelson wrote:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> i am also working on i18n. when i figure it out,
>>>>>>>>>> i was thinking it might be help ful to write a how to.
>>>>>>>>>> everything so far seems
>>>>>>>>>> fractured in terms of the steps to take to implement.
>>>>>>>>>> there are many if then's and info is everywhere, from
>>>>>>>>>> docs to jira to cocoon docs..
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> te a start is what is needed.
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Yes, use one catalogue file per language.
>>>>>>>>
>>>>>>>> Yes we do need to bring it all together
>>>>>>>> in the forrest docs.
>>>>>>>>
>>>>>>>> -David
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>
>>
Re: i18n usage
Posted by Torsten Stolpmann <To...@verit.de>.
Helena Edelson wrote:
> I have tabs_(lang-code).xml and menu_(lang-code).xml for each language,
> yet still the index.(lang-code).xml is the only one returned.
> Could my issue lie perhaps in the translations/langcode.xml file?
I don't think so, nothing unusual over here.
> I added de,fr,no to what is in the distribution yet even with my browser
> in de, still no luck with menu, tabs or CommonMessages_de.xml for skin.
>
The only advice I could give at the moment is to watch the error/debug
logs in build/WEB-INF/logs closely. This is what gave me the final clues.
> I must be missing one step?
You are very close.
>
> helena
>
Torsten
> Torsten Stolpmann wrote:
>
>>
>>
>> Helena Edelson wrote:
>>
>>> With things as they are now in my test, if my browser is on language
>>> n, the document (lang n) is served but I haven't gotten it to also to
>>> tabs and menues yet I see on other forrest sites it is working so I
>>> think I'm missing one thing.
>>>
>> looking at your post again - it is 'menu_es.xml' not 'menus_es.xml'
>> (just to make sure).
>>
>> I'll give an example from our sources (HTH):
>>
>> documentation/content/xdocs/tabs.xml:
>>
>> <tabs ...>
>> <tab label="Products" dir="products" indexfile="index.html"/>
>> ...
>> </tabs>
>>
>> translations/tabs_de.xml:
>>
>> <catalogue xml:lang="de">
>> <message key="Products">Produkte</message>
>> ...
>> </catalogue>
>>
>> translations/tabs_en.xml:
>>
>> <catalogue xml:lang="en">
>> <message key="Produkte">Products</message>
>> ...
>> </catalogue>
>>
>>> In my initial test I used the file naming conv index.es.xml and
>>> changed it not thinking it made a difference but I shall change it
>>> back and see.
>>>
>> Please do so.
>>
>>> *Do you mean you didn't have to modivy or add anything to sitemap?
>>>
>> Exactly.
>>
>>> Thanks,
>>> Helena
>>>
>> No problem.
>>
>> Torsten
>>
>>> Torsten Stolpmann wrote:
>>>
>>>> Hi,
>>>>
>>>> first of all:
>>>>
>>>> Our site at http://www.verit.de is already running in i18n-mode
>>>> (currently only de and en is supported) using the servlet approach
>>>> and dynamic language detection using forrest 0.7.
>>>>
>>>> I think from your description you are almost there:
>>>>
>>>> - Setting project.i18n=true in forrest.properties is the right thing
>>>> to do.
>>>>
>>>> - In contradiction to the documentation try naming your web pages
>>>> index.es.xml instead of index_es.xml. We got that from studying the
>>>> error logs closely and suspect the documentation is plain wrong
>>>> here. Can someone from the dev team comment on this? We also renamed
>>>> our default language files accordingly (index.en.xml in your case).
>>>>
>>>> - You are right about menus_es.xml, languages_es.xml, tabs_es.xml
>>>> this is what we did also and it worked as advertised.
>>>>
>>>> - Yes, to my knowledge all your pages have to be translated
>>>> seperatly. Especially if you want to support 10 or more languages
>>>> this will make structural changes in your pages cumbersome to
>>>> maintain. We already suffer from this with just our two languages.
>>>>
>>>> The above scheme worked for translating almost everything but some
>>>> settings defined in skinconf.xml (e.g. the feedback link).
>>>> Especially we never had to touch anything on the sitemap level.
>>>>
>>>> HTH,
>>>>
>>>> Torsten
>>>>
>>>>
>>>>
>>>>
>>>> Helena Edelson wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>> It doesn't make sense to have to add this:
>>>>> modify |cli.xconf| and add this line:
>>>>> <uri type=”insert” src-prefix=”" src=”index.html”
>>>>> follow-links=”false” dest=”/var/tmp/fs/build/i18n/*.en” />
>>>>> if you are in a live web environment - if you need mulitiple
>>>>> languages.
>>>>>
>>>>> If forrest.properties setting is project.i18n=true,
>>>>> and a user-client browser is language n,
>>>>> is it only that we need to create all the catalogues, menus and
>>>>> tabs for x lanuages we will support and the browser does the rest -
>>>>> i.e. translate the document portion of the page
>>>>> ?
>>>>>
>>>>> Also I can not find anything difinitive on modifying sitemap to
>>>>> handle i18n
>>>>> I see forrest.xmap does a few things, I see the F7 site2html.xsl
>>>>> includes
>>>>> xmlns:i18n="http://apache.org/cocoon/i18n/2.1"
>>>>> exclude-result-prefixes="i18n"
>>>>> in the xsl:stylesheet declaration so I am not sure what a dev needs
>>>>> to do on the config side,
>>>>> as it seems most of the work is done already in the guts of forrest
>>>>> itself.
>>>>>
>>>>> thank you,
>>>>> helena
>>>>>
>>>>> Helena Edelson wrote:
>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> I tested the i18n features of forrest-0.7-dev
>>>>>> - made a new dir
>>>>>> - fresh forrest seed
>>>>>> - turned forrest.i18n on
>>>>>> - added index_es.xml to .../xdocs/
>>>>>> - (menu_es.xml, languages_es.xml, tabs_es.xml in distro)
>>>>>> - index.xml file was renamed index_es.xml
>>>>>>
>>>>>> modified index_es.xml to display some Spanish text
>>>>>> Cheche's blog suggests to do this which I did as well:
>>>>>> |added project.configfile=/var/tmp/fs/cli.xconf| to
>>>>>> |forrest.properties|
>>>>>> modify |cli.xconf| and add this line:
>>>>>> <uri type=”insert” src-prefix=”" src=”index.html”
>>>>>> follow-links=”false” dest=”/var/tmp/fs/build/i18n/*.en” />
>>>>>>
>>>>>> I looked in my build/tmp/projfilters.properties and found that
>>>>>> even though I set project.i18n=true in forrest.properties,
>>>>>> ant projfilters.properties output is project.i18n=false.
>>>>>> Why might this be?
>>>>>>
>>>>>> My index_es.html is served (locale in browser set to 'es') yet the
>>>>>> menu_es.xml does not.
>>>>>> I know from mail-archives and others that translation of both menu
>>>>>> and doc can work.
>>>>>>
>>>>>> embarrasing question: Is it the case that if we want multiple
>>>>>> languages to be supported, we have to supply the
>>>>>> translations per document page? Nothing will automatically
>>>>>> translate for the app like how the online
>>>>>> translation engines do it? Would be great to plug something like
>>>>>> that in and simply do:
>>>>>>
>>>>>> localhost:8888/index.html?locale=es or
>>>>>> localhost:8888/index.html?locale=fr
>>>>>>
>>>>>>
>>>>>>
>>>>>> cheers,
>>>>>> helena
>>>>>>
>>>>>>
>>>>>>> David Crossley wrote:
>>>>>>>
>>>>>>>> Ross Gardler wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>>> Helena Edelson wrote:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> i am also working on i18n. when i figure it out,
>>>>>>>>>> i was thinking it might be help ful to write a how to.
>>>>>>>>>> everything so far seems
>>>>>>>>>> fractured in terms of the steps to take to implement.
>>>>>>>>>> there are many if then's and info is everywhere, from
>>>>>>>>>> docs to jira to cocoon docs..
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> te a start is what is needed.
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Yes, use one catalogue file per language.
>>>>>>>>
>>>>>>>> Yes we do need to bring it all together
>>>>>>>> in the forrest docs.
>>>>>>>>
>>>>>>>> -David
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>
>>
Re: i18n usage
Posted by Helena Edelson <he...@greenjaguar.com>.
I have tabs_(lang-code).xml and menu_(lang-code).xml for each language,
yet still the index.(lang-code).xml is the only one returned.
Could my issue lie perhaps in the translations/langcode.xml file?
I added de,fr,no to what is in the distribution yet even with my browser
in de, still no luck with menu, tabs or CommonMessages_de.xml for skin.
I must be missing one step?
helena
Torsten Stolpmann wrote:
>
>
> Helena Edelson wrote:
>
>> With things as they are now in my test, if my browser is on language
>> n, the document (lang n) is served but I haven't gotten it to also to
>> tabs and menues yet I see on other forrest sites it is working so I
>> think I'm missing one thing.
>>
> looking at your post again - it is 'menu_es.xml' not 'menus_es.xml'
> (just to make sure).
>
> I'll give an example from our sources (HTH):
>
> documentation/content/xdocs/tabs.xml:
>
> <tabs ...>
> <tab label="Products" dir="products" indexfile="index.html"/>
> ...
> </tabs>
>
> translations/tabs_de.xml:
>
> <catalogue xml:lang="de">
> <message key="Products">Produkte</message>
> ...
> </catalogue>
>
> translations/tabs_en.xml:
>
> <catalogue xml:lang="en">
> <message key="Produkte">Products</message>
> ...
> </catalogue>
>
>> In my initial test I used the file naming conv index.es.xml and
>> changed it not thinking it made a difference but I shall change it
>> back and see.
>>
> Please do so.
>
>> *Do you mean you didn't have to modivy or add anything to sitemap?
>>
> Exactly.
>
>> Thanks,
>> Helena
>>
> No problem.
>
> Torsten
>
>> Torsten Stolpmann wrote:
>>
>>> Hi,
>>>
>>> first of all:
>>>
>>> Our site at http://www.verit.de is already running in i18n-mode
>>> (currently only de and en is supported) using the servlet approach
>>> and dynamic language detection using forrest 0.7.
>>>
>>> I think from your description you are almost there:
>>>
>>> - Setting project.i18n=true in forrest.properties is the right thing
>>> to do.
>>>
>>> - In contradiction to the documentation try naming your web pages
>>> index.es.xml instead of index_es.xml. We got that from studying the
>>> error logs closely and suspect the documentation is plain wrong
>>> here. Can someone from the dev team comment on this? We also renamed
>>> our default language files accordingly (index.en.xml in your case).
>>>
>>> - You are right about menus_es.xml, languages_es.xml, tabs_es.xml
>>> this is what we did also and it worked as advertised.
>>>
>>> - Yes, to my knowledge all your pages have to be translated
>>> seperatly. Especially if you want to support 10 or more languages
>>> this will make structural changes in your pages cumbersome to
>>> maintain. We already suffer from this with just our two languages.
>>>
>>> The above scheme worked for translating almost everything but some
>>> settings defined in skinconf.xml (e.g. the feedback link).
>>> Especially we never had to touch anything on the sitemap level.
>>>
>>> HTH,
>>>
>>> Torsten
>>>
>>>
>>>
>>>
>>> Helena Edelson wrote:
>>>
>>>> Hi,
>>>>
>>>> It doesn't make sense to have to add this:
>>>> modify |cli.xconf| and add this line:
>>>> <uri type=”insert” src-prefix=”" src=”index.html”
>>>> follow-links=”false” dest=”/var/tmp/fs/build/i18n/*.en” />
>>>> if you are in a live web environment - if you need mulitiple
>>>> languages.
>>>>
>>>> If forrest.properties setting is project.i18n=true,
>>>> and a user-client browser is language n,
>>>> is it only that we need to create all the catalogues, menus and
>>>> tabs for x lanuages we will support and the browser does the rest -
>>>> i.e. translate the document portion of the page
>>>> ?
>>>>
>>>> Also I can not find anything difinitive on modifying sitemap to
>>>> handle i18n
>>>> I see forrest.xmap does a few things, I see the F7 site2html.xsl
>>>> includes
>>>> xmlns:i18n="http://apache.org/cocoon/i18n/2.1"
>>>> exclude-result-prefixes="i18n"
>>>> in the xsl:stylesheet declaration so I am not sure what a dev needs
>>>> to do on the config side,
>>>> as it seems most of the work is done already in the guts of forrest
>>>> itself.
>>>>
>>>> thank you,
>>>> helena
>>>>
>>>> Helena Edelson wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>> I tested the i18n features of forrest-0.7-dev
>>>>> - made a new dir
>>>>> - fresh forrest seed
>>>>> - turned forrest.i18n on
>>>>> - added index_es.xml to .../xdocs/
>>>>> - (menu_es.xml, languages_es.xml, tabs_es.xml in distro)
>>>>> - index.xml file was renamed index_es.xml
>>>>>
>>>>> modified index_es.xml to display some Spanish text
>>>>> Cheche's blog suggests to do this which I did as well:
>>>>> |added project.configfile=/var/tmp/fs/cli.xconf| to
>>>>> |forrest.properties|
>>>>> modify |cli.xconf| and add this line:
>>>>> <uri type=”insert” src-prefix=”" src=”index.html”
>>>>> follow-links=”false” dest=”/var/tmp/fs/build/i18n/*.en” />
>>>>>
>>>>> I looked in my build/tmp/projfilters.properties and found that
>>>>> even though I set project.i18n=true in forrest.properties,
>>>>> ant projfilters.properties output is project.i18n=false.
>>>>> Why might this be?
>>>>>
>>>>> My index_es.html is served (locale in browser set to 'es') yet the
>>>>> menu_es.xml does not.
>>>>> I know from mail-archives and others that translation of both menu
>>>>> and doc can work.
>>>>>
>>>>> embarrasing question: Is it the case that if we want multiple
>>>>> languages to be supported, we have to supply the
>>>>> translations per document page? Nothing will automatically
>>>>> translate for the app like how the online
>>>>> translation engines do it? Would be great to plug something like
>>>>> that in and simply do:
>>>>>
>>>>> localhost:8888/index.html?locale=es or
>>>>> localhost:8888/index.html?locale=fr
>>>>>
>>>>>
>>>>>
>>>>> cheers,
>>>>> helena
>>>>>
>>>>>
>>>>>> David Crossley wrote:
>>>>>>
>>>>>>> Ross Gardler wrote:
>>>>>>>
>>>>>>>
>>>>>>>> Helena Edelson wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>>> i am also working on i18n. when i figure it out,
>>>>>>>>> i was thinking it might be help ful to write a how to.
>>>>>>>>> everything so far seems
>>>>>>>>> fractured in terms of the steps to take to implement.
>>>>>>>>> there are many if then's and info is everywhere, from
>>>>>>>>> docs to jira to cocoon docs..
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> te a start is what is needed.
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Yes, use one catalogue file per language.
>>>>>>>
>>>>>>> Yes we do need to bring it all together
>>>>>>> in the forrest docs.
>>>>>>>
>>>>>>> -David
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>
>
Re: i18n usage
Posted by Torsten Stolpmann <To...@verit.de>.
Helena Edelson wrote:
> With things as they are now in my test, if my browser is on language n,
> the document (lang n) is served but I haven't gotten it to also to tabs
> and menues yet I see on other forrest sites it is working so I think I'm
> missing one thing.
>
looking at your post again - it is 'menu_es.xml' not 'menus_es.xml'
(just to make sure).
I'll give an example from our sources (HTH):
documentation/content/xdocs/tabs.xml:
<tabs ...>
<tab label="Products" dir="products" indexfile="index.html"/>
...
</tabs>
translations/tabs_de.xml:
<catalogue xml:lang="de">
<message key="Products">Produkte</message>
...
</catalogue>
translations/tabs_en.xml:
<catalogue xml:lang="en">
<message key="Produkte">Products</message>
...
</catalogue>
> In my initial test I used the file naming conv index.es.xml and changed
> it not thinking it made a difference but I shall change it back and see.
>
Please do so.
> *Do you mean you didn't have to modivy or add anything to sitemap?
>
Exactly.
> Thanks,
> Helena
>
No problem.
Torsten
> Torsten Stolpmann wrote:
>
>> Hi,
>>
>> first of all:
>>
>> Our site at http://www.verit.de is already running in i18n-mode
>> (currently only de and en is supported) using the servlet approach and
>> dynamic language detection using forrest 0.7.
>>
>> I think from your description you are almost there:
>>
>> - Setting project.i18n=true in forrest.properties is the right thing
>> to do.
>>
>> - In contradiction to the documentation try naming your web pages
>> index.es.xml instead of index_es.xml. We got that from studying the
>> error logs closely and suspect the documentation is plain wrong here.
>> Can someone from the dev team comment on this? We also renamed our
>> default language files accordingly (index.en.xml in your case).
>>
>> - You are right about menus_es.xml, languages_es.xml, tabs_es.xml this
>> is what we did also and it worked as advertised.
>>
>> - Yes, to my knowledge all your pages have to be translated seperatly.
>> Especially if you want to support 10 or more languages this will make
>> structural changes in your pages cumbersome to maintain. We already
>> suffer from this with just our two languages.
>>
>> The above scheme worked for translating almost everything but some
>> settings defined in skinconf.xml (e.g. the feedback link). Especially
>> we never had to touch anything on the sitemap level.
>>
>> HTH,
>>
>> Torsten
>>
>>
>>
>>
>> Helena Edelson wrote:
>>
>>> Hi,
>>>
>>> It doesn't make sense to have to add this:
>>> modify |cli.xconf| and add this line:
>>> <uri type=”insert” src-prefix=”" src=”index.html”
>>> follow-links=”false” dest=”/var/tmp/fs/build/i18n/*.en” />
>>> if you are in a live web environment - if you need mulitiple languages.
>>>
>>> If forrest.properties setting is project.i18n=true,
>>> and a user-client browser is language n,
>>> is it only that we need to create all the catalogues, menus and tabs
>>> for x lanuages we will support and the browser does the rest - i.e.
>>> translate the document portion of the page
>>> ?
>>>
>>> Also I can not find anything difinitive on modifying sitemap to
>>> handle i18n
>>> I see forrest.xmap does a few things, I see the F7 site2html.xsl
>>> includes
>>> xmlns:i18n="http://apache.org/cocoon/i18n/2.1"
>>> exclude-result-prefixes="i18n"
>>> in the xsl:stylesheet declaration so I am not sure what a dev needs
>>> to do on the config side,
>>> as it seems most of the work is done already in the guts of forrest
>>> itself.
>>>
>>> thank you,
>>> helena
>>>
>>> Helena Edelson wrote:
>>>
>>>> Hi,
>>>>
>>>> I tested the i18n features of forrest-0.7-dev
>>>> - made a new dir
>>>> - fresh forrest seed
>>>> - turned forrest.i18n on
>>>> - added index_es.xml to .../xdocs/
>>>> - (menu_es.xml, languages_es.xml, tabs_es.xml in distro)
>>>> - index.xml file was renamed index_es.xml
>>>>
>>>> modified index_es.xml to display some Spanish text
>>>> Cheche's blog suggests to do this which I did as well:
>>>> |added project.configfile=/var/tmp/fs/cli.xconf| to
>>>> |forrest.properties|
>>>> modify |cli.xconf| and add this line:
>>>> <uri type=”insert” src-prefix=”" src=”index.html”
>>>> follow-links=”false” dest=”/var/tmp/fs/build/i18n/*.en” />
>>>>
>>>> I looked in my build/tmp/projfilters.properties and found that even
>>>> though I set project.i18n=true in forrest.properties,
>>>> ant projfilters.properties output is project.i18n=false.
>>>> Why might this be?
>>>>
>>>> My index_es.html is served (locale in browser set to 'es') yet the
>>>> menu_es.xml does not.
>>>> I know from mail-archives and others that translation of both menu
>>>> and doc can work.
>>>>
>>>> embarrasing question: Is it the case that if we want multiple
>>>> languages to be supported, we have to supply the
>>>> translations per document page? Nothing will automatically translate
>>>> for the app like how the online
>>>> translation engines do it? Would be great to plug something like
>>>> that in and simply do:
>>>>
>>>> localhost:8888/index.html?locale=es or
>>>> localhost:8888/index.html?locale=fr
>>>>
>>>>
>>>>
>>>> cheers,
>>>> helena
>>>>
>>>>
>>>>> David Crossley wrote:
>>>>>
>>>>>> Ross Gardler wrote:
>>>>>>
>>>>>>
>>>>>>> Helena Edelson wrote:
>>>>>>>
>>>>>>>
>>>>>>>> i am also working on i18n. when i figure it out,
>>>>>>>> i was thinking it might be help ful to write a how to.
>>>>>>>> everything so far seems
>>>>>>>> fractured in terms of the steps to take to implement.
>>>>>>>> there are many if then's and info is everywhere, from
>>>>>>>> docs to jira to cocoon docs..
>>>>>>>>
>>>>>>>
>>>>>>> te a start is what is needed.
>>>>>>>
>>>>>>
>>>>>>
>>>>>> Yes, use one catalogue file per language.
>>>>>>
>>>>>> Yes we do need to bring it all together
>>>>>> in the forrest docs.
>>>>>>
>>>>>> -David
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>
--
Torsten Stolpmann
Geschäftsführender Gesellschafter EMail: stolpmann@verit.de
verit Informationssysteme GmbH Phone: +49-(0)631-30335580
Luxemburger Str. 5 Fax : +49-(0)631-30335581
D-67657 Kaiserslautern Web : http://www.verit.de
Re: i18n usage
Posted by Helena Edelson <he...@greenjaguar.com>.
With things as they are now in my test, if my browser is on language n,
the document (lang n) is served but I haven't gotten it to also to tabs
and menues yet I see on other forrest sites it is working so I think I'm
missing one thing.
In my initial test I used the file naming conv index.es.xml and changed
it not thinking it made a difference but I shall change it back and see.
*Do you mean you didn't have to modivy or add anything to sitemap?
Thanks,
Helena
Torsten Stolpmann wrote:
> Hi,
>
> first of all:
>
> Our site at http://www.verit.de is already running in i18n-mode
> (currently only de and en is supported) using the servlet approach and
> dynamic language detection using forrest 0.7.
>
> I think from your description you are almost there:
>
> - Setting project.i18n=true in forrest.properties is the right thing
> to do.
>
> - In contradiction to the documentation try naming your web pages
> index.es.xml instead of index_es.xml. We got that from studying the
> error logs closely and suspect the documentation is plain wrong here.
> Can someone from the dev team comment on this? We also renamed our
> default language files accordingly (index.en.xml in your case).
>
> - You are right about menus_es.xml, languages_es.xml, tabs_es.xml this
> is what we did also and it worked as advertised.
>
> - Yes, to my knowledge all your pages have to be translated seperatly.
> Especially if you want to support 10 or more languages this will make
> structural changes in your pages cumbersome to maintain. We already
> suffer from this with just our two languages.
>
> The above scheme worked for translating almost everything but some
> settings defined in skinconf.xml (e.g. the feedback link). Especially
> we never had to touch anything on the sitemap level.
>
> HTH,
>
> Torsten
>
>
>
>
> Helena Edelson wrote:
>
>> Hi,
>>
>> It doesn't make sense to have to add this:
>> modify |cli.xconf| and add this line:
>> <uri type=”insert” src-prefix=”" src=”index.html”
>> follow-links=”false” dest=”/var/tmp/fs/build/i18n/*.en” />
>> if you are in a live web environment - if you need mulitiple languages.
>>
>> If forrest.properties setting is project.i18n=true,
>> and a user-client browser is language n,
>> is it only that we need to create all the catalogues, menus and tabs
>> for x lanuages we will support and the browser does the rest - i.e.
>> translate the document portion of the page
>> ?
>>
>> Also I can not find anything difinitive on modifying sitemap to
>> handle i18n
>> I see forrest.xmap does a few things, I see the F7 site2html.xsl
>> includes
>> xmlns:i18n="http://apache.org/cocoon/i18n/2.1"
>> exclude-result-prefixes="i18n"
>> in the xsl:stylesheet declaration so I am not sure what a dev needs
>> to do on the config side,
>> as it seems most of the work is done already in the guts of forrest
>> itself.
>>
>> thank you,
>> helena
>>
>> Helena Edelson wrote:
>>
>>> Hi,
>>>
>>> I tested the i18n features of forrest-0.7-dev
>>> - made a new dir
>>> - fresh forrest seed
>>> - turned forrest.i18n on
>>> - added index_es.xml to .../xdocs/
>>> - (menu_es.xml, languages_es.xml, tabs_es.xml in distro)
>>> - index.xml file was renamed index_es.xml
>>>
>>> modified index_es.xml to display some Spanish text
>>> Cheche's blog suggests to do this which I did as well:
>>> |added project.configfile=/var/tmp/fs/cli.xconf| to
>>> |forrest.properties|
>>> modify |cli.xconf| and add this line:
>>> <uri type=”insert” src-prefix=”" src=”index.html”
>>> follow-links=”false” dest=”/var/tmp/fs/build/i18n/*.en” />
>>>
>>> I looked in my build/tmp/projfilters.properties and found that even
>>> though I set project.i18n=true in forrest.properties,
>>> ant projfilters.properties output is project.i18n=false.
>>> Why might this be?
>>>
>>> My index_es.html is served (locale in browser set to 'es') yet the
>>> menu_es.xml does not.
>>> I know from mail-archives and others that translation of both menu
>>> and doc can work.
>>>
>>> embarrasing question: Is it the case that if we want multiple
>>> languages to be supported, we have to supply the
>>> translations per document page? Nothing will automatically translate
>>> for the app like how the online
>>> translation engines do it? Would be great to plug something like
>>> that in and simply do:
>>>
>>> localhost:8888/index.html?locale=es or
>>> localhost:8888/index.html?locale=fr
>>>
>>>
>>>
>>> cheers,
>>> helena
>>>
>>>
>>>> David Crossley wrote:
>>>>
>>>>> Ross Gardler wrote:
>>>>>
>>>>>
>>>>>> Helena Edelson wrote:
>>>>>>
>>>>>>
>>>>>>> i am also working on i18n. when i figure it out,
>>>>>>> i was thinking it might be help ful to write a how to.
>>>>>>> everything so far seems
>>>>>>> fractured in terms of the steps to take to implement.
>>>>>>> there are many if then's and info is everywhere, from
>>>>>>> docs to jira to cocoon docs..
>>>>>>>
>>>>>>
>>>>>> te a start is what is needed.
>>>>>>
>>>>>
>>>>>
>>>>> Yes, use one catalogue file per language.
>>>>>
>>>>> Yes we do need to bring it all together
>>>>> in the forrest docs.
>>>>>
>>>>> -David
>>>>>
>>>>>
>>>>>
>>>>>
>
Re: i18n info
Posted by Ross Gardler <rg...@apache.org>.
Helena Edelson wrote:
> Has anyone on this list worked with web-based translation engines?
> Hard-coding each content page is not really an option for large sites
> with a high frequency of new content.
>
> With guidance, I could contribute a basic i18n how to. The basics are
> rather easy actually.
See my earlier reply regarding this subject:
http://www.mail-archive.com/user@forrest.apache.org/msg01529.html
> But I wonder, there seems to be so much in cocoon
> for i18n, is there anything there to implement in forrest to gain more
> flexibility? Or is forrest's implementation already drawing fully on that?
Again, as I have described a few times on this list. i18n is in its
infancy within Forrest, more work is needed, in any direction that makes
sense. The problem is that there are currently no active devs working on
this area (although most of us have at least half an eye on this issue).
Your promise of documenting the current state of play will be a great
help to us in deciding how to best improve on the current situation.
Please feel free to join us on the dev list if you have any specific
proposals about how to improve things.
Ross
Re: i18n info
Posted by Helena Edelson <he...@greenjaguar.com>.
Between the mailing list archives (both user and dev), the forrest and
cocoon docs, and the i18n code in forrest itself, plus satellite info
like Cheche's blog, there is rather a lot of information. I found it
hard to sort out what NOT to do, since options seem great to customize
(things like <i18n:attribute, translate, text...>, Getting
Common_Messages parsing language text in the skin is, er.., interesting,
some being in skinconf, some being in site2html.
Has anyone on this list worked with web-based translation engines?
Hard-coding each content page is not really an option for large sites
with a high frequency of new content.
With guidance, I could contribute a basic i18n how to. The basics are
rather easy actually. But I wonder, there seems to be so much in cocoon
for i18n, is there anything there to implement in forrest to gain more
flexibility? Or is forrest's implementation already drawing fully on that?
thanks :)
Helena
Ross Gardler wrote:
> Torsten Stolpmann wrote:
>
>> - In contradiction to the documentation try naming your web pages
>> index.es.xml instead of index_es.xml. We got that from studying the
>> error logs closely and suspect the documentation is plain wrong here.
>> Can someone from the dev team comment on this? We also renamed our
>> default language files accordingly (index.en.xml in your case).
>
>
> It is quite likely that the docs are at best misleading, or even
> incorrect.
>
> i18n support in Forrest is a long way from complete right now and
> there is almost no useful documentation (as this thread illustrates).
>
> I don't have experience of our i18n, nor do I currently have the time
> to go through the Forrest code right now to verify your conclusion,
> but if you have it working this way then I reckon that's a pretty good
> indication.
>
> It being the holidays in much of the world right now feedback may be
> slow coming.
>
> However, I (and probably others) are reading this thread an learning.
> We'll shout if we see something wrong, otherwise you can assume your
> work is educating us ;-)
>
> Ross
>
>
Re: i18n usage
Posted by Ross Gardler <rg...@apache.org>.
Torsten Stolpmann wrote:
> - In contradiction to the documentation try naming your web pages
> index.es.xml instead of index_es.xml. We got that from studying the
> error logs closely and suspect the documentation is plain wrong here.
> Can someone from the dev team comment on this? We also renamed our
> default language files accordingly (index.en.xml in your case).
It is quite likely that the docs are at best misleading, or even incorrect.
i18n support in Forrest is a long way from complete right now and there
is almost no useful documentation (as this thread illustrates).
I don't have experience of our i18n, nor do I currently have the time to
go through the Forrest code right now to verify your conclusion, but if
you have it working this way then I reckon that's a pretty good indication.
It being the holidays in much of the world right now feedback may be
slow coming.
However, I (and probably others) are reading this thread an learning.
We'll shout if we see something wrong, otherwise you can assume your
work is educating us ;-)
Ross
Re: i18n usage
Posted by Torsten Stolpmann <To...@verit.de>.
Hi,
first of all:
Our site at http://www.verit.de is already running in i18n-mode
(currently only de and en is supported) using the servlet approach and
dynamic language detection using forrest 0.7.
I think from your description you are almost there:
- Setting project.i18n=true in forrest.properties is the right thing to do.
- In contradiction to the documentation try naming your web pages
index.es.xml instead of index_es.xml. We got that from studying the
error logs closely and suspect the documentation is plain wrong here.
Can someone from the dev team comment on this? We also renamed our
default language files accordingly (index.en.xml in your case).
- You are right about menus_es.xml, languages_es.xml, tabs_es.xml this
is what we did also and it worked as advertised.
- Yes, to my knowledge all your pages have to be translated seperatly.
Especially if you want to support 10 or more languages this will make
structural changes in your pages cumbersome to maintain. We already
suffer from this with just our two languages.
The above scheme worked for translating almost everything but some
settings defined in skinconf.xml (e.g. the feedback link). Especially we
never had to touch anything on the sitemap level.
HTH,
Torsten
Helena Edelson wrote:
> Hi,
>
> It doesn't make sense to have to add this:
> modify |cli.xconf| and add this line:
> <uri type=”insert” src-prefix=”" src=”index.html” follow-links=”false”
> dest=”/var/tmp/fs/build/i18n/*.en” />
> if you are in a live web environment - if you need mulitiple languages.
>
> If forrest.properties setting is project.i18n=true,
> and a user-client browser is language n,
> is it only that we need to create all the catalogues, menus and tabs for
> x lanuages we will support and the browser does the rest - i.e.
> translate the document portion of the page
> ?
>
> Also I can not find anything difinitive on modifying sitemap to handle i18n
> I see forrest.xmap does a few things, I see the F7 site2html.xsl includes
> xmlns:i18n="http://apache.org/cocoon/i18n/2.1"
> exclude-result-prefixes="i18n"
> in the xsl:stylesheet declaration so I am not sure what a dev needs to
> do on the config side,
> as it seems most of the work is done already in the guts of forrest itself.
>
> thank you,
> helena
>
> Helena Edelson wrote:
>
>> Hi,
>>
>> I tested the i18n features of forrest-0.7-dev
>> - made a new dir
>> - fresh forrest seed
>> - turned forrest.i18n on
>> - added index_es.xml to .../xdocs/
>> - (menu_es.xml, languages_es.xml, tabs_es.xml in distro)
>> - index.xml file was renamed index_es.xml
>>
>> modified index_es.xml to display some Spanish text
>> Cheche's blog suggests to do this which I did as well:
>> |added project.configfile=/var/tmp/fs/cli.xconf| to |forrest.properties|
>> modify |cli.xconf| and add this line:
>> <uri type=”insert” src-prefix=”" src=”index.html” follow-links=”false”
>> dest=”/var/tmp/fs/build/i18n/*.en” />
>>
>> I looked in my build/tmp/projfilters.properties and found that even
>> though I set project.i18n=true in forrest.properties,
>> ant projfilters.properties output is project.i18n=false.
>> Why might this be?
>>
>> My index_es.html is served (locale in browser set to 'es') yet the
>> menu_es.xml does not.
>> I know from mail-archives and others that translation of both menu and
>> doc can work.
>>
>> embarrasing question: Is it the case that if we want multiple
>> languages to be supported, we have to supply the
>> translations per document page? Nothing will automatically translate
>> for the app like how the online
>> translation engines do it? Would be great to plug something like that
>> in and simply do:
>>
>> localhost:8888/index.html?locale=es or localhost:8888/index.html?locale=fr
>>
>>
>>
>> cheers,
>> helena
>>
>>
>>> David Crossley wrote:
>>>
>>>>Ross Gardler wrote:
>>>>
>>>>
>>>>>Helena Edelson wrote:
>>>>>
>>>>>
>>>>>>i am also working on i18n. when i figure it out,
>>>>>>i was thinking it might be help ful to write a how to.
>>>>>>everything so far seems
>>>>>>fractured in terms of the steps to take to implement.
>>>>>>there are many if then's and info is everywhere, from
>>>>>>docs to jira to cocoon docs..
>>>>>>
>>>>>>
>>>>> te a start is what is needed.
>>>>>
>>>>>
>>>>
>>>>Yes, use one catalogue file per language.
>>>>
>>>>Yes we do need to bring it all together
>>>>in the forrest docs.
>>>>
>>>>-David
>>>>
>>>>
>>>>
>>>>
--
Torsten Stolpmann
Geschäftsführender Gesellschafter EMail: stolpmann@verit.de
verit Informationssysteme GmbH Phone: +49-(0)631-30335580
Luxemburger Str. 5 Fax : +49-(0)631-30335581
D-67657 Kaiserslautern Web : http://www.verit.de
Re: i18n usage
Posted by Helena Edelson <he...@greenjaguar.com>.
Finally,
Does anything in this cocoon info page need to be implemented?
http://cocoon.apache.org/2.1/userdocs/i18nTransformer.html
thank you,
helena
Helena Edelson wrote:
>
> Helena Edelson wrote:
>
>> Hi,
>>
>> I tested the i18n features of forrest-0.7-dev
>> - made a new dir
>> - fresh forrest seed
>> - turned forrest.i18n on
>> - added index_es.xml to .../xdocs/
>> - (menu_es.xml, languages_es.xml, tabs_es.xml in distro)
>> - index.xml file was renamed index_es.xml
>>
>> modified index_es.xml to display some Spanish text
>> Cheche's blog suggests to do this which I did as well:
>> |added project.configfile=/var/tmp/fs/cli.xconf| to |forrest.properties|
>> modify |cli.xconf| and add this line:
>> <uri type="insert" src-prefix="" src="index.html"
>> follow-links="false" dest="/var/tmp/fs/build/i18n/*.en" />
>>
>> I looked in my build/tmp/projfilters.properties and found that even
>> though I set project.i18n=true in forrest.properties,
>> ant projfilters.properties output is project.i18n=false.
>> Why might this be?
>>
>> My index_es.html is served (locale in browser set to 'es') yet the
>> menu_es.xml does not.
>> I know from mail-archives and others that translation of both menu
>> and doc can work.
>>
>> embarrasing question: Is it the case that if we want multiple
>> languages to be supported, we have to supply the
>> translations per document page? Nothing will automatically translate
>> for the app like how the online
>> translation engines do it? Would be great to plug something like that
>> in and simply do:
>>
>> localhost:8888/index.html?locale=es or
>> localhost:8888/index.html?locale=fr
>>
>>
>>
>> cheers,
>> helena
>>
>>
>>> David Crossley wrote:
>>>
>>>>Ross Gardler wrote:
>>>>
>>>>
>>>>>Helena Edelson wrote:
>>>>>
>>>>>
>>>>>>i am also working on i18n. when i figure it out,
>>>>>>i was thinking it might be help ful to write a how to.
>>>>>>everything so far seems
>>>>>>fractured in terms of the steps to take to implement.
>>>>>>there are many if then's and info is everywhere, from
>>>>>>docs to jira to cocoon docs..
>>>>>>
>>>>>>
>>>>> te a start is what is needed.
>>>>>
>>>>>
>>>>
>>>>Yes, use one catalogue file per language.
>>>>
>>>>Yes we do need to bring it all together
>>>>in the forrest docs.
>>>>
>>>>-David
>>>>
>>>>
>>>>
>>>>
Re: i18n usage
Posted by Helena Edelson <he...@greenjaguar.com>.
Hi,
It doesn't make sense to have to add this:
modify |cli.xconf| and add this line:
<uri type="insert" src-prefix="" src="index.html" follow-links="false"
dest="/var/tmp/fs/build/i18n/*.en" />
if you are in a live web environment - if you need mulitiple languages.
If forrest.properties setting is project.i18n=true,
and a user-client browser is language n,
is it only that we need to create all the catalogues, menus and tabs for
x lanuages we will support and the browser does the rest - i.e.
translate the document portion of the page
?
Also I can not find anything difinitive on modifying sitemap to handle i18n
I see forrest.xmap does a few things, I see the F7 site2html.xsl includes
xmlns:i18n="http://apache.org/cocoon/i18n/2.1"
exclude-result-prefixes="i18n"
in the xsl:stylesheet declaration so I am not sure what a dev needs to
do on the config side,
as it seems most of the work is done already in the guts of forrest itself.
thank you,
helena
Helena Edelson wrote:
> Hi,
>
> I tested the i18n features of forrest-0.7-dev
> - made a new dir
> - fresh forrest seed
> - turned forrest.i18n on
> - added index_es.xml to .../xdocs/
> - (menu_es.xml, languages_es.xml, tabs_es.xml in distro)
> - index.xml file was renamed index_es.xml
>
> modified index_es.xml to display some Spanish text
> Cheche's blog suggests to do this which I did as well:
> |added project.configfile=/var/tmp/fs/cli.xconf| to |forrest.properties|
> modify |cli.xconf| and add this line:
> <uri type="insert" src-prefix="" src="index.html" follow-links="false"
> dest="/var/tmp/fs/build/i18n/*.en" />
>
> I looked in my build/tmp/projfilters.properties and found that even
> though I set project.i18n=true in forrest.properties,
> ant projfilters.properties output is project.i18n=false.
> Why might this be?
>
> My index_es.html is served (locale in browser set to 'es') yet the
> menu_es.xml does not.
> I know from mail-archives and others that translation of both menu and
> doc can work.
>
> embarrasing question: Is it the case that if we want multiple
> languages to be supported, we have to supply the
> translations per document page? Nothing will automatically translate
> for the app like how the online
> translation engines do it? Would be great to plug something like that
> in and simply do:
>
> localhost:8888/index.html?locale=es or localhost:8888/index.html?locale=fr
>
>
>
> cheers,
> helena
>
>
>> David Crossley wrote:
>>
>>>Ross Gardler wrote:
>>>
>>>
>>>>Helena Edelson wrote:
>>>>
>>>>
>>>>>i am also working on i18n. when i figure it out,
>>>>>i was thinking it might be help ful to write a how to.
>>>>>everything so far seems
>>>>>fractured in terms of the steps to take to implement.
>>>>>there are many if then's and info is everywhere, from
>>>>>docs to jira to cocoon docs..
>>>>>
>>>>>
>>>> te a start is what is needed.
>>>>
>>>>
>>>
>>>Yes, use one catalogue file per language.
>>>
>>>Yes we do need to bring it all together
>>>in the forrest docs.
>>>
>>>-David
>>>
>>>
>>>
>>>
Re: i18n usage
Posted by Helena Edelson <he...@greenjaguar.com>.
Hi,
I tested the i18n features of forrest-0.7-dev
- made a new dir
- fresh forrest seed
- turned forrest.i18n on
- added index_es.xml to .../xdocs/
- (menu_es.xml, languages_es.xml, tabs_es.xml in distro)
- index.xml file was renamed index_es.xml
modified index_es.xml to display some Spanish text
Cheche's blog suggests to do this which I did as well:
|added project.configfile=/var/tmp/fs/cli.xconf| to |forrest.properties|
modify |cli.xconf| and add this line:
<uri type="insert" src-prefix="" src="index.html" follow-links="false"
dest="/var/tmp/fs/build/i18n/*.en" />
I looked in my build/tmp/projfilters.properties and found that even
though I set project.i18n=true in forrest.properties,
ant projfilters.properties output is project.i18n=false.
Why might this be?
My index_es.html is served (locale in browser set to 'es') yet the
menu_es.xml does not.
I know from mail-archives and others that translation of both menu and
doc can work.
embarrasing question: Is it the case that if we want multiple languages
to be supported, we have to supply the
translations per document page? Nothing will automatically translate for
the app like how the online
translation engines do it? Would be great to plug something like that in
and simply do:
localhost:8888/index.html?locale=es or localhost:8888/index.html?locale=fr
cheers,
helena
> David Crossley wrote:
>
>>Ross Gardler wrote:
>>
>>
>>>Helena Edelson wrote:
>>>
>>>
>>>>i am also working on i18n. when i figure it out,
>>>>i was thinking it might be help ful to write a how to.
>>>>everything so far seems
>>>>fractured in terms of the steps to take to implement.
>>>>there are many if then's and info is everywhere, from
>>>>docs to jira to cocoon docs..
>>>>
>>>>
>>> te a start is what is needed.
>>>
>>>
>>
>>Yes, use one catalogue file per language.
>>
>>Yes we do need to bring it all together
>>in the forrest docs.
>>
>>-David
>>
>>
>>
>>
Re: i18n and documentation
Posted by Helena Edelson <he...@greenjaguar.com>.
thank you David.
When I get multiple language support working in one live site i'm
working on now,
I'll spend some time writing a how to. I hope to integrate at least ten.
Will review previously implemented work to date.
Some time in January a how to should be ready.
Helena
David Crossley wrote:
>Ross Gardler wrote:
>
>
>>Helena Edelson wrote:
>>
>>
>>>i am also working on i18n stuff. when i figure it out,
>>>i was thinking it might be help ful to write a how to.
>>>everything so far seems
>>>fractured in terms of the steps to take to implement.
>>>there are many if then's and info is everywhere, from
>>>docs to jira to cocoon docs..
>>>
>>>
>> te a start is what is needed.
>>
>>
>
>Helena, please ask questions on the mailing list
>rather than via the issue tracker. Here are some
>notes that might help you ...
>
>Yes, use one catalogue file per language.
>
>The map:serialise is an empty element. The patch
>that you looked at was old and has a syntax error
>with an extra closing tag for a map:generator.
>It has already been applied and has some subsequent
>changes which were done prior to 0.7 release.
>
>Anyway you should not need to look at the guts
>of Forrest just to use i18n.
>
>Remember that we only maintain the "pelt" skin.
>So for the i18n of menus, it might only work for
>pelt. The i18n of content should be independent
>of the skin.
>
>See the notes in forrest.properties about i18n.
>
>See a 'forrest seed site'.
>
>See Cheche's blog entry. Google: i18n forrest
>Beware, some changes have been made since he wrote.
>
>There is some recent discussion about i18n in
>the forrest-dev mailing archives. Guess about
>three months ago. I tried to explain the processing
>to Gav and we fixed a bug which produced invalid
>html output (only fixed in trunk at svn r263870
>and r264136). The i18n still worked.
>
>Yes we do need to bring it all together
>in the forrest docs.
>
>-David
>
>
>
>
Re: i18n and documentation
Posted by David Crossley <cr...@apache.org>.
Ross Gardler wrote:
> Helena Edelson wrote:
> >i am also working on i18n stuff. when i figure it out,
> >i was thinking it might be help ful to write a how to.
> >everything so far seems
> >fractured in terms of the steps to take to implement.
> >there are many if then's and info is everywhere, from
> >docs to jira to cocoon docs..
>
> Yes, your help in bringing it together into something coherent will be
> *very* helpful. Most of the i18n stuff has been implemented by Cheche
> who is still around on the dev lists, but rarely appears here on the
> user list.
>
> We need to improve i18n support in Forrest to make use of the new
> locationmap stuff (one of the major improvements in the 0.8-dev work).
> However, without a clear understanding of how the current i18n works
> this is very difficult. even a rough outline of what you know so far
> would be very useful to both users and devs. Don't worry about it being
> complete a start is what is needed.
Helena, please ask questions on the mailing list
rather than via the issue tracker. Here are some
notes that might help you ...
Yes, use one catalogue file per language.
The map:serialise is an empty element. The patch
that you looked at was old and has a syntax error
with an extra closing tag for a map:generator.
It has already been applied and has some subsequent
changes which were done prior to 0.7 release.
Anyway you should not need to look at the guts
of Forrest just to use i18n.
Remember that we only maintain the "pelt" skin.
So for the i18n of menus, it might only work for
pelt. The i18n of content should be independent
of the skin.
See the notes in forrest.properties about i18n.
See a 'forrest seed site'.
See Cheche's blog entry. Google: i18n forrest
Beware, some changes have been made since he wrote.
There is some recent discussion about i18n in
the forrest-dev mailing archives. Guess about
three months ago. I tried to explain the processing
to Gav and we fixed a bug which produced invalid
html output (only fixed in trunk at svn r263870
and r264136). The i18n still worked.
Yes we do need to bring it all together
in the forrest docs.
-David
i18n and documentation (Re: access control - user roles by sitemap)
Posted by Ross Gardler <rg...@apache.org>.
Helena Edelson wrote:
> i am also working on i18n stuff. when i figure it out,
> i was thinking it might be help ful to write a how to.
> everything so far seems
> fractured in terms of the steps to take to implement.
> there are many if then's and info is everywhere, from
> docs to jira to cocoon docs..
Yes, your help in bringing it together into something coherent will be
*very* helpful. Most of the i18n stuff has been implemented by Cheche
who is still around on the dev lists, but rarely appears here on the
user list.
We need to improve i18n support in Forrest to make use of the new
locationmap stuff (one of the major improvements in the 0.8-dev work).
However, without a clear understanding of how the current i18n works
this is very difficult. even a rough outline of what you know so far
would be very useful to both users and devs. Don't worry about it being
complete a start is what is needed.
Ross
Re: access control - user roles by sitemap
Posted by Helena Edelson <he...@greenjaguar.com>.
thanks. will do.
i am also working on i18n stuff. when i figure it out,
i was thinking it might be help ful to write a how to.
everything so far seems
fractured in terms of the steps to take to implement.
there are many if then's and info is everywhere, from
docs to jira to cocoon docs..
helena
Ross Gardler wrote:
> Helena Edelson wrote:
>
>> Is there any way using sitemap to manage user roles
>> via a login to control roles
>> access to app pages for user_role_a
>> disallow access for user_role_b type of thing?
>
>
> Depends on whether you are running in dynamic mode or not.
>
> In static mode you would have to use the mechanisms provided by your
> web server for protecting access to certain resources. On the Apache
> HTTPD server that would be using .htaccess files.
>
> In this case you simply provide the relevant .htaccess files in along
> with your XDocs and they will (theoretically) be copied over when you
> build the site. I say theoretically because I have not, personally,
> tried this. Let us know if you try it and it works (preferably in the
> form of a contribution to our docs).
>
> If you are running in dynamic mode you can, theoretically, use the
> Cocoon Authentication framework [1]. Again, I say theoretically
> because it I'm not aware of anyone having done this yet. If you want
> to go this route then it is really a dev topic, so please move this to
> the dev list where we can help guide you and (hopefully) you can write
> us a How-To on making it work.
>
> Ross
>
> [1] http://cocoon.apache.org/2.1/developing/webapps/authentication.html
>
>
Re: access control - user roles by sitemap
Posted by Ross Gardler <rg...@apache.org>.
Helena Edelson wrote:
> Is there any way using sitemap to manage user roles
> via a login to control roles
> access to app pages for user_role_a
> disallow access for user_role_b type of thing?
Depends on whether you are running in dynamic mode or not.
In static mode you would have to use the mechanisms provided by your web
server for protecting access to certain resources. On the Apache HTTPD
server that would be using .htaccess files.
In this case you simply provide the relevant .htaccess files in along
with your XDocs and they will (theoretically) be copied over when you
build the site. I say theoretically because I have not, personally,
tried this. Let us know if you try it and it works (preferably in the
form of a contribution to our docs).
If you are running in dynamic mode you can, theoretically, use the
Cocoon Authentication framework [1]. Again, I say theoretically because
it I'm not aware of anyone having done this yet. If you want to go this
route then it is really a dev topic, so please move this to the dev list
where we can help guide you and (hopefully) you can write us a How-To on
making it work.
Ross
[1] http://cocoon.apache.org/2.1/developing/webapps/authentication.html