forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sjur Nørstebø Moshagen <sjur.mosha...@kolumbus.fi>
Subject Re: i18n suggestion
Date Tue, 16 Mar 2004 07:32:01 GMT
På 16. mar. 2004 kl. 02.55 skrev Dave Brondsema:

> Sjur Nørstebø Moshagen wrote:
> <snip/>
>> Thus, you can localise most things, BUT NOT WHOLE PAGES ON A FILE 
>> LEVEL. This is where the i18nFile generator comes in. We need this 
>> for being able to serve whole pages, where the different 
>> language/locale versions of the page is stored in different files.
> <snip/>
>
> Can this be used in forrest documents?  For example if a page is 
> heavily dependant on graphics and doesn't have much text, it would be 
> easier to maintain one source file that had all the text section 
> translations in it.
> Dave Brondsema

Sure it can be used in Forrest documents, that's the whole idea;)

Seriously, what you describe is conceptually quite different from other 
i18n stuff in Cocoon/Forrest. In all i18n processing discussed so far, 
you allways _replace_ items of the default locale with similar items 
translated to the target locale: text snippets of elements, text of 
attributes, files (the main issue in this thread), and so forth. What 
you are asking for is to _remove_ all items that do NOT belong to the 
requested locale.

That is, it could be seen as a sort of i18n filtering. It does not 
easily fit together with what we have been discussing about the 
generator stuff. Rather, I would suggest to extend the present i18n 
Transformer to allow this type of filtering as opposed to translating 
specific items. You also need to specify the available languages in the 
document to be able to do efficient content negotiation before the 
actual processing applies. This can probably be done using the xml:lang 
attribute on the root element, although it is unclear to me whether 
this attribute can take more than one value (e.g. whether xml:lang="en 
de fr no" is legal). But why not? After the processing, this attribute 
should be changed, to reflect the single remaining language in the 
document.

Another and simpler approach would be to serve the document as is, and 
just use different CSS stylesheets with display:hidden for the 
languages that you don't want to show. It will require a slightly 
higher bandwith, but less processing, and would not require any changes 
to Cocoon nor Forrest. And since there is so little text in the first 
place (that being the reason for keeping all translations in the same 
document), the bandwith issue is no issue in reality, I assume. The CSS 
approach would also facilitate "immediate translation": you could 
create a language menu that would just change the value of display: for 
a given language, and voilá - the whole page is "translated"!

Just my 0,02 €.

Sjur


Mime
View raw message