[lazarus] Localization site

[Michal Bukovjan]

Mattias Gaertner wrote:

>On Mon, 16 Sep 2002 11:54:43 +0200
>Michal Bukovjan <bukovjan at mbox.dkm.cz> wrote:
>
>  
>
>>Mattias Gaertner wrote:
>>
>>    
>>
>>>>I've made a temporary
>>>>hack - moving initialization to a proc - in idecomp. But it would be a
>>>>good idea to load all internationalization not from constrctor, but from a
>>>>unit initialization, which must not be the last in unit lists.
>>>>   
>>>>
>>>>        
>>>>
>>>It doesn't matter for the IDE. The IDE should support language switching at runtime. Of course this needs Translate procs for every dialog.
>>> 
>>>
>>>      
>>>
>>I wouldn't recommend this. Sounds like a lot of work.
>>    
>>
>
>It is very little extra work compared to localization lazarus.
>
>
>  
>
>>IMHO, on Unix this 
>>should be handled by LC_ALL (and similar) environment variables. If 
>>someone wants always a different language just for this application, he 
>>can always start it like this:
>>
>>export LC_ALL=cs_CZ; ./lazarus
>>    
>>
>
>Hmm. Lazarus is a visual thing. IMO a good IDE should never need to restart and there should be a graphical frontend for _every_ setting. And it's easy to implement.
>
>>i.e., I recommend no explicit language switching inside IDE.
>>    
>>
>
>It's open source. If one implements it and it does not bite, it will go into the source. :)
>

Sure, nothing against. It would be the only application to support it, 
except maybe for Mozilla, which requires restart anyway.
It's not only message strings (which, going through Translate function, 
would slow the IDE down), localization has to include fonts (cyrillic, 
different character encodings), bi-di (arabic), sorting, uppercasing, 
shortcuts, number formatting, etc. (heck, even default paper size for 
printing :-)

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:

<rant mode>

- just type fpc - it lists 40 lines and wants Enter - why? I can use 
fpc|more or fpc|less, I have a bigger terminal, and it bugs me to hit 
Enter several times
- 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.
- [I may be misinformed here] - why fpcmake? Why not standard GNU 
autoconf/make stuff? It is meant to be programming language independent, 
right?
- rewriting of stuff that is in Win32 (I don't mean compatibility 
functions, rather desktop integration - stock icons, workspace, etc.) 
where GNOME or KDE was created for and fits the bill.

</rant mode>

Please don't react to the above points, they are only illustrative and I 
don't want to start a flamewar on any of these points.

The point is, we should always think about whether and how it is 
implemented in the OS(es), and follow those practices, if possible. If 
we need to change something, then ask lib/OS authors first, and only if 
they don't understand our needs, only *then* duplicate their work. 
That's the spirit of open source as I see it.

And one day, perhaps, we will not see Lazarus executable 9MB large and 
counting...

Michal