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 327839
To view parent comment, click here.
To read all comments associated with this story, please click here.
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