Sjur Moshagen wrote:
Den 23. sep. 2008 kl. 18.58 skrev Ross Gardler:
...
A long time ago I looked at using the locationmap to handle
internationalisation. It never happened because I had no use case for
it and it seems the current i18n solution was sufficient. I wonder if
this is the first use case we have where it is not sufficient.
What would be the benefit compared to the i18n matcher already available
in Cocoon (and thus Forrest)?
If the remote server understands i18n requests then there is no benefit.
In other words, if we want the source to be http://foo.org/bar.xml and
the remote serve honours the language preferences of the client all is well.
However, in this use case the remote server does not honour the clients
i18n settings and the request breaks.
If i18n were handled in the locationmap the developer of the content
object could override default i18n behaviour when needed, such as in
this wiki instance.
BUT...
I've not fully thought this through. I don't have any i18n sites and I'm
not fully up to speed with i18n content negotiation. In other words, my
argument could well be full of holes and I'm not about to start
experimenting with it.
So, feel free to implement something that works for your use case and
retains backward compatability (as discussed) if you don't want to
explore this random thought.
Ross
