Issue with i18n.defaultLocale setting

I'd like to set my default application locale to "en" (no country
code), but the Application Loaders do not correctly parse this and my
default locale becomes "en_EN".

I'm pretty sure this is a bug since the country code is an optional
parameter to defining a locale, so ColdBox should check that the
locale consists of a country code before correcting the case of this
setting.

thanks,

.brett

as of now the locale is strict Brett, basically local + country code. I might address this at a later version or something we can all tackle, but as of now, I don’t have a high priority on that issue.

Luis F. Majano
President
Ortus Solutions, Corp

ColdBox Platform: http://www.coldbox.org
Linked In: http://www.linkedin.com/pub/3/731/483
Blog: http://www.luismajano.com
IECFUG Manager: http://www.iecfug.com

Fair enough.

Another issue, in /coldbox/samples/includes/i18n/ there is a bundle
without a locale specified (I'm assuming this is the bundle
template). I was trying to load that with the ResourceBundle plugin
but there is no way to load it because CB assumes you will never pass
in an empty locale value, and a hardcoded underscore gets added to the
file name producing a lookup for includes/i18n/main_.properties.

I guess I will have to work around these issues for now, kinda a pain.

Yes the original.Implementation was strict but.if you can provide a patch that would be great

Cool, how do I submit a patch?

you can post it here if you like?

Also, as an open discussion to the group, what would be the best way for people to contribute patches?

Luis F. Majano
President
Ortus Solutions, Corp

ColdBox Platform: http://www.coldbox.org
Linked In: http://www.linkedin.com/pub/3/731/483
Blog: http://www.luismajano.com
IECFUG Manager: http://www.iecfug.com

you can post it here if you like?

Sure, I'm still working through some changes to it. Will post it when
I'm done.

Also, as an open discussion to the group, what would be the best way for
people to contribute patches?

Personally I would like to see the source hosted at GitHub. I believe
Assembla has integration hooks to do this so we could still use the
Assembla work spaces.

Brett

i'm not exactly sure allowing a language only locale is a "good" idea. while probably understandable for most of the "en" world, spellings certainly differ & in some cases might be considered unprofessional. for other languages ("chinese" for instance), you'd be allowing developers to blindly drive off a cliff.

furthermore this creeps into formatting. what currency symbol does "en" get? ditto for date & number formats. in cf, an "en" locale defaults to "en_US" for formatting which might not be what was intended (and if it was, why not just go with "en_US" in the 1st place).

on principle, i don't think it's such a good idea to allow language & culture to be separated from one another so easily.

Thanks Paul!! I would have to agree with you on this one, basically that is how it works now, it is strict.

Luis F. Majano
President
Ortus Solutions, Corp

ColdBox Platform: http://www.coldbox.org
Linked In: http://www.linkedin.com/pub/3/731/483
Blog: http://www.luismajano.com
IECFUG Manager: http://www.iecfug.com

Hi Paul - Good to know you are on the list, I can't argue with your
point, but....

I have a very liberal view of what a framework should do and allow,
and I see the implementation as broken. It should be up to the
developer to use best practices when developing applications and not a
role of the framework to "keep the developer on the tracks". That
stifles the flexibility and innovation in using the framework.

In my particular case, I'm implementing inheritance in my resource
bundles (see: http://java.sun.com/developer/technicalArticles/Intl/ResourceBundles/
) and ColdBox does not allow you to load a bundle without the full lang
+locale string. (technically you can but you have to name your file
main.en_.properties because it blindly adds the underscore to resolve
the file)

In the end it is a very simple fix to the resourceBundle plugin, and
already I am maintaining a branched version of ColdBox which is why I
wish there was a better way to push patches/fixes upstream to the
source or at least not have to struggle with SVN merging.

Brett,

Also note that 3.0 introduced the extensions location. Basically you can override the core plugins by dropping them in the /extensions/plugins folder. This way you don’t have to branch the core or plugins. You override the plugins as you see fit.

Again, we all have issues and ways to do things, you are not locked to what we decide. However, I tend to agree more on Paul’s views on the current implementation. If somebody does not like it then they can easily override the plugin and use their own. So use the extensions, this will really help out.

You can override ANY core plugin.

Luis F. Majano
President
Ortus Solutions, Corp

ColdBox Platform: http://www.coldbox.org
Linked In: http://www.linkedin.com/pub/3/731/483
Blog: http://www.luismajano.com
IECFUG Manager: http://www.iecfug.com

okay. It still doesn't make sense to me why we just wouldn't fix the
core plug-in, but I'll start going the route of overriding the plugins
and see how that works out as opposed to modifying the core.

Brett

Brett, what about doing that route, and then maybe having a flag in the configuration that can enable disable country locales?

Luis F. Majano
President
Ortus Solutions, Corp

ColdBox Platform: http://www.coldbox.org
Linked In: http://www.linkedin.com/pub/3/731/483
Blog: http://www.luismajano.com
IECFUG Manager: http://www.iecfug.com