To-day, I updated some software on a Samsung electronic tablet. The latest version comes with an ability to suggest changes on-the-fly to what I've written. These changes include to wording that Samsung calls Professional, to what they call Casual, or to what they call Social. What they call Social seems to be what they call Casual, with the addition of hashtags. What they call Professional certainly isn't very professional.

The software may already have been patched to address this specific error, but I'm sure that many other errors remain, and they will propagate. For decades now, a great many people, even people who imagine themselves as native speakers of the English language, have been uncritically accepting what software has told them about the language.

I will sometimes use software to check my spelling, but I don't simply make every change that it suggests. I find that, in analyzing my writing, grammar-checkers so often flag constructions that are actually correct and so seldom find real errors that these checkers are not worth running. And a person who relies upon software for tone is falsifying his or her relationships.

Since some time in April, a bug in the software at LiveJournal.com has kept me from logging into it, and from logging into other sites using that same software, with my OpenID. To-day I received an admission that the problem hasn't been worked and is not likely to be worked any time soon. If you're an LJ friend who posts nothing but Friends-only or otherwise filtered entries, then you might as well write me off.

More generally, my experience filing bug reports has not been very happy. I've recently reported my problems with the formula editor of OpenOffice.

Rather longer ago than that, I noted how WordPress, after letting two dead-lines slip, had just un-scheduled a bug-fix by setting a milestone of Future Release. This morning, I discovered that a spurious claim that the bug was not manifest had caused the report to be closed about three weeks ago. After I was compelled to jump through some otherwise superfluous hoops, it was plainly established that WordPress indeed had exactly the bug that I'd reported (on 29 April 2008), and that, from my initial description, the point of failure could have been quickly found and fixed. A patch was filed, and I thought that the fix would be scheduled for the next bug-fixing release (3.1.4 or 3.2.0, whichever came first), but then the milestone was instead re-set for Future Release. It might still be fixed in the next release, but there is simply no assurance of that. (I can hack my own installation, of course.)

As previously noted, back at the end of April 2008, when WordPress version 2.5.1 was the latest stable release, I reported a bug in the handling of nested q[uotation] elements by WordPress. The bug was scheduled to be fixed with version 2.7. Then, as the release of version 2.7 approached, the bug-fix was rescheduled for version 2.9. When I discovered this rescheduling, I wrote

And there seems no assurance that, about half-a-year from now, that target won’t be reset to version 3.1.

Well, that was actually more than 11 months ago, but two days ago, with version 2.9 in beta, the fix was rescheduled for Future Release, which is to say that it really isn't scheduled at all.

I don't really want to dive into the code to fix the error myself. For one thing, I've been thinking of writing an independent software package that would contain some of the same functionality as that of the package in which the bug resides, and I neither want to license the code of someone else nor face challenge as having perhaps cribbed said code. Further, I'd expect to have to invest significant effort to understand the code before I could properly patch it, and might have no use for the understanding after the patch.

WordPress version 2.7 has been released.

About eight months ago, when 2.51 was new, I reported a bug that had been giving me grief, a mishandling of the HTML <q> element. WordPress.org automatically set the target of fixing this bug by version 2.7 — which, frankly, to me seemed rather unambitious. It's one thing not to expect to fix a bug in the very next bug-fix release, quite another to put it off for two minor versions.

In any case, I've been looking forward to version 2.7. Now it's out… …and the bug is not fixed. In fact, I've learned that about two months ago, the target was changed to fixing the bug by version 2.9, another two minor versions away. And there seems no assurance that, about half-a-year from now, that target won't be reset to version 3.1.

Best practice in HTML is to put quotations into Q[uotation] elements, so that the mark-up looks like this:

Sam growled <q>I asked him, and he said <q>I swear on me mother's grave!</q></q>

rather than like this:

Sam growled “I asked him, and he said ‘I swear on me mother's grave!’”

Note that it is possible to have one Q[uotation] element inside of another — a good style-sheet will handle that.

Unfortunately, the WordPress editor seems to have been written by a programmer who believes that Q[uotation] elements must not nest, and the editor tries to fix things when it encounters nesting, by closing the outer element when it comes to the inner element. In the case of my previous entry, it then discarded the original closing </q> tag of the outer element, but (who knows why?) added an extra </div> at the end of the entry. The appearance of the whole page went to H_ll.

I fixed things by by-passing the WordPress software, and editing the 'blog's underlying dB with phpMyAdmin.

I've filed a bug report.

(I still need to arrive at a good specification of the list-bug that plagues my entry on installing Open Office.)