Just a couple of quick hints for you since I'm on my way out the door: On handling date, time, and currency formats: Take a look at SetLocale and LSDateFormat, LSTimeFormat, and LSNumberFormat
On currency conversion: You'll need to maintain a conversion matrix in your application that can convert the currencies. Conversion rates are not necessarily bi-directional, so a 1 US$ = .7729 Aus$ can not necessarily be inverted. Take a look at http://finance.yahoo.com/m3?u and do the reverse division, and you'll see why. It's a combination of precision and the effects of currency trading markets (average conversion rates, etc). Languages: Consider keeping the actual text of any messages you're putting on screen in an external resource file or in the database. This way, you can dynamically load a localized "strings" resource without maintaining different instances of pages. I recommend putting them in an XML file named for the locale it contains, and then dynamically loading that XML file into an application-based array or structure when you initialize the application. This also allows you to send out XML files for translation without having to export/import data tables or whole cf templates. Then adding a new locale is as simple as adding a new XML file. General: The following functions will help you handle localized formatting and conversion gracefully (see "International functions" in the CFML Reference): DateConvert, LSIsCurrency, LSParseDateTime, LSParseNumber, GetEncoding, LSCurrencyFormat, LSIsNumeric, LSTimeFormat, GetHttpTimeString, LSDateFormat, LSNumberFormat, SetEncoding, GetLocale, LSEuroCurrencyFormat, LSParseCurrency, SetLocale, GetTimeZoneInfo, LSIsDate, LSParseEuroCurrency Hope this helps, RC -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jay Gibb Sent: Monday, February 23, 2004 8:36 PM To: [EMAIL PROTECTED] Subject: RE: [CFCDev] localization Hi Paul, The roll out will be one site for all locales, and the g11n stuff is mostly the responsibility of the higher-ups, my primary focus (and the part that's most interesting to people on this list) is the i18n part. For the purposes of this discussion, let's assume that it will be built from scratch (especially considering the cfcdev audience and the fact that I'm looking for some best-practices specifics). Also in the same vein, let's assume that we're dealing with CF locales. Structurally speaking, the application will be consistent across all locales. The l10n differences in question are... 1) cosmetic (d/m/yyyy vs m/d/yyyy for example) 2) data (additional/fewer fields for some locales, or differences in data validation (eg: ssn vs sin)) 3) languages 4) currencies You mentioned that you "build a single locale "object" covering the whole gamut of app requirements that loads specific bits that differ locale-to-locale.". The design of that object (and the way l10n differences are normalized) is really what I'm mostly interested in understanding. Thanks for your help, - j. -----Original Message----- From: Paul Hastings [mailto:[EMAIL PROTECTED] Sent: Monday, February 23, 2004 4:38 PM To: [EMAIL PROTECTED] Subject: Re: [CFCDev] localization > I have localization guidelines defined by the business leaders in question, > and I'm looking for ideas for how to organize the software model to > centralize the differences between locales. g11n=globalization i18n=internationalization l10n=localization well i do things from a g11n perspective so this may or may not be relevant to what you're trying to do... i guess it depends a great deal on how you will roll these out. one locale per "site" or one "site" for all locales (not sure if you meant that your app would be physically deployed in those regions or just marketed there)? is this an oh-so-dreary i18n retro fit of existing s/w (remembering that l10n occurs after i18n) or built from scratch? will you be using the "official" cf locales or java ones (should be one or the other)? have you normalized the l10n guidelines? do they actually structurally differ locale to locale? or if they do, is it just version/marketing based (ver 1 will offer function a to x locales, ver 2 to x+2 locales if things go well, etc.)? i haven't really seen many apps that differ "structurally" from locale to locale (i actually try to insist that these *not* differ being the good little g11n drone that i am), though details like calendars, cultural things like names (how many parts, lengths, honorific), etc. certainly differ. in any case, i normally build a single locale "object" covering the whole gamut of app requirements that loads specific bits that differ locale-to-locale. maybe one of the real CFC gurus can offer more generic advice, i find it hard to offer advice without much details. btw, this discussion should take place on the cfc list (or cf-talk if its too cf generic), most folks will benefit one way or another. there's a surprising lack of i18n experience/knowledge in the cf community. ---------------------------------------------------------- You are subscribed to cfcdev. To unsubscribe, send an email to [EMAIL PROTECTED] with the words 'unsubscribe cfcdev' in the message of the email. CFCDev is run by CFCZone (www.cfczone.org) and supported by Mindtool, Corporation (www.mindtool.com). An archive of the CFCDev list is available at www.mail-archive.com/[EMAIL PROTECTED] ---------------------------------------------------------- You are subscribed to cfcdev. To unsubscribe, send an email to [EMAIL PROTECTED] with the words 'unsubscribe cfcdev' in the message of the email. CFCDev is run by CFCZone (www.cfczone.org) and supported by Mindtool, Corporation (www.mindtool.com). An archive of the CFCDev list is available at www.mail-archive.com/[EMAIL PROTECTED]
