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]> ----------------------------------------------------------------
