July 29, 2003
July 26, 2003
OT: mad about map projectionsthe map geek part of my psyche keeps bubbling up. here's an interesting site concerned with map projections. it purports to try to present a "complete a collection as possible, historical published map projections"--don't know about complete but it sure a has a bunch of them. the site is certainly mad about PDFs, 99% of the links are PFD docs--the whole thing's optimized for print. i plan on papering the walls of my home office with these...
July 22, 2003
sign thiswhile i wouldn't normally like to encourage flash coders ;-) some flash folks in the middle east have put together a petition asking Macromedia to support rtl (right to left) languages in flash. it does look like they have some legitimate gripes.
July 17, 2003
more humbug: the reception to I18N CF5 fillets the pageafter we all had a good laugh trying to use machine translations, Uwe Degenhardt and i have rounded up some human beings to translate content (a whole paragraph) on cftools.sdsolutions.de. this is another case showing how idiotic machine translators can be. lets take spanish for instance. the original english was: Welcome to the I18N CF5 Tools page. You can pick up a few free I18N tools for CF5 here. If you're using CFMX, we recommend the MX-specific I18N tools in the Macromedia ColdFusion Exchange. You'll find the available tools listed below. one machine translator, which i won't name but its babelfish ;-) translated that to: La recepción al I18N CF5 filetea la página. Usted puede tomar algunas herramientas libres de I18N para CF5 aquí. Si usted está utilizando CFMX, recomendamos las herramientas MX-especi'ficas de I18N en el intercambio de Macromedia ColdFusion. Usted encontrará las herramientas disponibles enumeradas abajo. while a real live homo sapien translated that english as: Bienvenidos al sitio I18N CF5 Tool. Aquí puede hacerse de algunas herramientas gratis para CF 5. Si se sirve de CFMX, recomendamos las herramientas específicas MX I18N de Macromedia descargar la zona ColdFusion-Exchange. Las herramientas disponibles se encuentran abajo. i don't speak any spanish but even i can see these two translations are quite different, who would you bet on? in any case, a good test of these things is to round-trip the translation--ie do you get back what you put in? in this case, not quite: The reception to I18N CF5 fillets the page. You can take some free tools from I18N for CF5 here. If you are using CFMX, we recommended the MX-specific tools of I18N in the Macromedia interchange ColdFusion. You will find the tools down available enumerated. bah humbug.
w3c i18n activity siteback to our regular scheduled programming. the w3c (world wide web consortium) produces a pretty useful i18n resource site. there is a weekly (in theory anyway) question that the GEO task force answers. i urge cf i18n folks to join the w3c international mailing list to keep abreast of things (its pretty low volume).
geoLocator's grass skirt slips a bit lowereric mauviere has tweaked the geoLocatorMap a bit more. it now handles mouseovers to show country name (in english) and "hits" (in this case the number of hits into the geoLocator testbed). you can see it here: geoLocatorMap. a few more tweaks are probably in order so if you have any suggestions please send them along to me.
July 16, 2003
the hoi polloi geoLocator in a grass skirteric mauviere has added a nifty world map flash front end for geoLocator. its dead simple to use, just pass in flashvars with ISO 2 char code, neatly provided by geoLocator, for the countries you want highlighted and bob's your uncle. flash remoting was out since we're supporting CF5. you can see it in action at cftools.sdsolutions.de.
July 13, 2003
warren zevon's got sand.Life'll Kill Ya. you have to admire the sand that warren zevon has. dying from lung cancer, dr. hunter s. thompson as his personal physician (not sure a perfectly healthy person would survive his gonzo bedside manner ;-), he manages to pull out yet another album. besides being one of my favorite musicians, he's certainly admirable for his courage and grace.
July 11, 2003
the hoi polloi geoLocatoras promised, Uwe Degenhardt has generously offered a site to distribute the CF5 version of the geoLocator (and maybe a few other cf5 i18n tools). head over to cftools.sdsolutions.de and pick up your copy. since this is geared for a cf5 environment, better aggressively cflock these functions.
encoding jig, java stylei suppose i shouldn't complain so much about cf i18n folks not quite getting on board the unicode 747. even in the java world, a world created from the ground up in unicode, many people are still having problems. a quick cruise thru the java i18n forums shows even more encoding misery than i normally see in the cf forums. that got me to thinking about tatooing "JUU" (just-use-unicode) on my forehead, but my wife suggested that wouldn't go over big w/her and the kids ;-) so as not to be a totally valuless blog posting: if you ever need to declare the encoding of an external CSS style sheet, according to the CSS2 Specification, you can use the "@charset at-rule". in your unicode CSS you would have something like @charset "UTF=8"; as the very first line in the file. note that this won't work for embedded styles as these share the encoding of the webpage. browsers are supposed to interpret a web page's encoding in the following order:
- HTTP "charset" parameter in a "Content-Type" field (which mx ignores btw)
- the @charset at-rule
- mechanisms of the language of the referencing document (e.g., in HTML, the "charset" attribute of the LINK element)
July 09, 2003
dancing the encoding jigafter once again doing the "encoding jig" in the forums, i'm at a bit of a loss as to why some i18n folks will not use unicode and still insist on using codepage encodings for their text data especially for languages/locales that have more than one encoding "standard". you're asking for trouble as its often the case that these multiple encodings actually do not exactly match. you will even see this with english language (well symbols like the euro, smart quotes, etc. anyway). while legacy data might need converting and might be a semi-valid reason for not moving to unicode (and unless you're talking Gb of data, any DBA worth his paycheck shouldn't flinch at this task, so even this isn't really a valid reason for not converting), legacy cf code to my mind isn't. you still need to put some effort into getting legacy codepage based code to work with MX--an effort that really doesn't buy you anything long term, it just moves that code's dead end a bit further down the road. perhaps more importantly, it also misses the opportunity to modernize your code with the new MX functionality (CFC, webservices, etc.). things that will actually help your i18n code overall. besides all the forgoing guff, these are some valid reasons for using unicode.
- its a standard (as they say here in thailand, "unicode same same ISO 10646")
- its multilingual
- it travels well (text in any language can be easily exchanged globally)
- unicode offers monolithic text processing (and that of course saves you money in development and support costs, time to market, etc.)
- wide industry support (macromedia, ibm, microsoft, hp, sun, oracle,etc.) make it vendor neutral
- continuously evolving (its now version at 4.0)
- possible to convert from legacy code pages
- its more or less apolitical
- and lets not forget its the default encoding for MX