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.
Thread beginning with comment 327837
To view parent comment, click here.
To read all comments associated with this story, please click here.
wannabe geek
Member since:
2006-09-27

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

Brendan Member since:
2005-11-16

Hi,

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.


If each directory has a standard name and a locale dependent nickname, then hopefully people giving advice would use the standard name instead of the locale dependent nickname.

To make it easier for beginners to learn the standard directory names a GUI would display both. For e.g. you might see "/etc (settings)" or "/etc (regolazioni)", instead of just "/etc" or "/settings" or "/regolazioni".

-Brendan

Reply Parent Score: 1

wannabe geek Member since:
2006-09-27

Hi,

If each directory has a standard name and a locale dependent nickname, then hopefully people giving advice would use the standard name instead of the locale dependent nickname.

To make it easier for beginners to learn the standard directory names a GUI would display both. For e.g. you might see "/etc (settings)" or "/etc (regolazioni)", instead of just "/etc" or "/settings" or "/regolazioni".

-Brendan


Hi, Brendan

Yes, that would probably work and would be of genuine help for beginners, but just as long as "etc" and the like are accepted as the standard. My proposal is more along the lines of not having to pick a particular keyword like "etc" or "settings" as the standard for everyone. So, "Settings" would be the standard for those using an English locale, and "regolazioni" would be the standard for those using an Italian locale. The only names that would arguably have to be the same for everyone are the names of the locales themselves, so that if I say (in a IRC channel, in my post, in my computing tips blog, whatever) that I'm using ES_es@Euro you can copy-paste that string in the "locale" slot of the terminal and then just use my code. It may look more cumbersome but it would be more general.

One possible reason why this idea sounds so odd when applied to programming language keywords may well be the deeply ingrained unique names assumption (UNA), that is, that no two names refer to the same object. So, if something is called EN/Settings but IT/Regolazioni is another equally valid name for the same thing, we are violating the UNA. Well, some languages (IIRC, OWL is an example) don't make this assumption. So what's wrong with violating the UNA? It's not fatal, since no ambiguity results of it. The problem is that code becomes less readable. If there's just one name for each thing, you can hope to memorize them.

Anyway, the UNA would still hold (if so desired) inside each locale, as long as all keywords have a translation. The only occasion where the UNA would be patently violated is when a foreign locale has to be used for a particular keyword inside a locale lacking this keyword. For instance, if you are using the IT locale to program in C, and there's no translation available to the "for" keyword (that would be "per"), you would have to insert a foreign keyword, with its locale marked, something like "EN/for" or "ES/para".

Hopefully, UNA violations inside a locale, for traditionally UNA-assuming programming languages, would be rare, as long as the importance of comprehensive keyword translation is recognized.

Reply Parent Score: 2

devurandom Member since:
2005-07-06

The fact is, everyone using English means everyone using a standard.

A standard is always better than no standard.

Natural, homeland language is all good and well (heck, I like Italian more than English) for personal talk purposes. But when a standard is required, a standard should be enforced.

Why someone wants to make a complex system to allow for non-standards, when people could just be teached the standard (and such a standard is useful for much,much more than simply reading filesystem hierarchies) again escapes my comprehension.

Reply Parent Score: 2

wannabe geek Member since:
2006-09-27

The fact is, everyone using English means everyone using a standard.

A standard is always better than no standard.



I have issues with both sentences. English is not a true standard, it's just a "de-facto" standard, much like the MS Office file formats.

Your complaint seems to be that people can't leave politics aside and pick whatever looks like a dominating option as a standard. But standards are all about politics, that's the whole point, IMO: a good standard must be perceived as common ground by all the parties conforming the standard's intended audience.

A true standard should be carefully designed with input from all the interested parties, beginning with a minimal common ground and then building upon it, trying to keep it simple, fair and balanced. Whenever possible, if parties disagree on how to do or how to express something, the standard should provide means for each party to specify their chosen option, rather than picking one of the competing solutions.

A bad standard may well be worse than no standard. At least a no-standards situation is fair, so it's a much better starting point for building good standards.

Of course you can ignore all of this, take the dominant player's caprices and call them standards. And then wonder why on earth so many people don't adhere to them.




Natural, homeland language is all good and well (heck, I like Italian more than English) for personal talk purposes. But when a standard is required, a standard should be enforced.

Why someone wants to make a complex system to allow for non-standards, when people could just be teached the standard (and such a standard is useful for much,much more than simply reading filesystem hierarchies) again escapes my comprehension.


Again, calling English "the standard" begs the question . English, the standard.. says who?. In my view, it's just the dominant player's option in a no-true-standards situation. The "complex" (not really) system I propose is an attempt at creating a standard, one that lets people agree to disagree and still communicate. Again, It only seems odd because modern computing was developed in a largely mono-lingual environment. If it had been an international (and inter-lingual) effort from the beginning, locale-agnostic provisions would seem only natural.

Regarding direct human (spoken and written) communication, learning a second language up to near-native level is *hard*. As long as the "standard" language is native for some of its speakers and not for others, the native speakers have a *huge* advantage. The only way that a particular natural language could work as a fair standard is that all the other languages were effectively eliminated, so that this "standard" were everyone's first language. Given that other strategies are available or at least conceivable (auxiliary languages like Esperanto, real-time translation), is it so surprising that many of the affected societies resist this trend?

Reply Parent Score: 2