On 08.09.2010 20:42, John M McIntosh wrote:
On 2010-09-08, at 3:34 AM, Philippe Marschall wrote:
- #primCountry and #primLanguage seem to answer a three element String with the last element being a zero character (I assume a C string), this is not so nice. I'm not sure whether this should be fixed in the primitive or in the Pharo code.
The primitive is answering a ISO 639-1 value (2 character) versus the ISO 639-2 value (3 character) I have to figure out how to get the ISO 639-2 data, but it seems in looking it appears you'll get the 2 character code versus the 3 character code on other platforms so I'll bet you need to deal with the case of 2 character codes. The plugin assumes a 3 character value which is why you get the trailing null char. You'll need to deal with it.
OK
- All the primitives seem to totally ignore the locale id and only work on the system locale. This makes it a whole lot less useful.
? explain ?
In the primitive I ask for "autoupdatingCurrentLocale" The current logical locale for the current user. The locale is formed from the settings for the current userâs chosen system locale overlaid with any custom settings the user has specified in System Preferences. The object always reflects the current state of the current user's locale settings.
(Locale localeID: (LocaleID isoString: 'de-CH')) primCountry I mean, really? It totally ignores the locale id and answers the locale of the user. If that's the intended behavior why not move it to the class side of Locale? That would remove a lot of potential for confusion. The current behavior might make sense for a single classroom EToys image. It's not very helpful in a multiuser application where you want to format numbers and currencies according to the users locale.
- I'm totally confused by the Current and CurrentPlatform class variables. What's the difference? Do we really need both? - I'm confused by #isoCountry vs #primCountry and #isoLangauge vs #primLanguage. Do we need both? What's the point? Is this what you meant which cleanup?
Yes that would be cleanup..
OK, but see the problem above, #isoCountry comes from the locale id, #primCountry comes from the user locale.
There is also issues withe currency symbol, the logic assumes it's one byte, but it could be a unicode value if you decide between the international symbol versus localized regional symbol. I think the plugin is flawed in that respect.
Answers 'SFr.' where quite nicely. Cheers Philippe