ICU core meeting 2003/10/22 Roll call: Deborah Goldsmith (Apple) Tex Texin (Xen Craft) Frank Tang (AOL) IBM: Daniel Chen Andy Heninger Doug Felt Markus Scherer George Rhoten Mark Davis Raghuram Viswanadha Steven Loomis Vladimir Weinstein (notes taker) Agenda: - int64 - locale keywords ++ Daniel Chen will have a list of changes/additions for 2.8. The time is short for 2.8. 64 bit type support in C++ compilers If there is no support for the type, some of the things like number formatting don't work. Compilers that we currently test on appear to have good 64 bit type support. We have requests for parsing and formatting 64 bit integers. It is much easier to do it if the type is supported by a compiler. We remap to int64_t type. If we require compilers to support it, we don't have any problems. Compilers without 64 bit support - palm pilot gcc, all recent gccs either support it or emulate it if it is not present on the platform. Compile flags around the stuff that uses 64 bit integers - it is kind of messy. Mark - we should require 64 bit support. We can detect if support is there. Tex - what is performance impact? They are not used in core functionality, only for formatting. if we want formatting of 64 bit ints we have to add it. If we require compilers to support 64 bits, the work is much less complicated if we have to emulate it on compilers that don't have it. We could make things faster by casting small 64 bits to 32 bits - if it doesn't make a lot of difference, we should not do it. It appears that the benefits of separate paths for 32 and 64 is not too big. Digit list is used for number formatting, but it is in core processing. It should be probably moved to i18n. Several requests have been made for 64 bit formatting. ICU 2.1 required 64 bits for RBNF. ++ Decision: - require 64 bit support. - Change digitlist so that it uses 64 bits so that it works. - Move digitlist to i18n from common so that common can build without int64_t. - This would be an API change. George will verify if APIs are return value or fill in. We'll need separate functions. Need an API proposal. More on keywords - de_DE_PREEURO - we keep that locale around, but we enable de@currency=DEM. Markus: 1. canonizer function that goes from a lot of stuff to new style 2. we also keep resource bundles at least with aliases. ICU4J cannot follow immediately. Locale is container for string ID, anchor for static functions and lets you get at pieces of information inside a locale. In Java we could have statics that would help access second two things. Java Locale is not flexible enough to be usable. If we just pass stuff in Locale, your resource lookup will not work properly - locale fallback will be broken. We have to do our own resource lookup thing. Keyword locale IDs - Deborah had an issue that TRADITIONAL was used for both collation and calendars. This is now disambiguated by having keywords. CurrencyFormat is locale defined. Probably it is not required to have locale/currency format. Problem might be with lookup of display names (chinese traditional, spanish traditional). Term TRADITIONAL should refer to old/obsolete settings. German Phonebook is not referred as such. Phonebook - sorting names. Have a policy document about keyword naming? Perhaps a translators guide. Part of LDML? ++ action for Mark - prepare a translators guide.