Den 26. sep. 2006 kl. 12.37 skrev Ross Gardler:
I can open http://localhost:8888/index.en.html and have my page in
English. The problem with this solution is that it does not work
nicely in a webapp environment (e.g. forrest run), because this
locale encoding does not communicate with the locale modules in
Cocoon (LocaleAction, LocaleMatcher, I18nTransformer). Thus, all
menus and tabs are/will most likely be in a different language. In
addition, it's location in the menu is lost.
This brings me back to the idea of using the locationmap for locale
matching rather than Cocoons components, which have their problems
in our use case. Something like (be warned, I've not fully thought
this through and do not have any i18n sites, I'm not at all sure
this will work in the real world):
<match pattern="**.xml">
<location src="{project:xdocs}/{1}.{2}.xml/>
</location>
<match pattern="**.*.xml">
<select>
<location src="{project:xdocs}/{1}.{2}.xml/>
<location src="{project:xdocs}/{1}.{project:locale.default}.xml/>
</select>
</location>
This looses completely the concept of content negotiation, which is
exactly what the Cocoon modules provide. And this is really the core
of the problem: when running in a webapp environment, you want
negotiation, and ways to override the negotiated result, whereas in a
static build you don't want negotiation at all, just all files
generated to the requested output format(s).
Using the locationmap is fine, but not until content negotiation is
working.
I must admit I never tried the CLI during my development of the
language override menu, since my own usecase is solely 'forrest run'.
But we do need to generate a static version of our site as well, thus
this is also important to us.
The problem with static builds is a known one in that you can't
build all locales in the same run.
Yes, but if we have an url with foo.html?locale=en then no static
site build will work due to the way Cocoon encodes the url
parameters in the filename. Unless you have found away this.
No. Now that I finally tried a static build, I have found lots of
errors durng the build, all of them belonging to two types:
X [0] wordsdoc/search/
index.html BROKEN:
org.apache.cocoon.environment.commandline.CommandLineRequest.getLocales(
) method not yet implemented!
X [0] /doc/ling/corpus-conversion-
tech.html BROKEN: dispatcherError: 500 - Internal server error
The contract "siteinfo-meta-navigation" has thrown thrown an
exception by resolving raw data from "cocoon://doc/ling/corpus-
conversion-tech.navigation.xml".
dispatcherErrorStack:
org.apache.excalibur.source.SourceNotFoundException: Exception during
processing of cocoon://doc/ling/corpus-conversion-tech.navigation.xml
The first error is clear enough - no direct support for locales in
the CLI.
The other one is harder - I already saw this error when running
forrest run, but I could not debug it. It seems to be a problem with
HTML source files only, and it is NOT related to dispatcher, despite
the text in the error message. It originates somewhere in the
**book.xml processing, breaking down in a sitemap match for no
appearent reason. More on this later.
The global language default should be set in a config file.
Agree, I just don't know how to do it.
It depends if you want to make your work compatible with 0.7
version of Forrest. If you do then see [1], but for an easier way
in 0.8 see [2]
0.8 is fine with us.
Note both of these are issues to document this process, so ask
questions if you don't understand.
Ok, I will.
Ross
[1] http://issues.apache.org/jira/browse/FOR-777
[2] http://issues.apache.org/jira/browse/FOR-588
Sjur
