Linked by Thom Holwerda on Sat 23rd Aug 2008 15:37 UTC
Editorial Earlier this week, we ran a story on GoboLinux, and the distribution's effort to replace the Filesystem Hierarchy Standard with a more pleasant, human-readable, and logical design. A lot of people liked the idea of modernising/replacing the FHS, but just as many people were against doing so. Valid arguments were presented both ways, but in this article, I would like to focus on a common sentiment that came forward in that discussion: normal users shouldn't see the FHS, and advanced users are smart enough to figure out how the FHS works.
Permalink for comment 327837
To read all comments associated with this story, please click here.
wannabe geek
Member since:

Please. We don't really want to localize a system hierarchy, isn't it?

Well, I do. But I also see the implications go much further than some admit.

Do you imagine how things start to become terribly complex and fragmented if each computer can have a different name for the /settings directory, based on its locale? And what about people using more than one locale?

In short, if properly done, it would only mean that you have to set the correct locale in the instance of Konsole where you are about to copy-paste the advice you've just seen in a forum, mailing list or IRC channel. For instance, if your system is localized to Italian, but you are asking in an English forum, the pieces of code you copy from there will have English localization, so you have to open a terminal and set English localization (just) for that instance of the terminal. Languages and locales should be like skins.

Yes, that's not how it works now. Not just in system directories, but also in programming language and all kind of technology infrastructures.

I've often heard the following "reductio ad absurdum": If system directories should be localised, then why not APIs, keywords in programming languages and so on? Good point, but you know what, I'm willing to bite the bullet.

The idea that you have to learn some keywords in a foreign language if you want to program is so pervasive that most people give it for granted, but it's just a product of the monolingual environment in which most of the programming standards were established (hello, ASCII, I'm pointing at you!).

If the first programming languages had been developed in, say, Canada, their authors would have realized that the first thing a parser should do is check the locale of the program, and that every program should declare its locale (at least when distributed outside its original locale).

One crucial activity of national standards bodies should be to establish translations for such keywords. But even if no "official" translation is available, it should be straightforward for users to define their own mappings, let their systems do the translation and interoperate with everyone else about as easily. If, for some reason, a new keyword only has translations to some languages, it should be possible to still use it in a program localized to a language where this keyword is missing, for instance by prefixing its name with a locale-setting expression.

The only people giving some serious thought to the need of localization in programming, AFAIK, are those involved in semantic web technologies. Maybe that's because ontology building is sufficiently close to natural language that the unfair advantage of being a native English speaker is most evident.

As I said in other posts, I have nothing against English, I find it nice and all. What upsets me, in this case, is the attitude of carelessly hardcoding a particular language into technology, and then expecting people to learn the language if they want to use the technology, as if said hardcoding were the most sensible thing to do.

Notice that I am not of English mother tongue -I am Italian, in fact, living in Italy- so this is not "who cares about non-AngloSaxons" talk. (end rant)

It's still "who cares about non-AngloSaxons" talk, just one by a non-Anglosaxon ;)

Reply Parent Score: 2