The roads I take...
KaiRo's weBlog
| Zeige Beiträge veröffentlicht am 01.04.2007 an. Zurück zu allen aktuellen Beiträgen | ||||||||||||||||||||||||||||||||||||||||||||||||||
1. April 2007
SeaMonkey and the Kitchen Sink
Today's a special day, as you might know. Once again it's time for April Fools. In recent weeks, the suggestion that the SeaMonkey project should take part in that once again and fool people with "the kitchen sink" has come up - so I feel I should take the chance and blog about my point of view on that topic today. 
If you're a native English speaker, you probably know the idiom "everything but the kitchen sink" well enough. For all others: This seems to be derived from the habit of some people (intentionally leaving out alleged gender connections) to seemingly take the whole house with them when leaving for vacation or even only a picnic. It often looks like they pack everything into the suitcases they can find and what they are able to carry. Everything but the kitchen sink, that is. Even if a kitchen sink might be useful in some cases on vacation or at a picnic, it seems to be a too intricate task to unmount it and pack it up.
I guess we all know that habit from someone we know. As a consequence, many people have bad connotations with that phrase, giving it a meaning of "more than anyone will ever realistically need", others seem to understand it as "just all you need".
And somehow, there are people who connect this phrase with Netscape Communicator, the Mozilla suite and now SeaMonkey. This actually goes as far as thinking that "everything but the kitchen sink" is not enough and filing a "Mozilla does not have a kitchen sink" bug on Bugzilla, which led to an XHML+JavaScript kitchen sink implementation (the flow can even be turned off and on by clicking the handle area), which was proposed to be shipped as an "about:kichensink" easter egg (and is available as a Firefox extension in AMO's sandbox [not publicly at the moment]). Since we founded the SeaMonkey project, the request to including this comes up every once in a while. When the idea came up about doing an April Fools joke that "SeaMonkey is now including the kitchen sink", I immediately feared that those requests will come up once again.
Now why am I opposed to including this "about:kitchensink" easter egg in SeaMonkey, you might wonder.
Granted, this is a very good joke, actually. It's even a nice example of simple, ASCII-art-based "DHTML" - despite its high demand of CPU power. It would probably show out humor and geekiness. But then, we already show that with long-lived easter eggs we inherited from our ancestors - as every decent browser with a Mozilla heritage, we feature the current "Book of Mozilla" verse in "about:mozilla" (yes, the 7:15 one about the "reborn beast"), and we even just recently fixed the fishcam easter egg to point to a somewhat working URL (no live images working there though, those can only be found in an AOL blog). So, what I'm saying is: Don't waste time on new easter eggs, rather help on interesting new features, beautification, fixing nasty issues, or enabling the future.
But it adding nothing of real worth to our software isn't even the real reason against this easter egg. My real reason is more that about:kitchensink would prove humor, geekiness, and that "everything but the kitchen sink" is our motto/guideline. So, while humor is good, it's not the argument to use our software over other alternatives. And geekiness, like humor, is nothing we lack as is, but it's a reason for potential users to be scared away - esp. those in business environments. They want a professional tool for internet access and communication, not a geeky joke. And then, I don't even think that SeaMonkey is or should offer "everything but the kitchen sink". For one thing, I don't want the connotation "more than anyone will ever realistically need", a.k.a. "a pile of useless junk on top of some nice, useful stuff". And then, I don't even think our software is "just all you need". Every user of SeaMonkey uses a pile of other software next to it, probably including a file manager, an image viewer, office programs, instant messaging apps, perhaps peer-to-peer, FTP, remote shell/desktop software, and whatever else. I think it would be neither useful nor reasonable for SeaMonkey to include all that functionality. Sure, our product is a suite. An Internet suite, to be exact. It includes and integrates the main apps advanced users, web developers, and maybe business users need in their Internet life, and it should not try to be even more than that. This mission is already enough, we actually have enough room for improvement even in that area: We currently lack calendaring, we lack good FTP support (or SFTP, for that matter), we lack RSS/Atom feed support, to name some areas. And we even need to improve in what we already include: We should finally start to not suck as a newsreader, we should get decent extension management, and even better rendering and default icons.
Lots of work is out there to be done, our suitcases are probably a bit bigger than other projects', we need to repack a bit and pack some not yet included items, but we don't nearly have the space for the metaphorical kitchen sink.
(And no, it won't even have a place in our to-be-selected new slogan(s).)
If you're a native English speaker, you probably know the idiom "everything but the kitchen sink" well enough. For all others: This seems to be derived from the habit of some people (intentionally leaving out alleged gender connections) to seemingly take the whole house with them when leaving for vacation or even only a picnic. It often looks like they pack everything into the suitcases they can find and what they are able to carry. Everything but the kitchen sink, that is. Even if a kitchen sink might be useful in some cases on vacation or at a picnic, it seems to be a too intricate task to unmount it and pack it up.
I guess we all know that habit from someone we know. As a consequence, many people have bad connotations with that phrase, giving it a meaning of "more than anyone will ever realistically need", others seem to understand it as "just all you need".
And somehow, there are people who connect this phrase with Netscape Communicator, the Mozilla suite and now SeaMonkey. This actually goes as far as thinking that "everything but the kitchen sink" is not enough and filing a "Mozilla does not have a kitchen sink" bug on Bugzilla, which led to an XHML+JavaScript kitchen sink implementation (the flow can even be turned off and on by clicking the handle area), which was proposed to be shipped as an "about:kichensink" easter egg (and is available as a Firefox extension in AMO's sandbox [not publicly at the moment]). Since we founded the SeaMonkey project, the request to including this comes up every once in a while. When the idea came up about doing an April Fools joke that "SeaMonkey is now including the kitchen sink", I immediately feared that those requests will come up once again.
Now why am I opposed to including this "about:kitchensink" easter egg in SeaMonkey, you might wonder.
Granted, this is a very good joke, actually. It's even a nice example of simple, ASCII-art-based "DHTML" - despite its high demand of CPU power. It would probably show out humor and geekiness. But then, we already show that with long-lived easter eggs we inherited from our ancestors - as every decent browser with a Mozilla heritage, we feature the current "Book of Mozilla" verse in "about:mozilla" (yes, the 7:15 one about the "reborn beast"), and we even just recently fixed the fishcam easter egg to point to a somewhat working URL (no live images working there though, those can only be found in an AOL blog). So, what I'm saying is: Don't waste time on new easter eggs, rather help on interesting new features, beautification, fixing nasty issues, or enabling the future.
But it adding nothing of real worth to our software isn't even the real reason against this easter egg. My real reason is more that about:kitchensink would prove humor, geekiness, and that "everything but the kitchen sink" is our motto/guideline. So, while humor is good, it's not the argument to use our software over other alternatives. And geekiness, like humor, is nothing we lack as is, but it's a reason for potential users to be scared away - esp. those in business environments. They want a professional tool for internet access and communication, not a geeky joke. And then, I don't even think that SeaMonkey is or should offer "everything but the kitchen sink". For one thing, I don't want the connotation "more than anyone will ever realistically need", a.k.a. "a pile of useless junk on top of some nice, useful stuff". And then, I don't even think our software is "just all you need". Every user of SeaMonkey uses a pile of other software next to it, probably including a file manager, an image viewer, office programs, instant messaging apps, perhaps peer-to-peer, FTP, remote shell/desktop software, and whatever else. I think it would be neither useful nor reasonable for SeaMonkey to include all that functionality. Sure, our product is a suite. An Internet suite, to be exact. It includes and integrates the main apps advanced users, web developers, and maybe business users need in their Internet life, and it should not try to be even more than that. This mission is already enough, we actually have enough room for improvement even in that area: We currently lack calendaring, we lack good FTP support (or SFTP, for that matter), we lack RSS/Atom feed support, to name some areas. And we even need to improve in what we already include: We should finally start to not suck as a newsreader, we should get decent extension management, and even better rendering and default icons.
Lots of work is out there to be done, our suitcases are probably a bit bigger than other projects', we need to repack a bit and pack some not yet included items, but we don't nearly have the space for the metaphorical kitchen sink.
(And no, it won't even have a place in our to-be-selected new slogan(s).)
Von KaiRo, um 09:00 | Tags: April, easter egg, Mozilla, SeaMonkey | keine Kommentare | TrackBack: 0
Why I'm eager for L20n
Mozilla 2 is to be started soon, and as you might have read, there are thoughts of creating a new localization infrastructure for that future generation of Mozilla software. Currently this is named L20n, driven by MoCo's L10n lead Axel Hecht, and though it's in a draft stage, I can't await to use this technology.
When Axel talked about L20n at FOSDEM, I was hoping people would tell us how they love it - unfortunately time for the talk was over before he could get to the interesting part - examples. Discussions there in Brussels were pretty interesting though, as I can't remember objections to the need of this or the general approach, only some criticism of the lol file format semantics. Oh, yes, it looks like localizing will be much fun in the future, having L10n info in ".lol" (Localizable Object List) files
I actually think that the proposed syntax of those file is good, as it feel familiar to most developers but is different enough from other languages to realize you're not in JS, XML but in a lol file.
The good thing is that L20n is a format that is growing out of knowledge about problems in current L10n approaches, both of the Mozilla approach(es) and the gettext/PO approach. People who have worked with both on a developer and localizer side know they all have their problems. While Mozilla lacks language fallbacks and plural handling, gettext/PO lacks good VCS compatibility and needs long original strings in the source code, while both lack flexible support for declension and other grammatical specialities. L20n is an effort to learn from the strengths and weaknesses of those, and esp. from the problem of their users, to create an L10n toolkit that satisfies developers, localizers and users the same - also across programming language boundaries. Axel has contacted other L10n communities than the Mozilla one to get feedback and, from what I heard, has received positive feedback and wishes for collaboration.
As an active SeaMonkey localizer, I heard about this new approach soon, bing in the Mozilla L10n newsgroup, I was more or less there when it was born (or the ideas for it were gathered) and actively took part in those discussions.
I'm more eager to working with L20n from a developer's perspective than from a localizer's perspective though: While "my" language (German) doesn't differ from English that much that I regularly run into the big problem of current approaches, L20n could simplify the code I write as a developer a lot:
Let's take this "simple" snippet of PHP code and German .po file to print out a number of comments (simplified source of this blog):
Now let's look at how it might look (in principle, I could be using wrong function names here) with L20n:
Note that I'm not sure that $postCount would be passed as an array like this, but it would probably be similar to that - and I hope I got the "plural0" macro right.
There are multiple good things about that approach: First, the actual code is much shorter and easier to read (even more so if I don't have short strings but long sentences there). Second, there is no "original string" in the source, just an ID ("comm_cnt"), it actually doesn't matter which language I'm doing first, while writing the code, as L20n doesn't care. Third, while writing the code, I could just define the string as
(And yes, I know, gettext probably knows plurals in some way, so those might be a bad example. It's one if the easiest to grasp for a developer who doesn't speak Finnish, Polish or other grammatically more complicated languages though.)
It would be so nice to simplify code and get all those long strings out of the source (which often require horizontal scrolling here) - and that's only speaking as a PHP dev doing two languages that don't need declensions or other specialties. It must be even more compelling for a localizer of some language like that who can finally give his users a linguistically correct user experience.
When Axel talked about L20n at FOSDEM, I was hoping people would tell us how they love it - unfortunately time for the talk was over before he could get to the interesting part - examples. Discussions there in Brussels were pretty interesting though, as I can't remember objections to the need of this or the general approach, only some criticism of the lol file format semantics. Oh, yes, it looks like localizing will be much fun in the future, having L10n info in ".lol" (Localizable Object List) files
I actually think that the proposed syntax of those file is good, as it feel familiar to most developers but is different enough from other languages to realize you're not in JS, XML but in a lol file.
The good thing is that L20n is a format that is growing out of knowledge about problems in current L10n approaches, both of the Mozilla approach(es) and the gettext/PO approach. People who have worked with both on a developer and localizer side know they all have their problems. While Mozilla lacks language fallbacks and plural handling, gettext/PO lacks good VCS compatibility and needs long original strings in the source code, while both lack flexible support for declension and other grammatical specialities. L20n is an effort to learn from the strengths and weaknesses of those, and esp. from the problem of their users, to create an L10n toolkit that satisfies developers, localizers and users the same - also across programming language boundaries. Axel has contacted other L10n communities than the Mozilla one to get feedback and, from what I heard, has received positive feedback and wishes for collaboration.
As an active SeaMonkey localizer, I heard about this new approach soon, bing in the Mozilla L10n newsgroup, I was more or less there when it was born (or the ideas for it were gathered) and actively took part in those discussions.
I'm more eager to working with L20n from a developer's perspective than from a localizer's perspective though: While "my" language (German) doesn't differ from English that much that I regularly run into the big problem of current approaches, L20n could simplify the code I write as a developer a lot:
Let's take this "simple" snippet of PHP code and German .po file to print out a number of comments (simplified source of this blog):
blog.php:
if ($postCount < 1) { print(gettext('no comments')); }
elseif ($postCount == 1) { print(sprintf(gettext('%s comment'), $postCount)); }
else { print(sprintf(gettext('%s comments'), $postCount)); }
blog.po:
msgid "no comments"
msgstr "keine Kommentare"
#, php-format
msgid "%s comment"
msgstr "%s Kommentar"
#, php-format
msgid "%s comments"
msgstr "%s Kommentare"
Now let's look at how it might look (in principle, I could be using wrong function names here) with L20n:
blog.php:
print($l20n_context->getValue('comm_cnt', array('num'=>$postCount)));
blog.lol:
<plural0: (n) -> {n == 0 ? 0 : (n == 1 ? 1 : 2 ) }>
<comm_cnt[plural0(num)]: ["keine Kommentare", "${num}i Kommentar", "${num}i Kommentare"]>
Note that I'm not sure that $postCount would be passed as an array like this, but it would probably be similar to that - and I hope I got the "plural0" macro right.
There are multiple good things about that approach: First, the actual code is much shorter and easier to read (even more so if I don't have short strings but long sentences there). Second, there is no "original string" in the source, just an ID ("comm_cnt"), it actually doesn't matter which language I'm doing first, while writing the code, as L20n doesn't care. Third, while writing the code, I could just define the string as
<comm_cnt[num]: "${n}i Kommentare"> to make things simple, and I could refine it to better values later (when the code is stable). Fourth, if some localizer comes along and tells me he need 5 different plural forms depending on the numbers, he can just do that in the lol file, I as a developer don't need to know or care. Fifth, the localization file is shorter. Sixth, I as a developer am actually writing a first localization along with the code, which a localizer can use as an example for his work. And there are probably more.(And yes, I know, gettext probably knows plurals in some way, so those might be a bad example. It's one if the easiest to grasp for a developer who doesn't speak Finnish, Polish or other grammatically more complicated languages though.)
It would be so nice to simplify code and get all those long strings out of the source (which often require horizontal scrolling here) - and that's only speaking as a PHP dev doing two languages that don't need declensions or other specialties. It must be even more compelling for a localizer of some language like that who can finally give his users a linguistically correct user experience.
Von KaiRo, um 00:58 | Tags: L10n, L20n, Mozilla | 6 Kommentare | TrackBack: 0
