forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sjur Moshagen <>
Subject Re: Dispatcher i18n update + three more issues
Date Tue, 26 Sep 2006 11:49:25 GMT
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  

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:  
) 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- 

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]
> [2]


View raw message