You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@forrest.apache.org by "Thorsten Scherler (JIRA)" <ji...@apache.org> on 2006/09/20 16:00:22 UTC
[jira] Commented: (FOR-934) i18n language override menu
[ http://issues.apache.org/jira/browse/FOR-934?page=comments#action_12436238 ]
Thorsten Scherler commented on FOR-934:
---------------------------------------
I had a quick look at the patch and it would make a good plugin.
Since the dispatcher contract is only a small part of the overall code and the code is not limited to the dispatcher it makes sense to create a plugin out of it.
wdyt?
> i18n language override menu
> ---------------------------
>
> Key: FOR-934
> URL: http://issues.apache.org/jira/browse/FOR-934
> Project: Forrest
> Issue Type: Improvement
> Components: Dispatcher (aka views), Internationalisation (i18n)
> Affects Versions: 0.8-dev
> Reporter: Sjur N. Moshagen
> Attachments: i18n-languages.zip
>
>
> Attached is a dispatcher contract with support files. It will return a list of alternative languages available for a given document. The list is of the form:
> <!--+ |start language list +-->
> <span>
> <a href="?locale=en">en</a>
> </span>
> <span>
> <a href="?locale=fi">fi</a>
> </span>
> <span>
> <a href="?locale=nb">nb</a>
> </span>
> <span class="selected">se</span>
> <span>
> <a href="?locale=smj">smj</a>
> </span>
> <!--+ |end language list +-->
> It handles filenames following this scheme (convention is already established for Forrest):
> document.XY.extension (XY = locale/language of document)
> document.extension (fallback document)
> If there is a fallback document, the contract will try to look inside the document to see if it can find an @xml:lang or @lang attribute to associate a language with the fallback document.
> The contract returns a list of available languages, including the one being displayed. The displayed language is marked with @class="selected" in the output html.
> If there is only one document available (=no alternating languages), the contract only returns three comments (start, end, and a comment stating that there's no alternative).
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [jira] Commented: (FOR-934) i18n language override menu
Posted by Cyriaque Dupoirieux <Cy...@pcotech.fr>.
Ross Gardler a écrit :
> Sjur Moshagen wrote:
>> Den 20. sep. 2006 kl. 17.00 skrev Thorsten Scherler (JIRA):
>>
>>> [
>>> http://issues.apache.org/jira/browse/FOR-934?page=comments#action_12436238
>>> ]
>>>
>>> Thorsten Scherler commented on FOR-934:
>>> ---------------------------------------
>>>
>>> I had a quick look at the patch and it would make a good plugin.
>>>
>>> Since the dispatcher contract is only a small part of the overall
>>> code and the code is not limited to the dispatcher it makes sense to
>>> create a plugin out of it.
>>>
>>> wdyt?
>>
>> Sure, that way I guess it would be available both to dispatcher and
>> non-dispatcher users. One could argue that this i18n-functionality
>> should really be part of the core, to make the i18n services of
>> Forrest complete, though.
>
> 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.
>
> Ross
>
>
+1 to include it in the core...
Re: [jira] Commented: (FOR-934) i18n language override menu
Posted by Ross Gardler <rg...@apache.org>.
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?
By definition core is not equal to a plugin. More on this at the end.
>> I think we should split the *whole* core into plugins, that will help to
>> refactor and simplify the code. Now we have spread the e.g. i18n code
>> all over our core. Ugly for understanding, ugly to maintain.
If it can work like that then I agree it is a good idea, but...
>> We already agreed that we would need a skin plugin as well, which is as
>> well a core feature, or?
No skins are not core features. Core works with XDocs, output plugins
provide a final format that is not predefined by core. One does not have
to work with any particular output plugin, one can work directly with
XDocs, i.e. core.
>> IMO *everything* should go into plugins and the core would be just a
>> couple of sitemaps. Maybe we should restructure the locations for
>> plugins:
>> tree $FORREST_HOME/plugins
>> .
>> |-- core
>> |-- incubator (the plugins from the whiteboard)
>> `-- optional
Again, I agree in principle. But will it work...
>> Starting an i18n plugin and move all code to there has much more
>> benefits (keeping documentation and code releated to i18n in one place)
>> and this is why we introduced plugins in the first place, or?
Yes, that is why plugins were introduced. And (I'm repeating myself), if
it can work I agree it should be a plugin, but...
>> So I am -1 to put it in the core, as long someone names a *good* reason
>> to put it in core?
OK, lets consider..
>
> One good reason could be that i18n processing cuts across all other
> processing - irrespective of which plugins you employ, i18n should work.
> i18n configuration and support should be centralised and available to
> all plugins.
...
> Another reason is to ensure proper and systematic support for i18n in
> all places. Forrest has been a bit patchy when it comes to i18n support,
> and still is. This makes for a bad user experiense, both for an advanced
> user developing web solutions with Forrest, and for end users of that
> web solution. When you need i18n support, you want it to work
> everywhere, with all plugins and all your documents, in all running
> environments.
Exactly my thinking. To expand...
The problem with i18n is that it is fundamental to the resolution of
resources for the *internal* processing of a request. As a result, it
touches a great many matches in the sitemap.
Now consider that I may want to write an internal plugin that modifies
some of the internal matches in our pipelines (like the dispatcher). I
need to ensure that I do not break the i18n behaviour of those matches.
If they i18n stuff is in core then no problem, I simply override the
matches I want and handle i18n accordingly.
However, if the i18n handling is in a plugin I have to override those
matches too which means that we are creating a dependency between the
two plugins.
Now we have a situation of a plugin developer who is not using the i18n
features creating a plugin that is likely to break the i18n behaviour
because they do not address those issues. Furthermore, changes to the
i18n plugin will result in changes being needed in all internal plugins.
It is true that changes in core i18n handling would also result in the
need to change internal plugins. But we expect all plugin maintainers to
monitor core, we do not expect the to monitor all plugins (at least I do
not expect them to do so).
At least this is how it worked with the *old* i18n implementation. If
your recent work (which I have not followed closely) removes this
dependency then this is not a strong enough argument for you to remove
your -1. Like I said before, I'm +0 for core, -0 for a plugin. If my
argument above does not stand then go ahead and make the plugin, I trust
your judgment.
> After some consideration, I would actually say that if any feature
> should stay in the core and not be made a plugin, it is i18n support.
To generalise that I would suggest, "any feature that works on
*internal* processes should be part of core. Any feature that touches
only input or output processes should be plugins."
Internal plugins were only ever intended [1] to allow the handling of
new formats for internal documents, such as IMS Manifests to site.xml.
They were not, and in my opinion, should not be intended for core
functionality.
We can still separate the code by using sitemap mounting, after all,
that is what an internal plugin does.
Ross
[1] this intention was my own, as as original author, as opposed to the
community leveraging that code, which has used it to rewrite whole
chunks of core
Re: [jira] Commented: (FOR-934) i18n language override menu
Posted by Ross Gardler <rg...@apache.org>.
Sjur Moshagen wrote:
> Den 22. sep. 2006 kl. 11.58 skrev Ross Gardler:
...
> 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:-)
That's cool. Anyone using skins that needs this can do the work
themselves. The key is that you have implemented it in such a way that
allows them to leverage your contribution.
Wherever this goes (plugin or core) we need to create an issue with a
link to your notes in this thread so that anyone coming later, who wants
to use it in skins can do so.
Ross
Re: [jira] Commented: (FOR-934) i18n language override menu
Posted by Sjur Moshagen <sj...@mac.com>.
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
Re: [jira] Commented: (FOR-934) i18n language override menu
Posted by Ross Gardler <rg...@apache.org>.
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?
Ross
Re: [jira] Commented: (FOR-934) i18n language override menu
Posted by Sjur Moshagen <sj...@mac.com>.
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?
>
> I think we should split the *whole* core into plugins, that will
> help to
> refactor and simplify the code. Now we have spread the e.g. i18n code
> all over our core. Ugly for understanding, ugly to maintain.
>
> We already agreed that we would need a skin plugin as well, which
> is as
> well a core feature, or?
>
> IMO *everything* should go into plugins and the core would be just a
> couple of sitemaps. Maybe we should restructure the locations for
> plugins:
> tree $FORREST_HOME/plugins
> .
> |-- core
> |-- incubator (the plugins from the whiteboard)
> `-- optional
>
>
> Starting an i18n plugin and move all code to there has much more
> benefits (keeping documentation and code releated to i18n in one
> place)
> and this is why we introduced plugins in the first place, or?
>
> So I am -1 to put it in the core, as long someone names a *good*
> reason
> to put it in core?
One good reason could be that i18n processing cuts across all other
processing - irrespective of which plugins you employ, i18n should
work. i18n configuration and support should be centralised and
available to all plugins. Perhaps a plugin could do this job, but the
present i18n sitemap does not work with the dispatcher (I haven't
tried with a non-dispatcher setting), and duplicates some of the i18n
configuration in the main sitemap. Which kind of proves my point -
decoupling i18n processing from the core (sitemap) does not seem like
a good idea to me.
Another reason is to ensure proper and systematic support for i18n in
all places. Forrest has been a bit patchy when it comes to i18n
support, and still is. This makes for a bad user experiense, both for
an advanced user developing web solutions with Forrest, and for end
users of that web solution. When you need i18n support, you want it
to work everywhere, with all plugins and all your documents, in all
running environments.
The bug I reported earlier today is an illustration of my point.
After some consideration, I would actually say that if any feature
should stay in the core and not be made a plugin, it is i18n support.
As I see it, the problems with i18n support in Forrest is symptomatic
of its origin: it was added more as an afterthought, and not as a
feature built-in from the very beginning. I believe the way to fix it
is *not* to remove it from the core, rather the contrary.
Just my few cents.
Best regards,
Sjur
Re: [jira] Commented: (FOR-934) i18n language override menu
Posted by Thorsten Scherler <th...@wyona.com>.
On Wed, 2006-09-20 at 16:42 +0100, Ross Gardler wrote:
> Sjur Moshagen wrote:
> > Den 20. sep. 2006 kl. 17.00 skrev Thorsten Scherler (JIRA):
> >
> >> [
> >> http://issues.apache.org/jira/browse/FOR-934?page=comments#action_12436238
> >> ]
> >>
> >> Thorsten Scherler commented on FOR-934:
> >> ---------------------------------------
> >>
> >> I had a quick look at the patch and it would make a good plugin.
> >>
> >> Since the dispatcher contract is only a small part of the overall code
> >> and the code is not limited to the dispatcher it makes sense to create
> >> a plugin out of it.
> >>
> >> wdyt?
> >
> > Sure, that way I guess it would be available both to dispatcher and
> > non-dispatcher users. One could argue that this i18n-functionality
> > should really be part of the core, to make the i18n services of Forrest
> > complete, though.
>
> 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?
I think we should split the *whole* core into plugins, that will help to
refactor and simplify the code. Now we have spread the e.g. i18n code
all over our core. Ugly for understanding, ugly to maintain.
We already agreed that we would need a skin plugin as well, which is as
well a core feature, or?
IMO *everything* should go into plugins and the core would be just a
couple of sitemaps. Maybe we should restructure the locations for
plugins:
tree $FORREST_HOME/plugins
.
|-- core
|-- incubator (the plugins from the whiteboard)
`-- optional
Starting an i18n plugin and move all code to there has much more
benefits (keeping documentation and code releated to i18n in one place)
and this is why we introduced plugins in the first place, or?
So I am -1 to put it in the core, as long someone names a *good* reason
to put it in core?
salu2
--
Thorsten Scherler
COO Spain
Wyona Inc. - Open Source Content Management - Apache Lenya
http://www.wyona.com http://lenya.apache.org
thorsten.scherler@wyona.com thorsten@apache.org
Re: [jira] Commented: (FOR-934) i18n language override menu
Posted by Ross Gardler <rg...@apache.org>.
Sjur Moshagen wrote:
> Den 20. sep. 2006 kl. 17.00 skrev Thorsten Scherler (JIRA):
>
>> [
>> http://issues.apache.org/jira/browse/FOR-934?page=comments#action_12436238
>> ]
>>
>> Thorsten Scherler commented on FOR-934:
>> ---------------------------------------
>>
>> I had a quick look at the patch and it would make a good plugin.
>>
>> Since the dispatcher contract is only a small part of the overall code
>> and the code is not limited to the dispatcher it makes sense to create
>> a plugin out of it.
>>
>> wdyt?
>
> Sure, that way I guess it would be available both to dispatcher and
> non-dispatcher users. One could argue that this i18n-functionality
> should really be part of the core, to make the i18n services of Forrest
> complete, though.
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.
Ross
Re: [jira] Commented: (FOR-934) i18n language override menu
Posted by Sjur Moshagen <sj...@mac.com>.
Den 20. sep. 2006 kl. 17.00 skrev Thorsten Scherler (JIRA):
> [ http://issues.apache.org/jira/browse/FOR-934?
> page=comments#action_12436238 ]
>
> Thorsten Scherler commented on FOR-934:
> ---------------------------------------
>
> I had a quick look at the patch and it would make a good plugin.
>
> Since the dispatcher contract is only a small part of the overall
> code and the code is not limited to the dispatcher it makes sense
> to create a plugin out of it.
>
> wdyt?
Sure, that way I guess it would be available both to dispatcher and
non-dispatcher users. One could argue that this i18n-functionality
should really be part of the core, to make the i18n services of
Forrest complete, though.
But I have no strong feelings.
Sjur