forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sjur Moshagen <sju...@mac.com>
Subject Re: i18n enhancements of wiki plugin
Date Wed, 17 Jan 2007 12:19:08 GMT
Den 17. jan. 2007 kl. 13.39 skrev Sjur Moshagen:

> Now, it *continues* to work with plain content like index.jspwiki.  
> But as soon as I localise it to index.no.jspwiki, I get a file-not- 
> found error. I don't understand why... :-(

I found a pattern, and a (clumsy) work-around:

It seems the i18n matcher needs to have a default/fallback file.  
Adding a file index.jspwiki will let the other localised two be  
accessible.

The next thought was that this was caused by a parameter in the main  
sitemap, so I changed $FORREST_HOME/main/webapp/sitemap.xmap to read  
in the LocaleMatcher config section:

         <use-blank-locale>false</use-blank-locale>

(it used to be true in my local copy).

According to the Cocoon docs it should now NOT be looking for a  
fallback document. But it still does - I get the following error  
message as long as I don't have a fallback file:

Request URI
adm/positions/software_engineer.html

cause
/Users/sjur/Documents/xtdoc/sd/src/documentation/content/xdocs/adm/ 
positions/software_engineer.xml (No such file or directory)

The workaround is thus to make sure I have a(n empty) fallback  
document. Then i18n with wiki files seems to work as it should.

On the other hand, when having a mixture of localised and non- 
localised files, we also need to have access to those non-localised  
files. Thus, we need to leave the use-blank-locale parameter true,  
otherwise Forrest will give a file-not-found error on all non- 
localised files! Since there was no actual difference between the two  
settings, that should not be a problem.

Please note that it does normally not make sense to have a fallback  
document for wiki documents. Since the wiki format is text-only (no  
markup), there is no explicit information about the human language  
used in a particular file within the document content. Thus, to  
detect the language used for further processing (language override  
menu, whatever), the filename is the *only* place where it is  
possible to encode this info.

The question remains why I get a file not found error when leaving  
out the fallback document. LocaleMatcher has a fallback language  
specified, which it could/should use to look up a file, if nothing  
else is found. Thus, as long as one of the localised files is the  
default language, there should be no error.

Sjur


Mime
View raw message