Internationalization appeal

[1/3] from: sunandadh::aol::com at: 16-May-2002 12:32

I'm about to embark on a design and code exercise that will end up with a set of functions that will enable me to properly internationalise (or -ize) an application I'm likely to be writing. First and most important: if any one has already done this, _please_ let me know....I've reinvented enough wheels in my time. I'm appealing to the List for three things: 1. Some feedback on the requirements. Please take a look at the sample functions below and tell me what is missing so it can work for your country/locale. 2. A few people off-list (no point burdening the list with a techie design discussion) to help debug my design, implementation, and documentation. Please reply to me privately if you want to see the design docs (such as they are) or generally want to put some input into this. 3. When it's ready, I'd like some people to contribute the code to provide the functions for their language/country/locale. What I am doing? I want functions that render dates, times, currency and country names appropriately for international and local audiences. The initial client is a web application for a listings service. Given the recent discussions about collating sequences, I'll aim a design that can handle those too, though it's not something I currently need. Examples: ----------dates:

>> render-date/short "uk-eng" 8-apr-2001

== 08 Apr 2001 ;; uk english short rendering

>> render-date/long "us-eng" 8-apr-2001

== April, 8 2001 ;; US english long (full month name) rendering

>> render-date "iso" 8-apr-2001

== 2001-04-08 ;; ISO standard

>> render-date/long "es-esp" 8-apr-2001

== 8 de Abril 2001 ;; spain/spanish

>> render-date/long "us-spa" 8-apr-2001

== Abril 8, 2001 ;; US/spanish (I'm guessing the acceptable format)

>> render-date "travel-int" 8-apr-2001

== 08APR01 ;; international format used by travel trade

>> render-date/long/day "uk-eng" 8-apr-2001

== Sunday, 8 April 2001 ;; long format with weekday

>> render-date/long/day "uk" 8-apr-2001

whatever...returns a default format for the UK

>> render-date/long/day "spa" 8-apr-2001

whatever....returns a default format for spanish Summary: render-date returns a display-formatted date in a format widely acceptable to people of that country/language. First parameter is usually xx-yyy where xx is the ISO 3166-1 2-alpha country code, and yyy is the ISO 639 3-alpha language code -- though variations are acceptable. ----------times:

>> render-time "cz" 13:00:00

== 13:00 ;; 24-hour clock format hh:mm

>> render-time "us" 13:00

== 1.00PM ;; 12hr clock, leading zero suppressed in hour ----------country names:

>> render-country-name "es"

== Espana ;; renders local short name format

>> render-country-name/ISO-eng "es"

== Spain ;; renders ISO-639 english short name format

>> render-country-name/ISO-fre "es"

== Espagne ;; renders ISO-639 french short name format ----------money:

>> render-money "us" $12.50

== USD12.50

>> render-money "de" -$1002.50

== EUR1.002,50- ;; German negative format -- trailing sign

>> render-money "uk" -$1002.50

== (GBP1,002.50) ;; UK negative format -- in brackets

>> render-money/symbol "us" $1

== $1.00

>> render-money/words "uk-eng" $20.50

== "Twenty Pounds and 50 pence"

>> render-money "in" $123456.78

== INR1,23,456.78 ;; Indian rupees =E2=80=93 note "nonstandard" location for separators. ----------collating functions:

>> sf: Get-collate-function "at-deu"

;; returns collate/compare function for Austria/German

>> sf: Get-collate-function "hu-hun"

;; returns collate/compare function for Hungary/Hungarian ----- Without prejudicing the design, I suspect there is a two-stage look-up.... Example: "us-spa", "us-esp", "us-sp", "840-spa", "840-esp", and "840-sp" (all ISO-639 variants for US/Spanish) will point to a rule set for render-date. That rule-set contains the actual code (maybe as a single 'compose statement) to action the rendering. There are then issues about caching functions for higher performance. I'm willing to do all the leg-work: design and write the supervising code, write the english documentation, and release it all under a BSD (flexible open-source) licence. But the more help I can get, the higher-quality the end result -- and I hope we can all benefit from that. Thanks for reading!! Sunanda

[2/3] from: g:santilli:tiscalinet:it at: 17-May-2002 14:20

Hi SunandaDH, On Thursday, May 16, 2002, 6:32:54 PM, you wrote: Sac> 1. Some feedback on the requirements. Please take a look at the sample Sac> functions below and tell me what is missing so it can work for your Sac> country/locale. Just my 2 cents: what about handling it like AmigaOS locale.library does? You first select the country and the language, and then use the functions. This way you don't need to have all the combinations loaded, but can simply store the required info in external files (i.e. %locale/italy.country and %locale/italian.language), which can easily be replaced/added without modification of the code. It looks much simpler this way to me. Regards, Gabriele. -- Gabriele Santilli <[g--santilli--tiscalinet--it]> -- REBOL Programmer Amigan -- AGI L'Aquila -- REB: http://web.tiscali.it/rebol/index.r

[3/3] from: ingo:2b1 at: 18-May-2002 21:55

Hi Gabriele, Sunanda, Gabriele Santilli wrote:

> Hi SunandaDH, > On Thursday, May 16, 2002, 6:32:54 PM, you wrote:

<<quoted lines omitted: 9>>

> without modification of the code. It looks much simpler this way > to me.

Yup, this would make it _much_ easier to add new languages, I think. Furthermore it might be an idea to add a field 'lang to the system/user object, and use this to determine the language settings. I have an experimental implementation to work with different language strings on the reb under h-o-h/core/languages . Maybe something like this should be part of the system, too. Kind regards, Ingo

Notes

Quoted lines have been omitted from some messages.
View the message alone to see the lines that have been omitted