> On 25 Aug 2015, at 16:01, Guillermo Polito <[email protected]> wrote: > > Hi guys, > > I was having a deep look today at Locale, LanguageEnvironment and > EncodedCharset with the objective of understanding it and see how we can > organize it better. > > As I saw, in almost all cases, it happened that the locale and language > environment are only used to get the current system's encoding. Even, it is > not that the system's encoding is obtained from the system's configuration > but guessed. Also, I saw that the usage of leadingCharacter is very limited > in the image and I'd say that most of the time we would not be using it: we > will be using unicode. > > I proposed in the issue tracker a change in three steps that cleans up this: > - Cleaning Locale's API > (https://pharo.fogbugz.com/f/cases/16379/Cleanup-Locale-API) > - Fix users to make use of this new API > (https://pharo.fogbugz.com/f/cases/16380/Make-use-of-new-Locale-API) > - Remove old unused code > (https://pharo.fogbugz.com/f/cases/16381/Removed-unused-Locale-code)
Yes, that seems the way to go. > I know that with this change we lose temporarily the ability to use other > language environments (like greek or japanese), and thus, change to other > system encodings that are not UTF8/16/32. Why do you say that ? As far as I understand it, we would not lose anything at all ! Leading char is a hack that does not seem to exist in other programming languages. AFAIU, it is only needed because there are (might/used to be) a couple (a very small number) of Unicode characters shared between 3 languages (I believe Japanese, Korean, and maybe Chinese) where the interpretation of the same Unicode character depends on the language. But I am totally not sure it really is such a big deal, I could be wrong though. Still, since we do UTF-8 (and some variations, as well as many byte encodings), I am pretty sure we support almost anything out there. > However, I believe that we should not 'guess' the system converter from the > system language but to ask the system the encoding it is using. And this > should maybe be added as a primitive (as the others already existing in the > Locale class for example). > If somebody could review these issues or has some comment on something that I > should not be aware of, I'd be grateful :). > > Guille
