993 words on Mac OS X
Arrgh. Now I’ve been running this site for a number of years and I still can’t predict which posts will be read by many people. Of course the number of people reading a post hasn’t got that much to do with its content – at least in the short term – but mainly with it being linked to by popular sites. That can easily double the number of readers for a day or two and bring many people along who are interested in the particular topic. Those people won’t be used to the general tone of the site, but that’s just how it is, I’d lock the site down if I couldn’t take them.
Yesterday’s post attracted many readers and many comments. Which hit me as a surprise, as I suspected that most people simply won’t care enough to even think about the issue. A number of the comments that people left pointed out further interesting points on Apple’s localisation of file names while others indicated that I could have been clearer in writing the post. It’s too late for that now and the comments hopefully bring enough clarity for those who are interested enough.
The problem here was that yesterday’s post was a bit of an afterthought on today’s post and as such it wasn’t written with the greatest care. Or rather it started as something I wanted to use as an introduction for this post but which became a bit too widely scoped while being written. So I decided to put it in a separate post to appear at least vaguely coherent and not purely rambling. Anyway…
As discussed yesterday, localised application names are far from trivial. At least with the way the Mac (and probably any other computer) uses files and file names today, localised application names mean that there is a disconnect between the ‘actual’ name for a file and the name displayed for it. The OS may be able to cover that up in many places but it certainly doesn’t make things more consistent. The OS also has to become more complex as it needs to keep an eye on the general distinction between a file’s ‘actual’ and its displayed name. The same is true for all applications dealing with files.
In addition, this can make discussing computer topics in multi-lingual environments (think internet) more difficult, particularly if localisations of file names differ widely between languages. So my bottom line would be: Localised application names are a great idea – probably essential if you truly want to address a global audience. But you need to do them properly. On the communications level that’d mean, you will localise the names of all applications. And of course – just like any car company who want to peddle their new model globally – you will have to think about the applications’ name and all its localisations before publishing it. If some name turns out to be bad for localising, you will pick another one. That should be a fairly non-trivial task. On the technical level, well, I guess we are just screwed with the way file systems on computers work these days. There won’t be a good solution for a viewing files which can have different names depending on who’s looking at them.
In the Classic Mac OS days things were easier as an application file was usually monolingual. So at least the technical problems didn’t exist. The file could just have (rather then only display) the localised name. In addition the OS wasn’t as braindead as the Unixy innards of OS X and could handle localised names of its own folders without problems. But those days are over and we probably all agree that the OS and applications being multi-lingual is a good thing. The multi-linguality is powerful but it isn’t perfect.
Taking a step back you will also see that things are even more complicated once you take into account that an application also includes things like manuals, help and and a web site. Doing these in many languages is a tremendous amount of work. And having a different name for an application in each language just adds to that. It also raises numerous questions such as what will be the canonical URL for the application’s web page. In fact, I wonder whether there exists a non-trivial application which localised names which gets this 100% right – down to the last web page and screenshot.
And thus our ‘theory’ here at earthlingsoft has been to simply throw a few German names into the game. It’s natural for us and unlike the poor sods at Apple we don’t have to do this for a living, so we will survive if some lazy American doesn’t manage to figure out that GeburtstagsChecker has something to do with birthdays because he couldn’t be asked to read more than the name. Throwing a few more languages into the mix like this also reflects that software development is international by now. [Homework, to take this to the funny parts: discuss whether or not FileMaker should have rather named their new ‘database’ 弁当.]
And thus I’m always delighted to see more and more German application names in application listings. That suggests that there must be some Mac developers around here who are joining in with the GeburtstagsChecker crowd. A list of German application names I recently spotted (without trying the applications) follows:
Plus of course our own GeburtstagsChecker, Rechnungs Checker and Ballerburg! Admittedly most applications in the list above are from the same company, and many don’t look particularly exciting. But it’s a start, I guess.
Admittedly some applications also drop out: GraphicConverter, for example, used to have the German name Grafikkonverter but that was changed when it became big.
In addition the OS wasn’t as braindead as the Unixy innards of OS X and could handle localised names of its own folders without problems.
Um, what? How was the Classic Mac OS any better in this respect, especially given the fact that they ran on the exact same underlying file system? There is a difference between the “display name” and the “actual filename” as you say, and I don’t see how the Classic Mac OS overcame that problem any better than Mac OS X does. As you note, it was just a matter of the Classic Mac OS being specialized for one specific language for each install, not having multiple languages on one install.
The Classic Mac OS didn’t have this problem because it didn’t attempt to address it at all. It’s ludicrous to call UNIX “braindead” because of that.
Sauerbraten? That’s a stupid name for a game engine.
Classic Mac OS was much better at that because it discouraged programmers from using explicit paths. This abstraction was much reduced in OS X where both the system and applications depend on explicit paths.
Why else can’t I rename the system folder? Why else are the ‘hidden’ Unixy folders at the top level of my drive (rather than stuffed away inside the System folder)? Why else does Help in Cocoa applications break if you move the application after launching it? And so on…
With things in the OS and inside applications frequently being addressed in terms of their explicit paths rather than their function, it seems pretty much impossible to move things off a path-based hierarchical file system as we have it today. As I said, that’s not a problem today as all common file systems fit that path based idea just fine (and I’m not even sure the whole Unixy file system idea could handle anything else), but if you want think about a file system as a database (as the internet likes to do every other year), you’d need a more abstract point of view to do that properly.
Received data seems to be invalid. The wanted file does probably not exist or the guys at last.fm changed something.