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.

---

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.