[fpc-devel] Russian locale information not compatible with FPC locale variables

[Daniël Mantione]

Op Tue, 29 Jul 2008, schreef "Vinzent Höfler":

> -------- Original-Nachricht --------
>> Datum: Tue, 29 Jul 2008 19:48:46 +0700
>> Von: Bee <bisma at brawijaya.ac.id>
>> An: FPC developers\' list <fpc-devel at lists.freepascal.org>
>> Betreff: Re: [fpc-devel] Russian locale information not compatible with FPC	locale variables
>>
>>> Unicode is another issue. Delphi dictates there design decisions based
>>> on Windows only. FPC targets multiple platforms, so we should target
>>> our implementations based on OUR requirements.
>>
>> +1
>>
>> Compatibility is good, no doubt about it. But if it obstacles FPC to
>> have feature(s) that most users need, FPC should put compatibility issue
>> aside and get users need on higher priority. Be the first, be the
>> leader, be a winner. If Delphi then implements it (if ever) in different
>> way, then we can start to discuss about compatibility. It's absurd
>> talking compatibility to something that even doesn't exist!
>
> Well, I second that. Especially because the "Delphi" implementation 
> seems to be so Win32-centric, that copying it would be close to useless 
> on platforms other than Windows. As far as I understand there is no such 
> thing as a "codepage number" on Unices.

Disagree. Nobody maintains codepage registries except two companies: 
Microsoft and IBM.

While I have my doubts about Windows API constants, there are only a few 
identifications that make sense:

* Microsoft code page number
* IBM code page number
* IANA mib-enum
* IANA encoding name

It doesn't matter which one you choose, you should choose one and use that 
over all platforms.

> I doubt that the FPC team would want such a specific implementation, so 
> despite all arguments, FPC would have to find its own way in either 
> case.

I can live with using numbers from the Microsoft code page registry. 
Numbers are far more comfortable to use in portable code than using 
strings, which is the common practise on Unix. So, while there is some bad 
Windows taste involved, it's not that bad from a portability point of 
view.

Daniël