I failed to submit a bug due to jira error. I'll try again this evening. 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.
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. Anyways, this wouldn't be a problem to fix. But even when I set the locale to lt explicitly, localization doesn't work. The i18n wrapper isn't used for Content (content node object I guess). I'll research that in the weekend. Jan, could you give me a hint, how are you doing the localization? 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]> ----------------------------------------------------------------
