[lazarus] Localization site
bukovjan at mbox.dkm.cz
Mon Sep 16 07:33:06 EDT 2002
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
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:
- 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,
- 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.
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
More information about the Lazarus