You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@forrest.apache.org by "Gav...." <br...@brightontown.com.au> on 2005/08/04 14:54:27 UTC
FOR-592 - pelt and i18n clarifications
Hi All,
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.
1. Setting project.i18n in any forrest.properties config file did not seem
to me to make any difference, the static site produced still did not
transform i18n at all. Only setting default-forrest.properties in
/main/webapp produced a static site that was HTML 4.01 compliant due to the
i18n elements being transformed correctly.
2. In /main/forrest.build.xml 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="project.site-dir"
location="${project.build-dir}/site/${user.language}" />
</then>
<else>
<property name="project.site-dir"
location="${project.build-dir}/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.
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> )
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.?
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)
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 W3.org
validator yet)
5. I take it that because of point 1 above, that forrest.apache.org is built
dynamically from the svn and that project.i18n is turned off, any reason for
this, or have I got confused somewhere.?
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?
7. Should I become a bit more familiar before asking such questions :)
Gav...
--
No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.338 / Virus Database: 267.9.9/62 - Release Date: 2/08/2005
Re: FOR-592 - pelt and i18n clarifications
Posted by David Crossley <cr...@apache.org>.
Gav.... wrote:
>
> | > | > 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.
> | 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.
>
> Well, I'm working on this and need a bit of help to complete it.
>
> I am using <xsl:when> block and then an <xsl:otherwise> in the pelt
> site2xtml.xsl but the
> when statement is causing me problems.
>
> How do I check for project.i18n=true (from forrest.properties created by
> forrest seed) from this when statement.
See my separate message today about
"passing parameters from sitemaps to stylesheets".
While this could solve the issue, you are right that
this feels like a quick fix.
Another approach would be to add another transformer at
the very end of the processing for html output, whose
job is to remove the unnecessary <text> wrappers which
are left over from not having done i18n processing.
That would be an "otherwise" clause at
main/webapp/sitemap.xmap line 242
Yet another approach would be to have i18n happening
all the time. But that topic is too big for the moment.
Lets get one of these workarounds happening first.
-David
passing parameters from sitemaps to stylesheets
Posted by David Crossley <cr...@apache.org>.
Gav.... wrote:
>
> How do I check for project.i18n=true (from forrest.properties created by
> forrest seed) from this when statement.
>
> I have :-
>
> <xsl:choose>
> <xsl:when test="config.i18n = 'true'"> /* also tried $config/i18n
> and a few others, this is where I'm stuck */
> (i18n compatible stuff)
> </xsl:when>
> <xsl:otherwise>
> (Remove i18n stuff)
> </xsl:otherwise>
> </xsl:choose>
Ah, this is turning in to a useful lesson. How to
pass parameters from the sitemaps into the stylesheets
and how to access project properties.
Notice that pelt/xslt/html/site2xhtml.xsl
imports common/xslt/html/site2xhtml.xsl
Look at the latter.
<xsl:variable name="config" select="//skinconfig"/>
That sets $config to all of the values from the
project's skinconf.xml file. This information has
been previously aggregated by the sitemap into the
xml stream that we are transforming.
<xsl:param name="path"/>
That was passed to this stylesheet from the sitemap.
Lets look at the sitemaps to find out how:
cd /svn/asf/forrest/main/webapp
grep site2xhtml *
more sitemap.xmap
That shows that the sitemap resource named "skinit"
was called with <map:parameter name="path" value="{0}"/>
That passes the value of the uri being processed.
Looking at the skinit resource, a transformer then
applies the relevant stylesheet and passes the
parameter "path".
So you could get other properties into your final
stylesheet in that way. Looking at the sitemaps
you can see that those values are obtained from
properties using the syntax {project:blah} or
{defaults:blah} {request:blah} {forrest:blah} etc.
The main/webapp/WEB-INF/xconf/forrest-core.xconf
shows how those values are made available using
"sitemap input modules".
-David
Re: FOR-592 - pelt and i18n clarifications
Posted by "Gav...." <br...@brightontown.com.au>.
----- Original Message -----
From: "David Crossley" <cr...@apache.org>
To: <de...@forrest.apache.org>
Sent: Monday, August 08, 2005 10:58 PM
Subject: Re: FOR-592 - pelt and i18n clarifications
|
| > | > 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.
| 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.
|
Well, I'm working on this and need a bit of help to complete it.
I am using <xsl:when> block and then an <xsl:otherwise> in the pelt
site2xtml.xsl but the
when statement is causing me problems.
How do I check for project.i18n=true (from forrest.properties created by
forrest seed) from this when statement.
I have :-
<xsl:choose>
<xsl:when test="config.i18n = 'true'"> /* also tried $config/i18n
and a few others, this is where I'm stuck */
(i18n compatible stuff)
</xsl:when>
<xsl:otherwise>
(Remove i18n stuff)
</xsl:otherwise>
</xsl:choose>
Thanks
Gav...
--
No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.338 / Virus Database: 267.10.5/68 - Release Date: 10/08/2005
Re: FOR-592 - pelt and i18n clarifications
Posted by David Crossley <cr...@apache.org>.
Gav.... wrote:
> Ok, finally got around to answering this one, (after my CSS delay tactics)
>
> ----- Original Message -----
> From: "David Crossley" <cr...@apache.org>
> |
> | 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 W3.org
> | > 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.
-David
Re: FOR-592 - pelt and i18n clarifications
Posted by "Gav...." <br...@brightontown.com.au>.
Ok, finally got around to answering this one, (after my CSS delay tactics)
----- Original Message -----
From: "David Crossley" <cr...@apache.org>
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
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.
Thanks for helping, on reflection I feel the issue *may* be more xml related
in
implementation rather than i18n itself, more below..
|
| > 1. Setting project.i18n in any forrest.properties 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 ...
<snip useful instructions>
Works for me too now.
|
| > ... Only setting default-forrest.properties 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.
Yep, got it.
|
| > 2. In /main/forrest.build.xml 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="project.site-dir"
| > location="${project.build-dir}/site/${user.language}" />
| > </then>
| > <else>
| > <property name="project.site-dir"
| > location="${project.build-dir}/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 *
| 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
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. 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.
|
| > 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
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 W3.org
| > 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 forrest.apache.org 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. index.fr.html
| 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
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.
Unless someone else makes a start on it, I will have a go once I have
it clear myself.
Gav...
--
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
Re: FOR-592 - pelt and i18n clarifications
Posted by David Crossley <cr...@apache.org>.
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 forrest.properties 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 forrest.properties 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
http://localhost:8888/index.html
... yes, the tab name is changed
Ctrl-C
forrest site
more build/site/en/index.html
... yes, the tab name is changed
> ... Only setting default-forrest.properties 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/forrest.build.xml 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="project.site-dir"
> location="${project.build-dir}/site/${user.language}" />
> </then>
> <else>
> <property name="project.site-dir"
> location="${project.build-dir}/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 *
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.
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 W3.org
> validator yet)
That should be discussed as a separate topic.
> 5. I take it that because of point 1 above, that forrest.apache.org 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. index.fr.html
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".
> 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.
David