forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sjur Moshagen <sju...@mac.com>
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  
simple.
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  
playground:-)

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

Sjur


Mime
View raw message