Mailing-List: contact dev-help@forrest.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@forrest.apache.org
Received-SPF: neutral (herse.apache.org: local policy)
Mime-Version: 1.0 (Apple Message framework v752.3)
In-Reply-To: <E9659A23-B31A-49B1-9BB6-517FD235FACB@mac.com>
References: <E9659A23-B31A-49B1-9BB6-517FD235FACB@mac.com>
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <B04BAD4E-2E28-4928-8B1F-E4B70F339505@mac.com>
Content-Transfer-Encoding: 7bit
From: Sjur Moshagen <sjurnm@mac.com>
Subject: Re: i18n enhancements of wiki plugin
Date: Wed, 17 Jan 2007 14:19:08 +0200
To: dev@forrest.apache.org

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