forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sjur Nørstebø Moshagen <>
Subject Re: i18n suggestion
Date Mon, 15 Mar 2004 15:10:22 GMT
På 15. mar. 2004 kl. 16.30 skrev Upayavira:

> Sjur Nørstebø Moshagen wrote:
>> The only point about debugging was that it should be _possible_ 
>> (without us doing anything) to request filename_{locale}.html, in the 
>> same way that it is now possible to request menu_{lang}.html.
> Fair enough.

I think it should have been menu_{locale}-filename.html;)

>> 1) i18nFile generator:
> Okay, as I said in a previous mail, I think we might do better with an 
> Input Module: I18NModule. This would enable you to say something like:
> <map:match pattern="**/*.html">
>  <map:generate src="{1}/{i18n:{2}.{locale}.xml}"/>
> So, we'd be using the file generator still, as all we need is a 
> filename conversion. And so long as we can come up with a suitable 
> module syntax, it should be easier to implement.

Sounds fine (you are the expert here, I'm just trying to understand and 
learn Cocoon;)

>> Thus, you can localise most things, BUT NOT WHOLE PAGES ON A FILE 
>> LEVEL. This is where the i18nFile
> Exactly my problem right now too!


> What we need to do is generalise out the stuff to do with filename 
> handling, and have a module share its code.

Sounds OK - except that I don't understand the last part;)

>> My suggestion is thus to extend the present i18n block with one more 
>> function, which should be easily based on what's already there.
> Exactly. Except for that it isn't a block, it is core functionality.

Still learning...

>> In the case that there is no localised version of a file, one could 
>> just let the i18nFile generator pick a default file/locale, and save 
>> the static file _without any locale at all_ (but that should not be 
>> the case if even one letter has been localised, i.e. if the menu, or 
>> the tabs, or some other included element is coming from a localised 
>> src - in all these cases the generated static file should be treated 
>> as if it was completely localised).
> Hmm. How to handle defaults, that's interesting.

I am not sure about this - the above is just one possible suggestion. 
Other ideas, anyone? How do we define a default locale for the CLI?

> One remaining point: how do we handle crawling? Do we crawl a page, 
> then seek all translations of it, or do we crawl from each language's 
> homepage, following links that way? Make sense?
> a.html <en
> a.html <de
> b.html <en
> b.html <de
> c.html <en
> c.html <de
> d.html <en
> d.html <de

Maybe this? That is, crawl a page, then all translations of it?


View raw message