forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Upayavira>
Subject Re: i18n suggestion
Date Tue, 16 Mar 2004 11:58:59 GMT wrote:

>>Okay. So you're saying that the above method becomes too complex when 
>>you've got multiple formats (four tests per resouce, six source file 
>>types, gives 24 different <map:when> clauses, which certainly is clunky.)
>What I did on forrest was create a resource called "file-resolver" and
>pass the {lang} out of the localeAction:
><map:act type="locale">
>  <map:call resource="file-resolver">
>    <map:parameter name="uri" value="{../1}_{lang}"/>
>  </map:call>
Hmm. You've only used the 'lang' from the locale, and haven't catered 
for the country or variant. That would add two more entries per file 
type, which is why this approach gets rather unwieldy.

>Then use the SourceExistsSelector to find out a localice version of any
>of the sources:
><map:resource name="file-resolver">
>      <map:select type="exists">
>        <map:when test="{project:content.xdocs}{uri}.ihtml">
>        <map:when test="{project:content.xdocs}{uri}.cwiki">
>So what it is missing is to have the default language and the fall-back.
Default language can be handled by a <map:otherwise> getting the default 
locale from <global-variables> in the sitemap (see my previous example).

Fall-back needs to be considered carefully, as static and dynamic have 
different needs. In a static context you want to try a locale, and if 
that fails, give an error. In dynamic, you want to try a locale, and if 
that fails, serve the default language. Otherwise you'll end up with a 
whole pile of apparent translated pages that contain nothing more than 
the default language version.

This only really matters in relation to default fall-back. Fallback on 
multiple locales isn't a problem, because the CLI will just pass in one 
locale at a time.

Now, we have a further problem. The HTTPEnvironment implements both 
request.getLocale() and request.getLocales(), but the LocaleAction only 
uses getLocale, which gets the preferred locale. Therefore, it ignores 
any other language preferences, preventing any fallback to other 
translations on a dynamically hosted site.

So, whatever solution we come up with, must be able to handle fallback 
to other preferred languages, and to the default language, and this must 
work in both static and dynamic modes.


Regards, Upayavira

View raw message