Thats not an bad idea. Really not. It's not the solution for my current problem but maybe for the next client who needs multi-culti.

Should be not so much effort. The multipage skin needs to be adapted a little here first. It should still work and should display only the 'next/prev' links for the selected language. The sitemap must be build from the dmHTML objects titles in the selected language below the navnodes instead from the navnodes, because there is still an single navnode only.

Page calls should go to the navnodes and then must be redirected to the right dmHTML object in the users language by browser settings and/or an session variable.

Nice pills :-) This maybe could work. I'm working through since Saturday evening. Possibly I cannot think clear.

Notations?

Why an single PLP step? Is not my personal business logic. They want it and they get it.

Silvio

Gavin Cooney wrote:
I'm just coming in at the end of this conversation, and trying to
understand it, but I'm wondering if this would not work:

Have a default language (say english) and every content object is in
that language. Then within the same nav node have additional dmHTML
(or a custom multilingual dmHTML object with a field for "language")
objects with other languages.

If you had a session variable (or something) that told you what
language the user prefered, you could easily customise the table of
contents custom tag to show the correct language where possible?

Would this not be a solution? I guess the problem would be that the
navigation would be built based on the default language, not the users
preferred language? Maybe to get around this problem you could make a
naviagtion customtag/rule that would show a teaser display method
rather than just a title? Something like the childlinks rule.

Or maybe i'm taking crazy pills?

And why would the PLP step for each language be so difficult?

Gav


On Sun, 17 Oct 2004 22:17:36 +0200, Micha Schopman <[EMAIL PROTECTED]> wrote:

Well, from a technical perspective it is possible, but I am not the right person 
talking about amounts of time needed for such solutions within FarCry. I do know about 
the aspects of integrating such functionality in a business process.

The biggest obstacle with such an approach is how do you plan to translate. Imagine 
this situation.

homepage
 -- subpage
     -- subpage of subpage
 -- subpage

Let's say you want to translate "subpage of subpage" to another language, but.. you haven't translated 
it's parent "subpage" yet. Where do you want to connect the result of the translation of "subpage of 
subpage" to? There isn't a parent available yet. This immediately forces you to create an exact structure in 
the opposite languages (or as called in a cms, a culture because Switserland only has 4 languages allready).


--- You are currently subscribed to farcry-dev as: [EMAIL PROTECTED] To unsubscribe send a blank email to [EMAIL PROTECTED]


Aussie Macromedia Developers: http://lists.daemon.com.au/







--- You are currently subscribed to farcry-dev as: [EMAIL PROTECTED] To unsubscribe send a blank email to [EMAIL PROTECTED] Aussie Macromedia Developers: http://lists.daemon.com.au/

Reply via email to