> 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.
g11n=i18n + l10n. what exactly are they doing for g11n? i18n is removing locale specific obstacles, ie making sure the app works in *any* locale. l10n is basically skinning an i18n app for a specific locale. making an existing app i18n is a huge pain. you'll need a way to transparently determine user locale (plus a manual way to swap). i use geoLocator CFC for that (http://www.sustainablegis.com/projects/geoLocator/) once you have locale pinned down, the rest of the app flows from that. > looking for some best-practices specifics). Also in the same vein, let's > assume that we're dealing with CF locales. well i would suggest you not use cf locales, if nothing else it widens your app's market to some of the more "fast growing" internet regions. and it helps pressure mm into using java locales for the next release....or so we can organize a good-sized mob to chase after damon cooper with pitchforks & burning torches ;-) > 1) cosmetic (d/m/yyyy vs m/d/yyyy for example) no, don't assume that's a cosmetic difference. one locale's "month" may not equal another's "month". this will bite your ankles off when it comes to date calculations. you should thoroughly research the calendars you will (eventually) need. don't just use gregorian, even if its what the current locales require, retro-fitting this will be nasty. > 2) data (additional/fewer fields for some locales, or differences in data > validation (eg: ssn vs sin)) i tend to produce generic table designs, one size fits all. depending on the locale, you either ignore or populate locale specfic columns. you could denormalize this i guess & futz around with locale specific table designs but that gets smelly pretty quickly. i use dan switzer's qforms for most validation (plus his nifty gateway API for slurping up clientside info), adding locale to specific validation functions as required. > 3) languages if you mean locale specific text, the answer is simple: resource bundles (rb) & unicode. your text/cf pages should be encoded in unicode (utf-8 best bet cf page in/out, the db should handle ucs-2 same as java/cf, most big iron databases do so its not that big a deal). accept no substitutes. you should completely seperate text, text presentation (via CSS) & code. rb are key value pairs, with the value being the translated text in escaped ANSI format (such as bengaliFive=\u09EB). this where language metrics research pays off btw. > 4) currencies do you mean symbols & fraction digits (for real money vs digital)? or currency exchange rates? i18n formatting functions should handle quite a bit of this. > The design of that object (and the way l10n differences are normalized) is > really what I'm mostly interested in understanding. well, for starters read my blog: http://cfg11n.blogspot.com/ & look for cf examples here: http://www.sustainablegis.com/things.cfm you might find the i18n functions cfc useful (though a bit outdated now, i've moved most of the date stuff to icu4j calendars). ---------------------------------------------------------- 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]
