On Wed, 2005-01-06 at 12:02 +0200, Juan Jose Pablos wrote:
> Pedro I. Sanchez wrote:
> >
> > Anyway, first I verified that setting value="es_ES" in
> > main/webapp/sitemap.xmap indeed works. It brings the Spanish strings
> > from the right catalogue. I also verified that value="${env.LANG}" does
> > *not* work.
> >
>
> are you sure that the $LANG property is set on your system?
> if not do an "export LANG=es_ES"
>
> do an echo $LANG before running "forrest site" to verify that the change
> has been made.
>
The string $(env.LANG} works well inside main/forrest.build.xml. It was
the default before you made changes to the trunk. But the same string is
ignored when you use it inside webapp/sitemap.xmap (skin labels are
looked up in the English dictionary, even if LANG=es_ES).
> >
> > 1) First change
> >
> > -#project.i18n=true
> > +project.i18n=true
> > +project.language=es_ES
> >
> > And this alone works just well. The site is generated under
> > build/site/es_ES but with English labels. The next step is
> > required to get the translations in place.
>
> The i18naction does not know anything about project.language that is why
> it does not translate
>
That's what I was trying to figure out in my 'second change'.
>
> >
> > 2) Second change: Reflecting these changes in the sitemap
>
> > Unfortunately these gives me a null pointer and dies :( But there's tons
> > of {project:xxxx} strings used everywhere in the site map! So, what's
> > missing to make my newly created "language" property to work?
> > forrest.build.xml likes it but sitemap.xmap doesn't.
> >
>
> Well you change the new stuff about a skin i18n aware. There is more
> stuff that needs to change. Still, I think that the main issue that you
> have is that forrest does not get you env.LANG property.
>
forrest.build.xml does. sitemap.xmap doesn't.
> I have change that so it uses {user.language} instead. try to "svn up"
> and report if that is working for you.
>
I don't believe what you did is right, sorry if I misunderstand :|
You replaced my 'project.language' with 'user.language' but you are not
defining 'user.language' in forrest.build.xml. So it does nothing when I
use it in my site's 'forrest.properties'.
So, let me rephrase my understanding of this issue so far. Before you
made changes to trunk this was the behaviour:
1. Forrest seed; forrest would generate the static site in English,
regardless of your LANG env.
2. Setting project.i18n=true in forrest.properties and running forrest
again would generate your site in build/site/xx, where xx is determined
by the LANG env. BUT, the generated static site is still all in English;
no look up into the language-specific catalogues ever takes place.
With your changes to the trunk this is the current behaviour:
1. As before.
2. Setting project.i18n=true in forrest.properties and running forrest
again would generate your static site in build/site/en, regardless of
your LANG env. This is not the expected behaviour. And the site is
generated in English as before, no changes here.
My goal for a static site is to be able to issue the command
$ LANG=es_ES forrest
and get two things:
a) My site is built under build/site/es. This was OK before your
changes. It's not the case anymore.
b) Get the generated static site with Spanish skin labels. This was not
happening before and it's not happening now. The reason? We still have
the line
<map:parameter name="locale" value="{request:locale}"/>
in sitemap.xmap which makes the translation unaware of the LANG setting.
Replacing it with
<map:parameter name="locale" value="${env.LANG}"/>
doesn't work. Replacing it with
<map:parameter name="locale" value="{project.language}"/>
gives a NULL pointer somewhere.
I have some ideas on the i18n behaviour I'd like to see when generating
a static site which I'll share in a different e-mail.
Cheers,
--
Pedro
