Affects Version/s: 6.2.X EE, 7.0.0 Beta 4
Component/s: Sites Administration > Sites
The purpose of the fix is to implement a redirection mechanism for non-group-available locales. It requires the collaboration of I18nServlet and FriendlyURLServlet. The former is for setting the value of i18nLanguageId; the latter is for judging if a redirection should happen according the value of i18nLanguageId.
1. What is kept with fix:
1) We can still use either languageCode, i.e. "/en", or languageId, i.e. "/en_US" as i18n path in URL. In 18nServlet, LocalUtil is for getting locale from lanuageId, and LanguageUtil is for getting locale from languageCode.
2) If LOCALE_USE_DEFAULT_IF_NOT_AVAILABLE as false, we will still get 404 page for non-company-available locales.
3) Which locale to be redirected to is still decided by
2. What is abandoned with fix:
1) We will not use null for non-company-available locales because null is ambigous here. When i18nLanguageId is retrieved as null in FriendlyURLServlet, it has no idea whether it means non-company-available locale, or there is no i18n path in URL. So it cannot decide if a redirection should occur.
2) We will not use default locale as i18nLanguageId in I18nServlet, as this will break the judgement of whether a rediretion should happen later in FriendlyURLServlet.
3. What is introduced with fix:
1) We will keep the i18nLanguageId as honest. If we can get locale represented by i18n path in URL, it will be a languageId, i.e "en_US"; If we cannot get this locale, we will keep i18nLanguageId as whatever in i18n path in URL. It might be either languageId or languageCode in this case.
2) I18nServlet will not check if the i18nLanguageId to be returned is company-available unless property LOCALE_USE_DEFAULT_IF_NOT_AVAILABLE as FALSE, which then will return 404 page.
3) In FriendlyURLServlet, i18nLanguageId alone is able to decide whether a redirection should happen, the judgement is :
, which returns TRUE means a redirection should happen and vise versa.
There are 6 senarios in total :
1) Senario1: non-company-available(Of course it is non-group-available) locale's languageId (i.e. fr_FR for French), URL as "localhost:8080/fr_FR/web/guest/home"
In this case, i18nLanguageId is "fr_FR" becuase LocaleUtil in 18nServlet will not care if returned locale is group-available or company-available, and the judgement return TRUE as although it is a valid languageId, but its not group-available.
2) Senario2: non-company-available locale's languageCode (i.e. fr for French), URL as "localhost:8080/fr/web/guest/home"
In this case, i18nLanguageId is "fr" because neither LocaleUtil nor LanguageUtil in i18nServlet is able to get locale, and the judgement return TRUE as fr is not something as languageId. So a redirection happen.
3) Senario3: company-available, but non-group-available languageCode(i.e., hu for Hungarian), URL as "localhost:8080/hu/web/guest/home"
In this case, i18nLanguageId is "hu_HU" because in I18nSevlet, LanguageUtil is able to get company-available locale for languageCode. But the judgement return TRUE as "hu_HU" is not group-available.
4) Senario4: group-available locale's languageId (i.e. en_US for English), URL as "localhost:8080/en/web/guest/home"
In this case, i18nLanguageId is "en_US", and the judgement return FALSE as although it is a valid languageId and group-available.
5) Senario5: group-available locale's languageCode (i.e. en for English), URL as "localhost:8080/en/web/guest/home"
In this case, i18nLanguageId is "en_US" as well, and the judgement return FALSE as although it is a valid languageId and group-available. In i18nServlet, we get i18nLanguageId from locale retrieved by languageCode, e.g."en".
6) Senario6: no i18n path in URL, i.e."localhost:8080/web/guest/home"
In this case, i18nLanguageId is null, and the judgement return TRUE.
Please refer to related LPS to find more informations