Every morn­ing I’m in a won­der­ful mood, and I can’t pos­si­bly imag­ine how by the end of the day all code will seem mis­er­able and con­fused. Everything’s clear and easy and sen­si­ble. Text and struc­ture and organ­i­sa­tion are a solid tri­pod on which to hap­pily sur­vey the world.

By night­fall the dae­mons set in, mud­dy­ing the waters with angst-ridden doubt­ing of every­thing. But not in the morn­ing. The morn­ing is good.

[No comments] [Permanent link]

I’ve been get­ting con­fused about why an HTML form I’ve been build­ing inside a Word­Press short­code has been get­ting redi­rected after sub­mis­sion. Turns out it was because I was using p as a name for a request vari­able, and that’s not allowed. It’s one of the names used by Word­Press core; there are a few dozen of them.

I switched to pre­fix­ing my form’s input names with the name of the plu­gin, and all is well.

[No comments] [Keywords: , , ] [Permanent link]

There’s an Aero­press trick of turn­ing the plunger upside-down and putting the cof­fee and water in from the bot­tom. Every time I try it I nearly stuff it up because I never put the plunger in far enough, and so when I turn the whole assem­bly over the plunger gets forced out a bit and hot cof­fee and grounds goes all over the place. Well, nearly.

So instead, I put it in the proper way up: fil­ter and cap on, then cof­fee in, then water — and then I get super fancy and bal­ance the plunger on top, not pushed in at all but just 100% block­ing the air. This stops the water drip­ping through, and can sit like that for a minute or two. Then, it’s just a mat­ter of depress­ing the plunger nor­mally.

[No comments] [Keywords: , , , ] [Permanent link]

Is it a good idea to develop full-blown appli­ca­tions as plu­g­ins inside Word­Press (or an other CMS)? I some­times feel like it’s a silly thing to do. Espe­cially if the appli­ca­tion is not really doing any­thing to extend or com­ple­ment the stan­dard func­tions of the CMS, and is just exist­ing as a stand-alone crea­ture within it.

In Word­Press, for instance, lots of things can be done by cre­at­ing new post types: a plu­gin for track­ing books and authors could have two new post types for those enti­ties, and we would attach what­ever meta­data is required. Or alter­nately, a few new data­base tables could be cre­ated, and the book-managing plu­gin could do things directly with them and com­pletely ignore the stan­dard post func­tion­al­ity. The lat­ter would mean other com­mon fea­tures of fil­ter­ing and things wouldn’t apply, but then that’s often just as it should be when we need full con­trol over how an appli­ca­tion behaves.

Basi­cally, I some­times only really use Word­Press as a frame­work for:

  1. user authen­ti­ca­tion and autho­ri­sa­tion;
  2. instal­la­tion and upgrade;
  3. a theming/skinning sys­tem;
  4. inter­na­tion­al­i­sa­tion;
  5. famil­iar UI for users;
  6. the front-end/back-end dico­tomy.

And that’s it. Every­thing else is within the plu­gin. See how it feels a bit silly?

How­ever, it means that a plugin-application does have the things listed above (for no effort on my part), and it also gets what it per­haps the most impor­tant rea­son that I go this route: the Word­Press com­mu­nity.

So I’ll carry on being silly.

[No comments] [Keywords: , , , , ] [Permanent link]

I’ve pretty much fin­ished mov­ing a set of ‘tem­plate’ Nyunga-language Wik­tionary entries into my user­space on Wik­tionary, from where they can be copied into main­space. There are a few dra­mas with dif­fer­ing character-sets between def­i­n­i­tions in some of the word lists I’ve got, so a cou­ple of let­ters are miss­ing. There’s plenty that are there though, and mainly I’m inter­ested now to see if this idea of copy­ing, past­ing, and then copy-editing these entries is going to be a sen­si­ble work­flow.

I thought about bulk import­ing these directly into place, but the prob­lem with that is (quite apart from the first fact that none of these wordlists have machine-readable part-of-speech data) that almost all of them are going to need clean­ing up and improv­ing. For exam­ple, “kabain nin nana kulert” is in there as an entry. It means “per­haps some­one ate it and went away”, and (I’m guess­ing) isn’t an idiom and so really oughtn’t have it’s own entry. It can how­ever be used as a cita­tion in every sin­gle one of its con­stituent words. That’s some­thing that I think is best left up to a human, rather that forc­ing a human to clean up a bot’s mis­takes. Or take “tand­a­ban” which has a def­i­n­i­tion of “jump, to [9]” (and the square bracket ref­er­ences are through­out this dataset and are not explained any­where that I’ve been able to find). This should just be trans­lated as “jump” with a link to the Eng­lish verb; again, a script could han­dle that, but the myr­iad of incom­ing for­mats would take too much time to code.

Maybe I’m just not being clever enough about prepar­ing the data, and an import script, in a rich enough way. But that could take ages before ever this data sees the light of day on Wik­tionary; the approach I’ve used means that it’s there now for any­one who wants to work with it. There are also so very many improve­ments that a human edi­tor can make along the way, that it seems we’ll have bet­ter data for fewer words… and that seems to be the cor­rect trade-off. Wik­tionary is a ‘for­ever’ project, after all!

Of course, the plan is to be able to extract the data after it’s been put in its proper place, and I’ve started work on a PHP library for doing just that. I’d rather do the code-work on that end of it, and put in the time for a human-mediated import at the begin­ning end.

All of this is a long-winded way of putting out there on the web, in this tiny way, an invi­ta­tion for any­one to come and help see if this import is going to work at all! Will you help?

[No comments] [Keywords: , , , , , , ] [Permanent link]