This is good news. I'll report the findings of my (wrapper related) problem at the weekend.
Vytautas Jan Haderka wrote: > On Fri, 2009-09-18 at 15:04 +0300, Vytautas C(ivilis wrote: >> I failed to submit a bug due to jira error. I'll try again this evening. > > It was probably just some intermittent error on the route, i bet if you > try to re-submit it would go through ... seen some issues like that last > night as well. > >> If the locale is set for each resource, and is not set for the whole >> request (which it is I assume), then it would be ok if the locale is set >> for each resource request. > > Well, that is just your definition of "whole" and "resource" request. > The webapp knowns of only "http" request. Each resource (be it main > page, css, js, images, ...) is obtained by issuing separate http > request. What you ask for is to have resources localized based on > whatever locale have been used to obtain the page html. In this case, > however all those subsequent http calls are made based on the url > constructed from the page itself, so you as a templater has a full > control on how they should look like and are free to inject the locale > information in such urls to ensure the requests for all the resources > linked from the page are localized the same way. > >> Now it seems (yet not 100% sure), that the locale is set for whole >> request when parsing each separate resource uri. >> >> So, if in single request the uri's parsed are like (in sequence): >> - /magnoliaAuthor/lt/myproject/News-overview/news02.htm (locale is set >> to lt) >> - /resources/template-kit/mycss.css (locale is set back to en) >> - /resources/template-kit/myjs.js (locale is set back to en) >> >> So basically, the locale for request set is dependent on the sequence in >> which the uri's are parsed. >> That sounds like a problem to me. > > Again, I disagree with you here since it has nothing to do with a > sequence. your browser requests > the /magnoliaAuthor/lt/myproject/News-overview/news02.htm (with the > locale set to lt), the locale is found in url and set properly., while > parsing received html from this localized page, browser find links to > non-localized resource urls and requests them (non-localizeD), hence > they are correctly served with the fallback locale. > > BTW, there is also RequestLocaleAwareI18nContentSupport class ... you > might want to use for cocalization that one instead of the default one > if you want to have your localization based not on path, but on the > client locale. ;) > >> Jan, could you give me a hint, how are you doing the localization? > > Uh, as I said I used the EE version of the I18Support. All I did was > enabling the i18n support, setting the proper class for it, setting > locale in the site configuration and then just called the pages with > virtual urls /en/Event-overview/event01.htm > or /de/Event-overview/event01.htm to get the pages localized (i.e. with > dates and calendar in given language) ... no magic involved. > > Jan > >> Vytautas >> >> Jan Haderka wrote: >>> I'm not so sure that this is a bug ... let me explain: >>> - you enable (explicitly) i18n support >>> - you specify that if the resource for requested locale doesn't exist, >>> the "fallback" locale should be used >>> - since it is quite often requirement to localize even the images >>> (specially when they might contain some text), all the resources needs >>> to be parsed. >>> >>> now coming to your scenario - the request comes and the i18n support >>> tries for find a localized version of it, since it if not found (the non >>> locale aware url), the system falls back in the default (fallback) >>> locale, changing the unsupported locale in the request to the fallback >>> one, so in case any process further down depends on supported locale >>> being set, it will be set. >>> >>> Now one can argue that system should perhaps look at the list of all >>> known/supported locales and if the current one is in the list, it should >>> not try to change it to the fallback, but since it would introduce yet >>> another special case i'm sure there are arguments against it as well. >>> Plus if your processing of the resources needed to be locale aware,, >>> would you not have taken care of localizing the resource urls first? >>> >>> Anyway feel free to submit the bug report you mentioned and lets see how >>> the discussion develops from there. >>> >>> Cheers, >>> Jan >>> >>> On Thu, 2009-09-17 at 19:50 +0300, Vytautas C(ivilis wrote: >>>> Ok, this is clearly a bug either in DefaultI18nContentSupport, or in >>>> other place: >>>> >>>> This support DefaultI18nContentSupport is called for each requested >>>> resource, independetly of it's origin. >>>> >>>> So, the resource uri like >>>> /stk-resources/site/resources/myProject/css/crealty.css is parsed for >>>> locale, it blindly takes stk-resources, and creates the Locale object >>>> out of it. >>>> >>>> Then at isLocaleSupported such a locale obviously fails, and it takes >>>> the default locale, so english. >>>> >>>> Because the correct request uri is parsed in the first place, the >>>> following uri's simply override the locale set. >>>> >>>> >>>> I guess I should file a bug, so I'll do that I guess? >>>> >>>> Vytautas >>>> >>>> >>>> Jan Haderka wrote: >>>>> On Thu, 2009-09-17 at 18:16 +0300, Vytautas C(ivilis wrote: >>>>>> Thank you for quick answer. >>>>>> >>>>>> The configuration attached. >>>>>> I've tried de locale too. >>>>>> >>>>>> To make it clear, I use the url as such: >>>>>> http://localhost:8080/magnoliaAuthor/magnoliaAuthor/de/myPage/.. >>>>> double occurrence of "magnoliaAuthor" ... is that just a typo? If not >>>>> then this would explain the issue at DefaultI18ContentSupport class >>>>> looks for the lang code only at the first subfolder after the context >>>>> path (i.e. after the first "magnoliaAuthor"). >>>>> >>>>> Other wise your configuration looks fine. You might want to try to >>>>> attach debugger to the methods in DefaultI18ContentSupport to see if the >>>>> translation is called at all and if it yields correct results and if so >>>>> then where later it gets lost. >>>>> >>>>> Truth to say, I have used the STK i18n only in the EE so using the >>>>> ETKI18nContentSupport instead of the default one, but I believe the >>>>> default should work as well. >>>>> >>>>> Cheers, >>>>> Jan >>>>> >>>>>> So, no country code. >>>>>> >>>>>> Vytautas >>>>>> >>>>>> >>>>>> Jan Haderka wrote: >>>>>>>> It looks like it doesn't react to url at all, but instead depends on >>>>>>>> client locale? On the other hand, if I enter unsupported locale, e.g. >>>>>>>> ru, then resource not found happens (correct behavior). >>>>>>>> >>>>>>> If that's the case I suspect it is more related to the i18n support >>>>>>> configuration ... can you provide screenshot or export of what you have >>>>>>> under config:/server/i18n/content and its children? >>>>>>> >>>>>>> Thanks, >>>>>>> Jan >>>>>>> >>>>>>> >>>>>>> ---------------------------------------------------------------- >>>>>>> For list details see >>>>>>> http://www.magnolia-cms.com/home/community/mailing-lists.html >>>>>>> To unsubscribe, E-mail to: <[email protected]> >>>>>>> ---------------------------------------------------------------- >>>>>>> >>>>>>> >>>>>> ---------------------------------------------------------------- >>>>>> For list details see >>>>>> http://www.magnolia-cms.com/home/community/mailing-lists.html >>>>>> To unsubscribe, E-mail to: <[email protected]> >>>>>> ---------------------------------------------------------------- >>>>> ---------------------------------------------------------------- >>>>> For list details see >>>>> http://www.magnolia-cms.com/home/community/mailing-lists.html >>>>> To unsubscribe, E-mail to: <[email protected]> >>>>> ---------------------------------------------------------------- >>>>> >>>>> >>>> ---------------------------------------------------------------- >>>> For list details see >>>> http://www.magnolia-cms.com/home/community/mailing-lists.html >>>> To unsubscribe, E-mail to: <[email protected]> >>>> ---------------------------------------------------------------- >>> >>> ---------------------------------------------------------------- >>> For list details see >>> http://www.magnolia-cms.com/home/community/mailing-lists.html >>> To unsubscribe, E-mail to: <[email protected]> >>> ---------------------------------------------------------------- >>> >>> >> ---------------------------------------------------------------- >> For list details see >> http://www.magnolia-cms.com/home/community/mailing-lists.html >> To unsubscribe, E-mail to: <[email protected]> >> ---------------------------------------------------------------- > > > ---------------------------------------------------------------- > For list details see > http://www.magnolia-cms.com/home/community/mailing-lists.html > To unsubscribe, E-mail to: <[email protected]> > ---------------------------------------------------------------- > > ---------------------------------------------------------------- For list details see http://www.magnolia-cms.com/home/community/mailing-lists.html To unsubscribe, E-mail to: <[email protected]> ----------------------------------------------------------------
