forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sjur Moshagen <>
Subject Re: [jira] Commented: (FOR-934) i18n language override menu
Date Fri, 22 Sep 2006 10:09:03 GMT
Den 22. sep. 2006 kl. 11.58 skrev Ross Gardler:

> Sjur Moshagen wrote:
>> Den 21. sep. 2006 kl. 12.10 skrev Thorsten Scherler:
>>>> I've not been following the i18n discussions, but I have to  
>>>> admit that
>>>> when I saw Thorstens comments I wondered "why not core?".
>>>> I'm not doing the work on this so do it however you like. But if  
>>>> you
>>>> want my (possibly uninformed) opinion then I'd say core is the  
>>>> right place.
>>> Hmm, after all the feature contains a dispatcher contract.  
>>> Further who
>>> said core cannot be in a plugin?
> In my previous reply I missed the "contains a dispatcher contract"  
> part...
> I got the impression that this code would work with skins too is  
> that not the case?
> The dispatcher contract should be part of the dispatcher, not part  
> of core, or another internal plugin. We do not have a mechanism for  
> plugin dependencies and I don't think this use case warrants one.
> If the i18n work is useless without this contract then this is of  
> no use to Forrest users who are not using dispatcher, therefore it  
> is a dispatcher feature.
> Can it be generalised for skins?

The work was done within a dispatcher setting, wanting to have a  
language override menu in the dispatcher. I found it way easier to  
add a piece of custom data using the theme/contract model of the  
dispatcher than modifying skins. That said, most of the work can, and  
probably should, be reused and generalised. Thorsten's observation was:

1) there's a contract, but that's only one document. It is pretty  
2) there's a dataURI in the contract, which resolves to some sitemap  
fragments and some XSLTs

1) is only relevant to the dispatcher, but 2) is basically doing the  
same as $FORREST_HOME/main/webapp/i18n.xmap - except that I couldn't  
get it to work, and it does not handle fallback documents at all.

I understand Thorsten such that he suggest to turn 2) into a plugin,  
whereas my intention was to put it in core, essentially replacing or  
augmenting the present i18n.xmap.

So to answer you question:

Yes, it definitely can be generalised for skins, I just don't know  
how it can be integrated with a skin (ie how to modify a skin to  
include the generated list), therefore I chose dispatcher as my  

When generalising for skins, one should probably have another look at  
the final processing steps, which is now done in the contract. My  
idea was that 2) above should provide a simple XML document that  
could be transformed to whatever is wanted in each case - some users  
want to leave out the displayed language, other not, some would like  
to have a list, others a menu, etc. Also, presently i18n markup of  
the final output is done in the contract - that should also be  
considered in the generalised version.

To sum up:
- the contract ( 1) above) should be part of dispatcher
- the real extraction and identification of available languages ( 2)  
above) should be generalised and put somewhere available to both  
skins and dispatcher
- somebody needs to integrate the output of 2) with at least the  
default skin, and have a nice way to turn it on when requested


View raw message