never used that val() trick, it takes care of numeric casts? sounds great. thanks for the info. event after all this time, i learn something new about cf every week i think.

Regarding the MessageFormat numeric stuff, I've haven't run across any issues that using val() in the arrayAppend call didn't solve. Without that, however, plenty of issues. On another app, I'd run into a couple weirdnesses where CF passes a java.lang.Double into a {0,number,integer} format and the formater balks. I think I just used {0,number} in this app, even for integer values, so it wouldn't have arisen.

I've always gone with the dotted notation to differentiate the camel casing. Otherwise is it the 'purchase title' item of the 'add' screen, or is it the 'title' item on the 'add purchase' screen?

well we only use MessageFormat w/rb so that's where we stuck it (and we have enough i18n CFCs running around as it is). you're the 1st person to call it wierd though ;-) btw we've had some issues where numeric data needed to be cast for MessageFormat to swallow it.

"addPurchaseTitle" would be a better choice. or use an addPurchase rb file w/the addPurchase related keys in that. what are you using to manage these? notepad ;-) you can get extra weirdness w/cf as that comes out like a structure's dotted notation (this just came up last week w/somebody's app falling down on railo). as most folks slap the rb into a shared scope per locale.

The locale bits are there, but using ResourceBundle.getBundle() isn't workable without adding your .properties files to the classpath. That's the dependancy I was looking to avoid.

I know I haven't enabled locale-based selection support in the resource bundle loader. Honestly, the i18n was kind of a free bonus, I was externalizing the strings strictly so I could change the terminology on the site easily. I'll add in the locale selection at some point, but I didn't need it up front, so I didn't code it in. ;)

There is MessageFormat support in there to, a simple UDF in Application.cfm that takes the string to format and then Java5-style varargs for the formatting arguments. I suppose it could go on the resource bundle class, but that seems like a weird place to put it. It has nothing to do with resource bundles, but everything to do with formatting in your UI.

Regarding the non-kosher message keys, I don't quite follow. That's just the way I've always done it, because it seemed reasonable enough. What's the "right" way to do it?

your rb keys aren't very "kosher". it would be better not to have dotted keys "addPurchase.title" (if you're doing this to manage these, get an rb tool w/logical groups, etc. instead). the rb CFC's rb finding logic isn't robust, normally you start w/the full rb file & locale (something_en_US.properties) & start chopping back until you hit the base rb (something.properties) or die trying. i guess you might grab my javaRB.cfc it also uses PropertyResourceBundle so it can work w/out the rb files being on the classpath. it also contains a MessageFormat function.

anyway, great to see you kept i18n in mind when you developed this. and it looks to be a pretty useful app.

thanks.

So it's still an environment mapping, even though it's not server-wide, just web-root wide.