Hi Jonas, [Cc: and Reply-To set to [EMAIL PROTECTED] since I believe it belongs more on that list.]
-On [20070624 20:39], Jonas Borgström ([EMAIL PROTECTED]) wrote: >It's not exactly documentation, but by looking at all the installed >catalogs in the /usr/share/locales directory of my ubuntu desktop, a >territory name is only specified when more than one catalog is available >for a specific language. The problem is that BSD systems, for example, do not have such a shortcut. Windows does not use such locales at all. Even if one would want to get pedantic, the SUSv3 and POSIX specs show in examples how it uses a language_TERRITORY setting for common French (http://www.opengroup.org/onlinepubs/000095399/functions/setlocale.html) OpenGroup's own locale registry has the 'full locale' as well: http://www.opengroup.org/pubs/catalog/lo.htm For all I know is that when it comes to the OS shorthand of language it is a GNU extension. But this is all besides the point to a certain level. Please see below. >So as far as I can tell, the best solution would be to drop the >territory name for all languages where we only support a single >territory. This way the current babel negotiation algorithm will work >with all browsers without needing to add some "internal mapping table" >to babel. Babel will map both "sv" and "sv_SE" to sv.mo. I disagree. Babel uses the CLDR and the CLDR operates on the basis of providing a common ground {language}.dat file that specifies everything that is observed as being generic across all implementations for {language}-* locales. It then adds additional specifiers for the territory (sv_FI, sv_SE in the case of Swedish, but ja and ja_JP for Japanese). These additional specifiers specify important, but territory-specific, locale information in addition to the generic one. Depending on the file this can include names of months, currency formatting, date/time formatting, and so on. Simply using ja.dat would mean we lose out on curreny formatting for example. Simply using sv.dat would mean we lose out on certain date/time formats, date/time naming and quotation information for example. So you cannot be without a mapping table, in my opinion, simply since you have to complete the generic information with the additional information. Also from the sake of providing a default we would want to have a mapping table inside Babel, one which can be overridden by the developer, simply to have: - a default configuration of a short-hand language tag to map to the dominant (or official) full locale, ja -> ja_JP, sv -> sv_SE, nl -> nl_NL, pt -> pt_PT and so on. - a method to allow someone to override a mapping, a very clear example would be that the default for en is en_UK and that people from the US want to override it to be en_US by default when someone requests 'en'. (CLDR has 27 en_* and 20 es_* specifiers for example.) And please do also not forget that Babel goes beyond just Trac and web-related applications. So even if we might not use something specific in Trac other applications might be. I hope this better illustrates the point I was trying to make. -- Jeroen Ruigrok van der Werven <asmodai(-at-)in-nomine.org> / asmodai イェルーン ラウフロック ヴァン デル ウェルヴェン http://www.in-nomine.org/ | http://www.rangaku.org/ Knowledge is soon changed, then lost in the mist, an echo half-heard... --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Trac Development" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/trac-dev?hl=en -~----------~----~----~----~------~----~------~--~---
