JBossDeveloper

It never ends.... ;-)

in LocaleSelector.setLocale() you do this

...
set locale based on language and so on...
...
else
 {
 locale = java.util.Locale.getDefault();
 FacesContext facesContext = FacesContext.getCurrentInstance();
 if (facesContext!=null)
 {
 java.util.Locale defaultLocale = facesContext.getApplication().getDefaultLocale();
 if (defaultLocale!=null) locale = defaultLocale;
 java.util.Locale requestLocale = facesContext.getExternalContext().getRequestLocale();
 if (requestLocale!=null) locale = requestLocale;
 }
 }

messages.properties (happens to be in en_US)
messages_sv_SE.properties
messages_de_DE.properties

 <locale-config>
 <default-locale>de_DE</default-locale>
 <supported-locale>de_DE</supported-locale>
 <supported-locale>en_US</supported-locale>
 <supported-locale>sv_SE</supported-locale>
 </locale-config>

Sure, that would solve the problem, once. But you wouldn't want to have the deployer changing the filenames when he could change a setting in faces-config.xml. In my imaginary company the developers have a standard that says they should always have messages.properties in english :-)

I gotta admit that it seems nuts to say "the default locale is german", but messages.properties is in english....

Well, you could just get rid of messages.properties and only have the other files, IF the localeSelector cared about the "supported locales" settings in faces-config.xml.

To quote myself:

"perwik" wrote:
...IF the localeSelector cared about the "supported locales" settings in faces-config.xml.

1. Read forum
2. Update from CVS
3. Post if still needed

To be able to do this

<h:selectOneMenu value="#{localeSelector.localeString}">
 <f:selectItems value="#{localeSelector.supportedLocales}" />
</h:selectOneMenu>
<h:commandButton action="#{localeSelector.select}" value="#{messages['button.changeLocale']}"/>

 private ArrayList<SelectItem> supportedLocales;

 public String getLocaleString()
 {
 return getLocale().toString();
 }

 public void setLocaleString(String localeString)
 {
 String[] localeParts = localeString.split("_");
 if (localeParts.length > 0)
 {
 this.language = localeParts[0];
 }
 if (localeParts.length > 1)
 {
 this.country = localeParts[1];
 }
 if (localeParts.length > 2)
 {
 this.variant = localeParts[2];
 }
 }

 @Create
 public void setSupportedLocales()
 {
 this.supportedLocales = new ArrayList<SelectItem>();
 Locale supportedLocale;
 SelectItem selectItem;
 FacesContext facesContext = FacesContext.getCurrentInstance();
 for (Iterator it = facesContext.getApplication().getSupportedLocales(); it.hasNext();)
 {
 supportedLocale = (Locale) it.next();
 selectItem = new SelectItem(supportedLocale.toString(), supportedLocale.getDisplayLanguage(supportedLocale));
 this.supportedLocales.add(selectItem);
 }
 }

 public ArrayList<SelectItem> getSupportedLocales()
 {
 return this.supportedLocales;
 }

Ah, that is a nice idea. I will do something like that.

By the way, if you are ever not happy with the algorithm for calculating the locale (which now basically just delegates to JSF), you can simply subclass LocaleSelector, override calculateLocale(), and name your subclass @Name("localeSelector").

Final note: in the latest CVS, changing the locale via localeSelector.select now also changes the locale in use by JSF.

*Oh*, so components in my jar overrides the core ones if they have the same name? I guess I should've known that :-) By the way, what about anotations in the superclass? Are they inherited now? I remember reading something about it not being implemented yet.

No not yet implemented.

I committed that to CVS.