28 messages in net.sourceforge.lists.courier-sqwebmail[sqwebmail] Re: Spelling and other te...
FromSent OnAttachments
oth...@freeshell.orgDec 21, 2004 1:57 pm 
Brian CandlerDec 28, 2004 3:11 am 
Sam VarshavchikDec 28, 2004 4:16 am 
Paul L. AllenDec 28, 2004 11:32 am 
oth...@freeshell.orgDec 28, 2004 7:45 pm 
oth...@freeshell.orgDec 28, 2004 8:45 pm 
oth...@freeshell.orgDec 28, 2004 9:02 pm 
Paul L. AllenDec 29, 2004 3:28 am 
oth...@freeshell.orgDec 29, 2004 11:39 am 
Paul L. AllenDec 29, 2004 1:18 pm 
oth...@freeshell.orgDec 29, 2004 2:34 pm 
Paul L. AllenDec 29, 2004 4:50 pm 
oth...@freeshell.orgDec 29, 2004 9:08 pm 
Brian CandlerDec 30, 2004 1:10 am 
Brian CandlerDec 30, 2004 2:29 am 
Paul L. AllenDec 30, 2004 9:56 am 
Paul L. AllenDec 30, 2004 12:15 pm 
oth...@freeshell.orgDec 30, 2004 2:39 pm 
oth...@freeshell.orgDec 30, 2004 3:14 pm 
Paul L. AllenDec 30, 2004 4:07 pm 
Brian CandlerDec 31, 2004 2:40 am 
Laurent WacrenierDec 31, 2004 3:00 am 
Paul L. AllenDec 31, 2004 3:41 am 
Brian CandlerDec 31, 2004 4:11 am 
Pawel TeczaDec 31, 2004 4:47 am 
Laurent WacrenierDec 31, 2004 5:22 am 
Brian CandlerJan 1, 2005 4:45 am 
Brian CandlerJan 1, 2005 5:17 am 
Actions with this message:
Paste this link in email or IM:
Paste this link in email or IM:
Atom feed for this thread
Paste this URL into your reader:
Subject:[sqwebmail] Re: Spelling and other templates (Was: stale processes and m17n)Actions...
From:Paul L. Allen (pl@softflare.com)
Date:Dec 29, 2004 4:50:10 pm
List:net.sourceforge.lists.courier-sqwebmail

oth@freeshell.org writes:

On Wed, Dec 29, 2004 at 09:18:47PM +0000, Paul L. Allen wrote:

[Figuring out which spelling checker is in use and which dictionaries are available]

Shouldn't take that long =)

Really? On Red Hat 7.3, for instance, there is no man page or info node for aspell or ispell. In fact, unless somebody told you about them you might not even know they were there.

Is there any more docu needed than what's already been written? It seems simple enough to me anyway. Figuring this out for SqWebMail is no different than any other mail client.

For the mail clients that come with Red Hat you don't have to figure out which package is there because it's configured in. These aren't the old days of building a kernel from scratch, these are the days when the installation is so automated that even people who can install Windows by themselves can install it and then use it. It's not quite as easy as a Windows install yet but it will have to become so for Linux to have a chance of dominating the home desktop market - and that has to happen soon to prevent Windows "embracing and extending" Linux out of any market (which is happening - we installed dedicated qmail/sqwebmail servers for various companies a couple of years ago and now they're insisting on switching to Exchange for all the OWA and synchronized calendars and stuff that there is no open source alternative for that works without installing custom connectors on Outlook).

You figure out what flag feeds the speller and the location of the dictionary or language code.

Which with aspell is non-trivial. I couldn't see any mention of those things in my scan through the documentation on aspell. I'm smart enough to use find (or an RPM query if find doesn't get me anywhere) but there are admins out there who aren't.

It's pretty straightforward. Hell, if an admin can't do that, that admin probably couldn't get the server started in the first place.

I have some surprises for you, based upon my experience in other lists...

1) A lot of IT work is now off-shored to places like India, but you probably knew that.

2) Despite the claims of these off-shore workers being professionals, there are some dodgy companies out there who take on people with little or no experience of Linux and then have them doing work on Linux boxes installing packages like the Nagios network monitor.

3) These people don't have a clue about Nagios, or how to configure apache to serve up the nagios web pages (or how to configure apache to do anything), or the underlying protocols of the network services they're monitoring, or how to write shell or perl, or how to do much at all.

4) Having found Nagios and managed to install it, their BIG crime is that they do not read (or cannot understand) the documentation. So they ask on the mailing list. The same moronic questions time after time. And all of those questions equate to "I don't know how to do this and don't know (or don't want) to read the documentation, and I don't know to search google for an answer, and I'm being paid to do the work you used to do before your job got off-shored, so please tell me the answer to my moronic question in sufficient detail that somebody who knows nothing about Linux or apache and should never have been let loose with the root password can understand it."

I'm not saying all off-shore workers are like that. The good ones won't ask stupid questions on the list because they don't need to. But there are enough bad ones to be very annoying. I agree that these people shouldn't be let loose on *nix but they are, so it's a matter of programming defensively - then they won't have to ask because if they can get past the ./configure, make... hurdle it's all been done for them.

I see the scripting method being possible, but altogether messy and will take much longer to test and implement before becoming "stable" rather than putting an extra paragraph in the docu and making people read it if they want m17n.

Your documentation has to cover:

1) How to figure out which spelling package(s) you have.

2) Where the dictionaries are located under various flavours of *nix and distros of Linux. This can vary quite a lot. :(

3) Some hint as to typical naming schemes for dictionary files, possibly including a list of known names for spelling checkers that give them weird names that are unrelated to ISO code yet accept the ISO code when selecting a dictionary.

Once you have that level of detail it's pretty simple to turn it into a couple of tables of data you feed into a script. Oh look you have aspell. And you're on RH 7.3, so the dictionaries are here. And in this release of RH and aspell they are named like this, so you have dictionaries for American English and Brasilian Portuguese, so I'll add en-US and pt-BR to usr/local/share/sqwebmail/whatever_we_call_it and tell the sqwebmail config.h that you have aspell.

You're skeptical? Once upon a time I pointed out to Sam that the timezoneinfo shipped with Sqwebmail covered only 6 of the 19 US timezones and nothing else. His answer was that you have to add the timezones you want manually because it was impossible to generate them automatically. But the whole point of webmail is that you can use it when away from your own computer - like when you're on holiday in the Philippines or at your company's subsidiary in South Africa or when you're at your company's subsidiary in Russia, or when your company is located in Kazakhstan. I didn't pick those examples at random, they're just some of the cases applying to some of our customers that I happen to know of, so we need a full timezone list. There is now a script included in the contrib section of sqwebmail that will generate a full list of timezones that your machine knows about. You might want to edit the output for cosmetic reasons, but it's a hell of a lot better than doing it by hand. One day I will remember to send Sam the improved version of that script, which does a couple of things a little better and drops the result directly in place.

One human at each of thousands of ISPs. It's a lot of duplicated effort. With many of them not knowing enough to figure out how to do it and end up asking here for idiot-level instructions. So eventually it will get scripted just to stop the bandwidth being wasted by people who can't figure out where their spelling checker keeps its dictionaries, because once you have idiot-level instructions you can script it.

For a functionality that doesn't currently exist?

Once you add it, people will want it. In fact people already want it, which is why we're discussing it.

If the file doesn't exist, SqWebMail defaults to English

Sqwebmail's web pages default to English. Aspell defaults to your machine's LANG setting, or your own LANG setting if you've overriden the global one. If you're lucky, your distro installed the relevant dictionary, or possibly even every language dictionary that was included in the distro.

The only effort needed is when admins want to add spelling m17n...and at that point they'd probably bust out the manual anyway.

So lots of people busting out the manual for their spelling checker (except aspell's manual doesn't mention where the dictionaries are installed or how they're named) versus one person writing clear instructions, versus an automated script as part of the build process.

And even if you want all those admins to suffer, just think of those off-shore workers who don't even know about find and who will post here asking for clear instrustions...

If you run into an admin who can't discern which speller is installed, which dictionaries are installed and their respective language codes or files, and how to put this info into a text file - after installing and configuring this package, having the blurb in the docu and access to the list archives - please let me know. I'd be more than happy to give a basic tutorial of the filesystem and pkg mgmt system for the sake of m17n.

You are going to have to give detailed instructions or you're going to face a barrage of morons who don't even tell you which OS they're using when they ask how to get the spelling checker working. And then post the same question an hour later because nobody has yet answered them. And then once they've told you their OS can't understand your answer because they don't know enough about *nix. And then... You may think I'm exaggerating but I'm not - I've SEEN this happen. :(

OK, chances are it won't be as bad here as on the nagios list. These people probably want to monitor a network of Windows servers and they found nagios as a way of doing it for free so they installed a linux box to run nagios but nobody there really understands linux. There's a good chance that most of them will put in Exchange servers. But the same sort of person that can hunt down nagios as a cheap alternative to an expensive Windows product can find a *nix mail server + sqwebmail as a cheap alternative to Exchange. "We can install an Exchange server for your company with 10,000 users and the hardware/software cost is expensive and the per-seat licensing is ridiculously expensive; or we can install linux/qmail/sqwebmail for a slightly higher base price (because we have to learn how to do it by pestering the sqwebmail list with moronic questions) but then there is no per-seat cost."

It's only a matter of time before they show up here, unless Bill succeeds in locking out every other OS as a viable server. Defensive programming has to be the answer - make it monkey-proof so that even an MSCE can install it. Anyway, it's the right thing to do for other reasons - if we make this painless then some other admin has a bit more free time so he can work on making something else we want to install painless. For both reasons that extra effort will pay off.

If I understand it correctly, to use it in sqwebmail would STILL require template substitution.

Yes, it does seem that way in the Sympa templates.

I didn't look at them but from what little I know of gettext I couldn't see any other way it could work.

In essence you have to do everything that the qmailadmin system does and THEN call gettext on top.

Based on your analysis, it seems that qmailadmin's method is superior.

I don't know all the advantages of gettext. From what I read it seems to incorporate elements of a revision control system and all sorts of other things. If you wanted to write a multi-lingual app that had lots and lots of different phrases that could be output directly by the app itself then gettext might be a better solution simply because it enforces a degree of rigour that would probably be necessary in very large projects. I don't know enough about it to be sure if it is always an over-engineered "throw in the kitchen sink in case somebody needs it" package or if it is an essential tool in some situations. I think that in this particular case it adds unnecessary overhead to the code and imposes an unnecessary learning curve for translators; in other cases gettext may well be the superior approach. But then I haven't looked at Sam's templating code in sufficient detail to figure out which approach would be easier to plumb in (and my definition of easier may be at odds with Sam's).

So unless I'm missing something, using gettext would make it harder for anyone who wants to customize things.

Maybe that's why qmailadmin has more translations than Sympa?

How long has Sympa been around? It could be a very unfair comparison if Sympa has only been around a year. That said, there seems to have been an exponential decline in new translations for qmailadmin - the people who were eager for translations did them very soon after the mechanism was added.