[lazarus] Localization site

[Michal Bukovjan]

Florian Klaempfl wrote:

> At 13:36 16.09.2002 +0200, you wrote:
>
>> MHO:
>>
>> The nice thing about Unix, is its modularity. This is what I love 
>> about Unix, and hate about Windows (lack of). As I see it, Free 
>> Pascal and potentially Lazarus tend to do a lot of things on its own, 
>> still essentially the same way as others. Sometimes it is needed for 
>> crossplatformness, sometimes just because someone feels like it. This 
>> is not a rant, I myself am curious to see where it leads - maybe it 
>> will show up as a more powerful direction. As I see it, though, there 
>> is a lot of duplication and incosistencies with the rest of the 
>> operating system and its applications (read Linux here) as a result.
>>
>> It's a number of these little things, for example:
>
>
> Common for a all points: your arguments may be true for Linux but FPC 
> runs on a lot of other platforms...
>
Wouldn't Cygwin help here?
I belive gcc is for Windows as well, so it should be possible...

>> I can use fpc|more or fpc|less, I have a bigger terminal, and it bugs 
>> me to hit Enter several times
>
>
> Do a fpc -h|more and you'll be fine.
>
> I think the fpc solution is much more user friendly than the default 
> behavior of unix tools, i.e.
> an integrated "more". Though the terminal line determination may be 
> buggy. 

It does not work at the moment, both line and column determination.
IMHO, it should be rooted away, or perhaps make this behaviour after a 
switch (like fpc -h). It is the only app that does this, and it confuses 
me as user...
And sure, "less" or "more" is much more powerful for this than you will 
ever want to code into FPC. "more" is available even for DOS - and 
people running FPC from commandline are most likely to know what "more" 
and pipe is :-)

>
>
>> - sorting, uppercasing, lowercasing procs do not take into account 
>> locale. Sure, it is a lot of work, but it's already in glibc (that's 
>> why it may take about 20MB installed in the system), which all (not 
>> just C) program rely on. FPC does not relay to glibc and rather 
>> duplicates the work, so we end up with unusable sorting for anyone 
>> else except Englishmen.
>
>
> A glibc based solution might be unusable for non unix systems thus we 
> want a generic solution. The linux/unix
> solution might use glibc based code. OTOH we decided a long time ago 
> that the core rtl won't use glibc. 

But this sort of thing (i18n) is a lot of drudgery, noone seems to want 
to do that and maintain that ...
I believe you should use glibc for POSIX systems, and specific Win32 
bindings for Windows, just like Lazarus does for Win32/GTK/Qt

IIRC, glibc is present in MacOS X, too. For Win32, I would think glibc 
from Cygwin project could be linked as well...

Michal