The Linux I18N And Standard Base Merge

Leo Comitale writes "According to this press release the Linux Standard Base and the Linux Internationalization (I18N) project have merged and are calling themselves the Free Standards Group. I think it is really important for Linux to have a basic, low level standard for file system layout and support for international languages. These areas are critical to keeping Linux from splintering into a bunch of incompatible variants, and it seems these efforts are not getting as much support as they probably should be."

Comments

Portability vs. Uniformity

[Gurlia]

I'm all for a standard that allows applications to be written that can work seamlessly across Linux distributions. BUT. I hope this does not degenerate into uniformity. Let me explain.

When Oracle first decided to release version 8 for Linux, I was very interested and downloaded it. However, I found out that apparently it was only targeted for RedHat, and I, a Debian user, couldn't get it to work properly. Libraries were missing, and the installer insisted upon a particular path to JDK, which was extremely annoying. There isn't even an option for me to specify an alternate search path or anything. It was hard-coded, and so were certain libraries that had Debian equivalents but were in a different location.

What I'm trying to get at is, although a unified standard for where stuff should go in Linux is good, I fear that this may encourage developers to become lazy and simply assume a certain configuration and give no option for reconfiguration. For example, assuming that JDK must be installed in /usr/local/jdk/ or some such. I mean, I don't have a problem if they used /usr/local/jdk/ as a default, but if they don't allow you to re-configure where you want your stuff to be, that's very bad.

Now, I realize that the initial download of Oracle I had was probably a hurried hack, so it's probably not their fault (that was probably the first thing they ever released for Linux IIRC -- not surprisingly they went for the commercially better known RedHat). But it underlines a problem with a lot of application developers: hard-coding platform-specific assumptions and leaving no room for reconfiguration.

I know that it's easier (and arguably, results in more efficient products) to code for a specific platform, perhaps for the future Linux Standard. However, not allowing any room for reconfiguration is very annoying, and limits the scope of the application. An app that can be configured (with various amounts of effort) to run on, say, any UNIX system, would be more successful than one that just had to run on Linux because it was hard-coded with some directory paths or some obscure libraries that only existed on Linux.

Programs should be portable, more or less (ie. it should come with reasonable defaults that can run as-is on the specific system it was designed for, but it should not require massive recompilation or source-level hacking to get it to work on a slightly differently-configured system). A standard is meant to serve as a reasonable default, and not as an excuse for lazy, non-portable programming habits.

---

Standards.

[Matt2000]

There's alot of debate for and against standards in the Linux community and in the open source community in general.

Arguments against: Stifles innovation.
Arguments for: Prevents fragmentation.

My take is that certain administrative OS things should be standardized just to make our lives easier. I mean who really cares whether files go in /usr or /local, just pick one! Let's leave the room for innovation in things that really matter and make sure that simple things like deploying applications are as easy as possible.

Hotnutz.com - Funny

Re:Standards.

[jilles]

"Arguments against: Stifles innovation"

This is a myth, in fact it promotes innovation because after a good standardization process there is no need to reinvent the wheel poorly. Essential is that the standardization process is done properly (i.e. it should be done by people who know what they are doing and who represent all major stakeholders) based on existing practice.

"Arguments for: Prevents fragmentation."

And makes it easier to switch distribution and makes it easier and more worthwhile to learn the details of the system since they are less likely to change. It makes it easier to write distribution independent applications (or am I the only one who thinks it sucks that many applications come in 4 or even more distribution specific packages).

I think that standardization is good. Delaying it makes it unnecessarily hard to create applications for Linux. If the linux platform has to fragment then let it at least fragment for a good reason and not because vendor X stores programs in path A while vendor Y insists on using a different path.

Re:Sprechen Sie Espanol, Monsieur?

[dsplat]

Flame on, Pike. Some of us are actually doing something about it. I hardly think that people should use a different OS or a different compiler simply because they have different native languages. That doesn't make any sense. However, with free software, it doesn't make any sense to whine about not having translations into your own language. If you want them, do them yourself. I'm doing exactly that.

However, there are a few pieces of underlying support necessary:

1. The underlying software must actually read translated messages from somewhere (the GNU gettext mechanism works pretty well).
2. Character sets and fonts that support your alphabet must be supported.
3. The messages to be translated must be made available, and preferrably, the translations should be rolled back into the main distribution of the program.

As for native speakers of American English (of which I am one), even if you are monolingual, there is a decent chance that you would like to have customers in other countries with names constructed out of funny characters. Having the software you run handle their names correctly doesn't hurt. Frankly, I'm not at a disadvantage if all the menus, error messages and help files are in English. But I need to be able to enter data that contains foreign characters. Internationalization benefits more people than you realize.

Pointer to the Free Translation Project

[dsplat]

The Free Translation Project has been handling the internationalization and localization of free software (primarily, but not exclusively GNU software) for quite some time. If you are interested in help internationalizing a program, or in participating in a translation team, it is a good place to start.

Re:Sprechen Sie Espanol, Monsieur?

[Menthos]

I see a lot of people bursting arteries because we Americans actually write software in American English

No, no one is flaming (or should be flaming) people writing software in their own language. I don't know where you got that from. If you're talking about closed-source apps, I might agree that people might complain about English being the only choice. But with open source - no. The standard "do it yourself" often apply, interpreted as "translate it yourself". No need to rewrite the entire app, if the app was made cleverly. gettext will parse many c programs just fine.

No one expects you to translate your software into 11 zillion different languages. What you might do, however, is to make it easier for translators. This may be such things as not hard-coding US-ASCII everywhere. This may sound simple, but I've seen many programs not accept filenames with non-US-ASCII characters, or where such characters simply break the app.

It might also be to write the strings in your app so that they are easy understandable even out of their context. This helps translators a lot. Avoid TLAs when you can and write easy understandable sentences.

Also try to avoid assuming that all others whould like the same localization as you. Don't hard-code these settings in your application for example:

• AM/PM clock
• Legal paper format
• Weeks begin on Sunday
• Date formats and date strings
• Inches

I could go on and on, but you get the idea. These are things that can get people "burst their arteries" if hard-coded.

As for american programmers writing in english: Don't assume that most programmers writing applications in English are american. If you look at the contributor list of many free software projects (like the GNOME and KDE ones) you'll see that a lot of them are not from the US, maybe even the majority. English just happens to be the default language that applications are written in, and then translated into as many other languages as possible.

Disclaimer: I am a Translation Project translator, translating GNU software.

I can't moderate trolls so I'll just correct them

[On Lawn]

"All I truly want is a nearly universal dependancy/packaging/installation/uninstallation system. rpm comes close"

Last I knew, rpm is dependant on a database (not binary based like Windows) to figure out those things. That means it is no where near universal and depends on everything else being an rpm. You can do cross packaging with alien, but you soon learn that for it to really work rpm needs to
1) Better catalogue its own dependancies.
2) Play nicer in configuration file placement.

Some of the rest of your vitrol is kind of cute, somewhat insightful but overall meaningless since I would rather judge an ideas technical merits rather than motivations (patting themselves on the back, etc...) ascribed by some misinformed outsider.

Also a post mearly questioning "Why are they doing what they are doing?" in the middle of a sea of posts explaining exactly that makes one sound impetuous (jumping before looking.)
^~~^~^^~~^~^~^~^^~^^~^~^~~^

RedHat is NOT LINUX!!!

[autechre]

bash-2.03$ whereis netscape
netscape: /usr/lib/netscape /usr/X11R6/bin/netscape /usr/bin/X11/netscape
bash-2.03$

This is on my Debian system. I also do not like the fact that RedHat really likes to throw everything into /usr/bin. So, it is incorrect to say that "Linux" does this. Debian has defined things like this very specifically in their Debian Policy Manual for package maintainers, and certain others would do well to follow.

Debian also does not install telnetd, etc. (and enable them!) by default. If you haven't tried Debian GNU/Linux before, I would highly recommend it...I used to use RH, but I've been completely sold on Debian and now run it on all of my machines. Even if it were not for the directory issue, apt-get would have won me over.