Hey everyone,
while trying to localise our webstore I got a little confused over the use of the localeString. I noticed that the setSessionLocale uses the simple 2 char string to set the locale (eg: en for English and de for German and so on), yet sometimes the longer form of 4chars is used, ie de_DE or en_US. Now this wouldn't really make a difference to me, but it really ruins all my efforts to localise the content. For some reason my webstore starts with en_US as the locale... but a click on the setSessionLocale widget changes this to de or en respectively, hence all the lookups wouldn't work... is this a known issue or how can i circumvent this? |
I don't understand what you mean by "setSessionLocale uses the simple 2
char string to set the locale" - what makes you think that? It would be helpful if you could list the steps taken to reproduce the problem you are trying to describe (preferably on the demo server). -Adrian madppiper wrote: > Hey everyone, > > while trying to localise our webstore I got a little confused over the use > of the localeString. I noticed that the setSessionLocale uses the simple 2 > char string to set the locale (eg: en for English and de for German and so > on), yet sometimes the longer form of 4chars is used, ie de_DE or en_US. > > Now this wouldn't really make a difference to me, but it really ruins all my > efforts to localise the content. For some reason my webstore starts with > en_US as the locale... but a click on the setSessionLocale widget changes > this to de or en respectively, hence all the lookups wouldn't work... is > this a known issue or how can i circumvent this? |
ah,
this is odd, on the demo server there isn't really anything wrong at all. Perhaps I should describe the problem on my server then. The language ftl file on my server produces the following code: <div id="choose-language" class="screenlet"> <div class="screenlet-header"> <div class="boxhead">Sprache</div> </div> <div class="screenlet-body" style="text-align: center;"> <form method="post" name="chooseLanguage" action="/ecommerce/control/setSessionLocale" style="margin: 0pt;"> <select name="newLocale" class="selectBox" style="width: 95%;" onchange="submit()"> <option dir="ltr" value="en" lang="en">English</option> <option dir="ltr" value="de" lang="de">Deutsch</option> </select> </form> </div> </div> I left the language.ftl itself untouched: <div id="choose-language" class="screenlet"> <div class="screenlet-header"> <div class="boxhead">${uiLabelMap.CommonLanguageTitle}</div> </div> <div class="screenlet-body" style="text-align: center;"> <form method="post" name="chooseLanguage" action="<@ofbizUrl>setSessionLocale</@ofbizUrl>" style="margin: 0;"> <select name="newLocale" class="selectBox" style="width:95%" onchange="submit()"> <#assign availableLocales = Static["org.ofbiz.base.util.UtilMisc"].availableLocales()/> <#list availableLocales as availableLocale> <#assign langAttr = availableLocale.toString()?replace("_", "-")> <#assign langDir = "ltr"> <#if "ar.iw"?contains(langAttr?substring(0, 2))> <#assign langDir = "rtl"> </#if> <option lang="${langAttr}" dir="${langDir}" value="${availableLocale.toString()}"<#if locale.toString() = availableLocale.toString()> selected="selected"</#if>>${availableLocale.getDisplayName(availableLocale)}</option> </#list> </select> </form> </div> </div> but I did edit the general.properties file and set the following: locale.properties.fallback=de # -- locales made available separated by commas locales.available=de,en Perhaps this is really a configuration mishap of mine (which would actually solve several problems of mine at once ;) ), but why would it only display the first two chars of the actual localeString? |
The locales listed in the Select Locale screen are controlled by the
locales.available property in general.properties. If you are only seeing two locales listed, then it is because you changed the locales.available property to display only two locales. The locale.properties.fallback property in general.properties should not be changed. Changing it to de will throw exceptions when there is no de translation found (which is often the case). When you change that property to de, you are telling OFBiz, "If you can't find a German translation, then fall back to the German translation" - which wouldn't make any sense. If your intention is to make German the default language, then you want to change the ofbiz.locale.default property in start.properties. -Adrian madppiper wrote: > ah, > > this is odd, on the demo server there isn't really anything wrong at all. > Perhaps I should describe the problem on my server then. The language ftl > file on my server produces the following code: > > <div id="choose-language" class="screenlet"> > <div class="screenlet-header"> > <div class="boxhead">Sprache</div> > </div> > <div class="screenlet-body" style="text-align: center;"> > <form method="post" name="chooseLanguage" > action="/ecommerce/control/setSessionLocale" style="margin: 0pt;"> > > <select name="newLocale" class="selectBox" style="width: 95%;" > onchange="submit()"> > <option dir="ltr" value="en" lang="en">English</option> > <option dir="ltr" value="de" lang="de">Deutsch</option> > </select> > </form> > </div> > </div> > > > I left the language.ftl itself untouched: > > <div id="choose-language" class="screenlet"> > <div class="screenlet-header"> > <div class="boxhead">${uiLabelMap.CommonLanguageTitle}</div> > </div> > <div class="screenlet-body" style="text-align: center;"> > <form method="post" name="chooseLanguage" > action="<@ofbizUrl>setSessionLocale</@ofbizUrl>" style="margin: 0;"> > <select name="newLocale" class="selectBox" style="width:95%" > onchange="submit()"> > <#assign availableLocales = > Static["org.ofbiz.base.util.UtilMisc"].availableLocales()/> > <#list availableLocales as availableLocale> > <#assign langAttr = availableLocale.toString()?replace("_", > "-")> > <#assign langDir = "ltr"> > <#if "ar.iw"?contains(langAttr?substring(0, 2))> > <#assign langDir = "rtl"> > </#if> > <option lang="${langAttr}" dir="${langDir}" > value="${availableLocale.toString()}"<#if locale.toString() = > availableLocale.toString()> > selected="selected"</#if>>${availableLocale.getDisplayName(availableLocale)}</option> > </#list> > </select> > </form> > </div> > </div> > > > but I did edit the general.properties file and set the following: > > locale.properties.fallback=de > > # -- locales made available separated by commas > locales.available=de,en > > > Perhaps this is really a configuration mishap of mine (which would actually > solve several problems of mine at once ;) ), but why would it only display > the first two chars of the actual localeString? |
Oh, yeah, but thats not quite what I meant.
All availableLocales listed in the language.ftl file are displayed as two character values, eg: de instead of de_DE and en instead of en_US. The thing I don't really get is why that is the case... |
If you read my reply again, you will see why this is happening.
-Adrian madppiper wrote: > Oh, yeah, but thats not quite what I meant. > > All availableLocales listed in the language.ftl file are displayed as two > character values, eg: de instead of de_DE and en instead of en_US. > > The thing I don't really get is why that is the case... |
you are bloody brilliant :)
thanks alot!!! |
Perhaps the last message was a little premature. I changed the start.properties (default lang is now de) file and changed the general.properties file as you suggested (fallback is now en). Still the dropdowns in the ecommerce application remain de and en --> not the expected en_US and de_DE
|
Did you change the locales.available property in general.properties so
that it contains all of the locales you want? -Adrian madppiper wrote: > Perhaps the last message was a little premature. I changed the > start.properties (default lang is now de) file and changed the > general.properties file as you suggested (fallback is now en). Still the > dropdowns in the ecommerce application remain de and en --> not the expected > en_US and de_DE |
Yup :)
It reads: # -- locales made available separated by commas locales.available=de,en And again, the problem is not that only those two languages are available - that works as planned. The Problem is that the language.ftl file displays the values of the options on the selectbox as de and en instead of the de_DE and en_US values. So once anybody attempts to set the locale, it'll be defined as de or en and this gives me problems on the content management system (and localisation of products / categories) as the cms looks for a datasource with the localeString en_US or de_DE and not en or de... |
I don't know how to make this any clearer, but I'll give it one last try...
If you want the available selections to be en_US and de_DE, then locales.available should contain en_US and de_DE, NOT en and de. -Adrian madppiper wrote: > Yup :) > > It reads: > > # -- locales made available separated by commas > locales.available=de,en > > > And again, the problem is not that only those two languages are available - > that works as planned. The Problem is that the language.ftl file displays > the values of the options on the selectbox as de and en instead of the de_DE > and en_US values. So once anybody attempts to set the locale, it'll be > defined as de or en and this gives me problems on the content management > system (and localisation of products / categories) as the cms looks for a > datasource with the localeString en_US or de_DE and not en or de... |
Well, I am still confused. I got the part that I can change the available languages in the general.properties file. The confusion does not arise there. The confusion i got is the following:
What is the difference between en and en_US and de/de_DE respectively? Why are there 2 different choices for the languages and if I want my page to run in English and German would I choose en and de or en_US and de_DE for it? If I choose en and de, how would that affect the DataResource-Entries in the OFBiz CMS? Do they still need to have the localeString set to en_US and or de_DE? And why would would the setting of de in the start.properties file still resolve to de_DE in the locale on startup, if de is set through the setSessionLocale command, the locale will change to de and not de_DE as on the start.properties file... It all comes down to this: why two different localeStrings (eg: de and de_DE) if they both mean the same? Sorry, if I still couldn't make myself clear about what my question is - your help is well appreciated... |
http://www.google.com/search?source=ig&hl=en&rlz=&q=java+locale&btnG=Google+Search&aq=f On Feb 12, 2009, at 10:53 AM, madppiper wrote: > > Well, I am still confused. I got the part that I can change the > available > languages in the general.properties file. The confusion does not arise > there. The confusion i got is the following: > > What is the difference between en and en_US and de/de_DE > respectively? Why > are there 2 different choices for the languages and if I want my > page to run > in English and German would I choose en and de or en_US and de_DE > for it? > > If I choose en and de, how would that affect the DataResource- > Entries in the > OFBiz CMS? Do they still need to have the localeString set to en_US > and or > de_DE? And why would would the setting of de in the start.properties > file > still resolve to de_DE in the locale on startup, if de is set > through the > setSessionLocale command, the locale will change to de and not de_DE > as on > the start.properties file... > > It all comes down to this: why two different localeStrings (eg: de and > de_DE) if they both mean the same? > > Sorry, if I still couldn't make myself clear about what my question > is - > your help is well appreciated... > -- > View this message in context: http://www.nabble.com/Confused-over-localeString-tp21952500p21981251.html > Sent from the OFBiz - User mailing list archive at Nabble.com. > |
In reply to this post by madppiper-2
http://java.sun.com/j2se/1.5.0/docs/api/java/util/Locale.html
madppiper wrote: > Well, I am still confused. I got the part that I can change the available > languages in the general.properties file. The confusion does not arise > there. The confusion i got is the following: > > What is the difference between en and en_US and de/de_DE respectively? Why > are there 2 different choices for the languages and if I want my page to run > in English and German would I choose en and de or en_US and de_DE for it? > > If I choose en and de, how would that affect the DataResource-Entries in the > OFBiz CMS? Do they still need to have the localeString set to en_US and or > de_DE? And why would would the setting of de in the start.properties file > still resolve to de_DE in the locale on startup, if de is set through the > setSessionLocale command, the locale will change to de and not de_DE as on > the start.properties file... > > It all comes down to this: why two different localeStrings (eg: de and > de_DE) if they both mean the same? After you read the information in the link I provided, you will see that de and de_DE are NOT the same. -Adrian |
Free forum by Nabble | Edit this page |