forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Crossley <>
Subject Re: FOR-592 - pelt and i18n clarifications
Date Fri, 05 Aug 2005 06:39:27 GMT
Thank you for tackling issues like this.
Exactly what we need, people tidying up the current
state of things rather than rushing on to new abilities.
Both are needed of course.

Interesting your FOR-592 comment:
"I would like to help if I can with various
parts of Forrest , starting with the little things.
How would I go about helping with this little validation matter?"

:-) here we are at a not-so-little issue already.
Thanks for helping.

Gav.... wrote:
> With regard to the above issue , which involves the pelt skin not validating 
> if project.i18n is not set to true I would like to clarify and then ask a 
> few things.

Other developers (e.g. Cheche in particular) understand more
about i18n than me. Anyway, i will try to help.

> 1. Setting project.i18n in any config file did not seem 
> to me to make any difference, the static site produced still did not 
> transform i18n at all. ...

Works for me. I did this ...
mkdir /home/me/seed-i18n; cd there
forrest seed
edit to set i18n true
forrest site
more build/site/en/index.html
... yes, the <text> wrapper elements are gone.
cd src/documentation/translations/
cp tabs.xml tabs_en.xml
edit tabs_en.xml to tweak one of the translations
forrest run
... yes, the tab name is changed
forrest site
more build/site/en/index.html
... yes, the tab name is changed

> ... Only setting in 
> /main/webapp produced a static site that was HTML 4.01 compliant due to the 
> i18n elements being transformed correctly.

A user should not need to touch that file.
The default is false. See above; setting at
the project level works for me.

> 2. In /main/ there is this if statement.
> <!-- If the user wants to build i18n in diferent locations this is one way 
> to implemented it-->
>     <if>
>         <equals arg1="${project.i18n}" arg2="true"/>
>         <then>
>           <property name="" 
> location="${}/site/${user.language}"    />
>         </then>
>         <else>
>           <property name="" 
> location="${}/site"    />
>         </else>
>     </if>
> This is self explanatory but I have a couple of questions. This if statement 
> checks whether project.i18n is turned on, and acts accordingly and 
> correctly. However, this is the only check I can find anywhere (in forrest) 
> to see if project.i18n=true.

To see how Cocoon handles it, follow the core sitemaps.

cd main/webapp
grep i18n *
... shows that initial matches are done for existence
of i18n content first (e.g. *.fr.xml) and then looks for *.xml
So yeah, no actual on/off check there but that is
how the Cocoon sitemap works: fall through to try other matches.

sitemap.xmap and menu.xmap and tabs.xmap
... these all have a test for whether i18n is on/off.
They use an i18n-enabled transformer to
look up a catalogue.

How each sitemap handles the various translations
should be obvious. If not, just ask.

> This also means that in the pelt skin a check is not being made as to 
> whether i18n is turned on or not. If it is on, the pelt skin transforms the 
> i18n statements correctly. If i18n is turned off, it does not transform 
> correctly because it can't , all that gets done is i18n gets removed from 
> any tags, leaving untransfromed and invalid code in place. (such as 
> <text>...</text> )

To clarify, i gather that you mean just the i18n namespace
is removed, leaving the bare <text> wrapper. 

> Should there be an if statement added to pelt skin to check for 
> project.i18n=true and act accordingly, as in provide an alternative if it is 
> turned off -- which it is by default.?

Could do that. That would be a an immediate solution.
This ablility to add translation for certain parts
of the skin such as "Search", was only added very
recently. Perhaps it does need better implementation.

> 3. How long is it acceptable for the forrest site to remain invalid - can a 
> temporary measure in the current pelt skin be acceptable, seeing as the way 
> skins/themes/views are moving forward in a different direction. (In other 
> words is this worth persuing still)

I expect that the same issues will happen with "views".
So we need to solve it ASAP. Anything that we learn
can easily be applied.

> 4. Will it be helpful to provide an XHTML1.1 compliant pelt skin, or 
> leather-dev as a step forward to XHTML 2.0 (for which there is no 
> validator yet)

That should be discussed as a separate topic.

> 5. I take it that because of point 1 above, that is built 
> dynamically from the svn and that project.i18n is turned off, any reason for 
> this, or have I got confused somewhere.?

Yes, built from sources in our svn trunk at site-author/
and yes i18n is turned off. However, no it is not built
dynamically. We used the 'forrest site' technique to
genrate a static set of documents.

There is a reason for turning it off when not using it.
Efficiency. It means that Cocoon underneath does not need
to bother about the translations. See 6 below.

We don't have any i18n-enabled content yet.
That will be a long way down the track when we
have solidifed our documentation and are ready
to do translations of content.

There are various aspects to our i18n ...

[a] provision of translated content. e.g.
This is performed by forrest.xmap and i18n.xml
to look for alternative source documents.

[b] Translation of the names for Tabs and Menu items.
This is defined at the project level in
This is performed by tabs.xmap and menu.xmap
to look up a catalogue.

[c] Translation of the certain pieces of content
such as the word "Search" on the button and the
prompt inside the seach input field. This is defined at
This is performed by the "skinit" resource in sitemap.xmap
This is also powerful to use for the same language
to change default names for page elements,
e.g. "Search the site with". 

> 6. What is the reason for there being a choice in whether i18n is on or off, 
> why not it be on all the time and be done with it?

Efficiency, i presume. It would be interesting to know
if there was a noticable difference in both dynamic
mode ('forrest run') and static mode ('forrest site').

It looks more and more like we will need to
make active use of a profiler.

> 7. Should I become a bit more familiar before asking such questions :)

No, keep on. This is useful.

Ideally we can come back to harvest these
replies to create some documentation. That is
why i tend to be verbose (hope not too much so).

What is needed obviously is a document to describe
how to use it.


View raw message