aka ''[l10n]''. In software, localization is the process of making a program able to adapt to local conventions of sorting (??), commification (I guess that's what you would call selecting the character used when marking off orders of magnitudes of numbers ... i.e., 1,000,000 versus 1.000.000 (1)), and other issues. Also, translation of all GUI texts to the local, or selected, language (see [msgcat]). ---- [DKF] - Perhaps it is easier to put it like this: Localization is the process of taking a program (typically one that has undergone the process of [internationalization]) and adapting it to the particular situation in which it is found (generally called the ''locale''.) This includes things like showing the right strings to the user, handling numbers, dates and monetary values correctly, doing the right thing when comparing two strings, etc. ---- As mentioned at Tcl'2003E, for some examples of just how easy it is to work with l10n in Tcl, see [http://mimersbrunn.sourceforge.net/icudata.html]. It shows some of the ICU data in Tcl-form. It can of course be downloaded with all the data from sourceforge, see [http://mimersbrunn.sf.net]. - [VL] ---- (1) [RS] thinks ''number formatting'' is a better understandable term for that. [escargo] thinks ''numeric presentation'' or ''numeric representation'' is a better term for that. [aa] thinks ''numeric representation'' is more appropriate as a description of the underlying bits in computer memory than of the displayed characters. The term ''presentation'' is quite nice, though. There are three issues of presentation that I can think of. 1. Marking off magnitudes. 1. Marking off fractions. 1. Expressions involving currency. ''What about dates and times? - [aa]'' Date and time settings need to be considered, but there needs to be like today the clock format to be used by the programmer, do we collect any sort of setting today from the OS in regards to date and time presentation? - [VL] 2003-aug-20: [Luciano ES], hobbyist programmer and translator by trade, thinks that "localization" is the best term because that's the term used by the entire translation and l10n industry. Unless you mean something else, of course. In practice, some l10n is almost invariably applied to some extent even in "pure" translation, because some cultural differences cannot be ignored. In the present context, you can't simply "translate" numbers. Each locale's conventions must be taken into consideration. Another example is that Tk also uses "named colors", and many of these colors' names will not be recognized in other countries if rendered into strictly literal translation. Games probably provide the best example to illustrate the issue. Many worldwide popular games, including some already represented in this wiki board in Tcl/Tk code, have names whose meanings do not correspond to the meaning of the names they carry in other cultures. For example: if you translate "Solitaire" into Brazilian Portuguese literally, everyone will think you mean another game, not the one you meant. If you translate "Monopoly" or "Clue" literally, no one will have the faintest idea of what you mean, although these games are (or used to be when I was a kid) very popular in Brazil. So numbers are just one of the many aspects of localization. If you don't like the name, then you'd better decide if this page is going to be truly about localization in general or merely about [numeric representation]. We can't change the names of the pages, so I guess you don't have much of a choice. :-) ---- [VL] 2003-aug-20: Since there seems to be a small 'project' to localize the messages in Tk's dialogs etc. shouldn't that be at least mentioned on this wiki? It seemed quite obvious at Tcl'03'europe that there was a great deal of interest in translation of the core. But noone seems to have even mentioned it since, is the problem interest, coordination or what? ---- 30 Aug, 2002 - [Luciano ES] It just crossed my mind, and I never saw anyone mention it, that Tcl must be the only language that can be translated/localized, allowing the programmer to program in their own native language. For example: instead of saying... foreach i $list { if { eof } { set a [ expr $a + 1 ] puts "the end - total is $a" } else { gets } } ... I could source one file full of [rename]s and say, in Portuguese: percorre i $lista { se { fda } { seja a [ calcule $a + 1 ] cuspa "Acabou - o total é de $a" } euc { pl } } ... or more verbose... {para cada} i $lista { se { {fim do arquivo} } { seja a [ calcule $a + 1 ] cuspa "Acabou - o total é de $a" } {em ultimo caso} { {pega linha} } } * euc = em último caso The commands could even have accents and diacritics, and Tcl wouldn't care. Weird, but totally doable! ---- [Category Porting]