forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Gav...." <>
Subject Re: FOR-592 - pelt and i18n clarifications
Date Mon, 08 Aug 2005 13:52:12 GMT
Ok, finally got around to answering this one, (after my CSS delay tactics)

----- Original Message ----- 
From: "David Crossley" <>
Subject: Re: FOR-592 - pelt and i18n clarifications

| 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.

No problem

| 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.

Ah, how little did I know :) (and still don't)

| ...
| Gav.... wrote:
| >
| > With regard to the above issue , which involves the pelt skin not 
| > if project.i18n is not set to true I would like to clarify and then ask 
| > few things.
| Other developers (e.g. Cheche in particular) understand more
| about i18n than me. Anyway, i will try to help.

Thanks for helping, on reflection I feel the issue *may* be more xml related 
implementation rather than i18n itself, more below..

| > 1. Setting project.i18n in any config file did not 
| > to me to make any difference, the static site produced still did not
| > transform i18n at all. ...
| Works for me. I did this ...
<snip useful instructions>
Works for me too now.

| > ... Only setting in
| > /main/webapp produced a static site that was HTML 4.01 compliant due to 
| > 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.

Yep, got it.

| > 2. In /main/ there is this if statement.
| >
| > <!-- If the user wants to build i18n in diferent locations this is one 
| > 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 
| > checks whether project.i18n is turned on, and acts accordingly and
| > correctly. However, this is the only check I can find anywhere (in 
| > to see if project.i18n=true.
| To see how Cocoon handles it, follow the core sitemaps.
| cd main/webapp
| grep i18n *
| forrest.xmap
| ... 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.

No, there is no on/off check and they do fall through as you say, the
default being no language specified and used *.xml. By looking through
various code, this seems to happen whether i18n is turned on (=true) or not.

| 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.

Well, yes I can see what they do when the test is true, ie when i18n is 
on, and this all works very well as we know. I can not however see what 
when the test is false, in fact there is no code (that I can see) to say 
what happens
when i18n is turned off. This is where my confusion lies, I am not the 
brightest when
it comes to understanding xml code as it has been implemented within 
forrest, but I
would have thought there would be some code somewhere that strips away all 
i18n stuff when it is not being transformed/parsed.(see next answer also...)

| > 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 
| > 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 
| > 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.

Yes, in /pelt/xslt/html/site2xhtml.xsl the namespace is removed leaving
<text></text> in place, though I am not sure this is where the problem
really lies.

| > 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.

I will look into it, I somehow feel this is a quick-fix and not the proper
solution. If I do not find the proper solution soon I will implement this
fix as an interim and see what you think.

| > 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 
| > skins/themes/views are moving forward in a different direction. (In 
| > 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.

As per your reply to the other issue, maybe I should move on to viewHelper
(once this is resolved).

| > 5. I take it that because of point 1 above, that is 
| > dynamically from the svn and that project.i18n is turned off, any reason 
| > 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
| src/documentation/translations/
| 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
| main/webapp/skins/common/translations/
| 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".

Thanks for the above.

| > 6. What is the reason for there being a choice in whether i18n is on or 
| > 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.

Unless someone else makes a start on it, I will have a go once I have
it clear myself.


No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.338 / Virus Database: 267.10.2/65 - Release Date: 7/08/2005

View raw message