Hi Geert,

Is this old problem from November now resolved too?
Where can I find information about how L10N should be implemented now?

Cheers,
Lars

> -----Original Message-----
> From: [EMAIL PROTECTED] 
> [mailto:[EMAIL PROTECTED] On Behalf Of Geert Bevin
> Sent: 25 November 2005 20:51
> To: RIFE users list : questions, bug reports and suggestions.
> Subject: Re: [Rife-users] localized login template
> 
> 
> Hi Lars,
> 
> hmmm, good point, there is no solution for that at the moment.
> 
> This needs some thinking and I'd like to find a solution for 
> it since  
> it seems to be an important oversight. I don't have any real  
> solutions in mind at the moment. If you think of something, shoot,  
> I'll ponder about it too.
> 
> Best regards,
> 
> Geert
> 
> On 25-nov-05, at 19:52, Lars Grupe wrote:
> 
> > Hi Geert.
> >
> > Ok, that's working now, many thx again. :)
> >
> > Now I think I have only one problem.
> > I added some strings to the login template which should be 
> localized. 
> > If I understand it correct the built-in element 
> > rife/authenticated/memory.xml is used to print the template that is 
> > given in the 'template_name' property. Is there a way to 
> submit a path 
> > to the resource bundle and a name of a global variable where the
> > locale
> > should be taken from?
> >
> > Or do you know another solution for my problem?
> >
> > Cheers,
> > Lars
> >
> >> -----Original Message-----
> >> From: [EMAIL PROTECTED] 
> >> [mailto:[EMAIL PROTECTED] On Behalf Of Geert Bevin
> >> Sent: 25 November 2005 15:03
> >> To: RIFE users list : questions, bug reports and suggestions.
> >> Subject: Re: [Rife-users] Embedded elements submissions execution 
> >> order
> >>
> >>
> >> Hi Lars,
> >>
> >> this will work if you make it a globalcookie.
> >>
> >> This also makes sense, since you generally would want the user's 
> >> language preference to be remembered.
> >>
> >> Best regards,
> >>
> >> Geert
> >>
> >> On 25-nov-05, at 14:53, Lars Grupe wrote:
> >>
> >>> Hi Geert,
> >>>
> >>> No, it's not a cookie it's a globalvar, that is defined in
> >> the site as
> >>> follows:
> >>>  <globalvar name="locale"/>
> >>>
> >>> I think the problem is not depedent on the type of global 
> var I use.
> >>>
> >>> I will show you an part of my log file:
> >>>
> >>> [DEBUG] [2005-11-25 14:36:25,187] [init] Home.processElement
> >>> <-- main element
> >>> [DEBUG] [2005-11-25 14:36:25,234] [init] 
> >>> LanguageSelection.processElement  <-- embedded element [DEBUG] 
> >>> [2005-11-25 14:36:25,234] [init] LanguageChanged.processElement
> >>> [DEBUG] [2005-11-25 14:36:25,234] [init]
> >>> LanguageSelection.processElement
> >>> [DEBUG] [2005-11-25 14:36:25,234] [init] MainMenu.processElement
> >>>
> >>> Now the user selects a new language by clicking on a link 
> the will 
> >>> start a submission of the embedded element.
> >>>
> >>> [DEBUG] [2005-11-25 14:36:28,750] [init] Home.processElement
> >>> <-- main element
> >>> [DEBUG] [2005-11-25 14:36:28,765] [init] Language selected
> >>> <-- submission of embedded element
> >>> [DEBUG] [2005-11-25 14:36:28,765] [init] 
> >>> LanguageChanged.processElement [DEBUG] [2005-11-25 14:36:28,765] 
> >>> [init] LanguageSelection.processElement
> >>> [DEBUG] [2005-11-25 14:36:28,781] [init] MainMenu.processElement
> >>>
> >>> In the second main element line I would like to know to
> >> which language
> >>> was selected in the embedded element. But the submission 
> is called 
> >>> later, what I understand. But now the global variable has
> >> been changed
> >>> but the page is displayed in the old language. Another click will 
> >>> change the language on the page. So that is not what I 
> would like to 
> >>> have:
> >>> E.g.: On an English page you click on 'German' and the 
> page is shown 
> >>> again in 'English', if you choose another link, than the 
> language of 
> >>> the page will be 'German'.
> >>>
> >>> So my problem is, if I could manage that with a embedded 
> element? I 
> >>> would like to prevent from writing a changeLanguage 
> submission for 
> >>> each element.
> >>>
> >>> Cheers,
> >>> Lars
> >>>
> >>>
> >>>> -----Original Message-----
> >>>> From: [EMAIL PROTECTED] 
> >>>> [mailto:[EMAIL PROTECTED] On Behalf Of Geert Bevin
> >>>> Sent: 25 November 2005 13:06
> >>>> To: RIFE users list : questions, bug reports and suggestions.
> >>>> Subject: Re: [Rife-users] Embedded elements submissions 
> execution 
> >>>> order
> >>>>
> >>>>
> >>>> Hi Lars,
> >>>>
> >>>> I don't mind answering your questions ;-)
> >>>>
> >>>> Embedded elements are only processed once you obtain an
> >> instance of
> >>>> the template in which they are embedded.
> >>>>
> >>>> What global variable are you changing, a cookie?
> >>>>
> >>>> Geert
> >>>>
> >>>> On 25-nov-05, at 13:01, Lars Grupe wrote:
> >>>>
> >>>>> Hi Geert,
> >>>>>
> >>>>> I'm sorry to bother you with my questions.
> >>>>>
> >>>>> I have an embedded elements, that show some links on my 
> page. For 
> >>>>> better understanding: Follow a link should change the
> >>>> language of the
> >>>>> site. If a link is followed than the called submission 
> changes a 
> >>>>> global variable. My problem is that the submission of the
> >> embedded
> >>>>> element is called after the processElement function of my main 
> >>>>> element. Should the submission of the embedded element force a 
> >>>>> reload of the page? And how can I do this? Or is there another 
> >>>>> option to execute the submission of
> >> the embedded
> >>>>> element before the processElement function of the main 
> element is 
> >>>>> called?
> >>>>>
> >>>>> Cheers,
> >>>>> Lars
> >>>>> _______________________________________________
> >>>>> Rife-users mailing list
> >>>>> Rife-users@uwyn.com
> >> http://www.uwyn.com/mailman/listinfo/rife-> users
> >>>>>
> >>>>
> >>>> --
> >>
> >>>> Geert Bevin                       Uwyn
> >> bvba
> >>>> "Use what you need"               Avenue de Scailmont 34
> >>>> http://www.uwyn.com               7170 Manage, Belgium
> >>>> gbevin[remove] at uwyn dot com    Tel +32 64 84 80 03
> >>>>
> >>>> PGP Fingerprint : 4E21 6399 CD9E A384 6619  719A C8F4 D40D
> >> 309F D6A9
> >>>> Public PGP key  : available at servers pgp.mit.edu, 
> wwwkeys.pgp.net
> >>>>
> >>>>
> >>>> _______________________________________________
> >>>> Rife-users mailing list
> >>>> Rife-users@uwyn.com 
> http://www.uwyn.com/mailman/listinfo/rife-users
> >>>>
> >>> _______________________________________________
> >>> Rife-users mailing list
> >>> Rife-users@uwyn.com 
> http://www.uwyn.com/mailman/listinfo/rife-> users
> >>>
> >>
> >> --
> 
> >> Geert Bevin                       Uwyn 
> bvba
> >> "Use what you need"               Avenue de Scailmont 34
> >> http://www.uwyn.com               7170 Manage, Belgium
> >> gbevin[remove] at uwyn dot com    Tel +32 64 84 80 03
> >>
> >> PGP Fingerprint : 4E21 6399 CD9E A384 6619  719A C8F4 D40D 
> 309F D6A9 
> >> Public PGP key  : available at servers pgp.mit.edu, wwwkeys.pgp.net
> >>
> >>
> >> _______________________________________________
> >> Rife-users mailing list
> >> Rife-users@uwyn.com http://www.uwyn.com/mailman/listinfo/rife-users
> >>
> > _______________________________________________
> > Rife-users mailing list
> > Rife-users@uwyn.com http://www.uwyn.com/mailman/listinfo/rife-users
> >
> 
> --
> Geert Bevin                       Uwyn bvba
> "Use what you need"               Avenue de Scailmont 34
> http://www.uwyn.com               7170 Manage, Belgium
> gbevin[remove] at uwyn dot com    Tel +32 64 84 80 03
> 
> PGP Fingerprint : 4E21 6399 CD9E A384 6619  719A C8F4 D40D 
> 309F D6A9 Public PGP key  : available at servers pgp.mit.edu, 
> wwwkeys.pgp.net
> 
> 
> _______________________________________________
> Rife-users mailing list
> Rife-users@uwyn.com http://www.uwyn.com/mailman/listinfo/rife-users
> 
_______________________________________________
Rife-users mailing list
Rife-users@uwyn.com
http://lists.uwyn.com/mailman/listinfo/rife-users

Reply via email to