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 Mon, 08 Aug 2005 14:58:58 GMT
Gav.... wrote:
> Ok, finally got around to answering this one, (after my CSS delay tactics)
> ----- Original Message ----- 
> From: "David Crossley" <>
> |
> | 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.

That is correct. That is how the Cocoon sitemap operates,
the first match wins.

> | 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 
> turned
> on, and this all works very well as we know. I can not however see what 
> happens
> when the test is false, in fact there is no code (that I can see) to say 
> what happens
> when i18n is turned off.

That is just the point, nothing happens.
e.g. sitemap.xmap line 241 then i18n processing is
only applied if i18n is switched on. Otherwise no
extra i18n transformation is applied.

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

No this is not the issue.

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

This is definitely the best way to go at this stage.

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

Yep, i reckon do the workaround above, then get on to
something else. This excursion to understand i18n has
given you a little more grasp of how to work with
Forrest internals.

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

Just at the user level. Should be a pretty short doc.
Don't forget to google: cheche blog i18n
He has a basic explanation. We need something similar
in Forrest docs. But don't bother if you'd rather do
something else. Have fun.


View raw message