I first heard of structured blogging a few days ago and at first I thought it was an excellent idea. I mean which geek wouldn’t like its promise?

However, the more I think about it, the more skeptical I am. I’m not the first and other people said it better than I could. Shelley Powers questions the need for such a thing since modern publishing tools should provide more sensible, tailor-made solution. I may be down on WordPress, but this is something it gets right today. Paul Kedrosky sees user laziness as a problem, which might limit SB to enterprise as pointed out by Frank Gilbane.

I basically agree with all of them. First I don’t like the current implementation with embedded x-subnode format. I’m trying to move stuff like CSS and Javascript out of the document and it seems odd that I would now litter the same document with different kind of inline data. Contained blocks are a different representation of content and not a script, so it smells of tag abuse as well.

I like microformats, but that’s because I find it clever how you can use names to add meaning and structure to what you already have. It can be a cheap way to add value to existing data. In my opinion they are most suitable for pages that need multiple formats to describe contained data and each of them represents a fairly small chunk of the whole page.

Then there’s a question how you can get this data. I think there are 4 ways you get data from users:

1. it’s fun for them to do so
2. benefits to them by far outweigh the pain of providing the data
3. by accident
4. it’s forced upon them

It certainly isn’t fun. It’s difficult enough for me to select categories in which to put a certain post. Often they don’t fit in just one, so which interface would I have to use then?

And why? There are no immediate benefits or at least not any obvious ones. That strikes option number two.

By accident simply means what we already have. Google seems to be good at getting information out of unstructured data, but it’s certainly not what SB was supposed to be. Strike number three.

So what we are left with is environment with little choice, more often referred to as a job. It certainly not a novel idea, although it probably hasn’t been applied to blogs yet. I’m not all that convinced it will be, but I’m willing to be surprised.

Conclusion? No, thanks (for now).

A while ago I wrote a post berating WordPress UI that got more attention than I wanted. I still stand behind my words, but I’d rather be known for something else.

Hearing that new WordPress is around the corner, I was eager to write something more positive. Thanks to Shelley , I got a chance to test new WordPress (WP from now on) and see for myself improvements they made.

First the good news. WP provides a new WYSIWYG editor ( tinyMCE ) that certainly makes editing easier. It does just what you’d expect it to. I also like improved post preview, which uses iframe to show post in real environment, using theme of the blog. This has been something that really bothered me in current version, since it makes post preview barely usable. Previews are also available for themes, so you can see what blog should look like before you apply the theme.

WP has been “ajaxified??? and mostly for the better. For example you can add a new category while editing post. UI has been somewhat simplified by arranging it in boxes that can be closed or opened according to user’s need. User can also reorder them and since WP remembers their position and state, it’s a fairly effective way to customize UI to personal needs. Nice. I wish reordering was extended to other lists (e.g. links), but for all I know, this might be fixed by the time of 2.0 release.

However, my old complaints are still valid. While posts can be edited by other people of appropriate level, this hasn’t been extended to pages. Not a week passes by in which I wouldn’t bump against this limitation. Theme editor still gives you the same stupid choice between security and usefulness. User interface is more flexible, but still largely the same and often overloaded. There’s only so much that can be achieved by hiding stuff in boxes.

Nevertheless, WP 2.0 is a big step forward. Even bigger under the hood according to what I hear, but since I can’t be made to care about PHP, it’s not all that relevant to me. I certainly don’t think it sucks anymore, but I still think it has a far way to go before it will truly be a friendly tool for everyone.

Holidays are closer with each day and it’s getting harder and harder to concentrate on work, when your mind is occupied with loot coming your way.

It’s also a time of the year when web sites are filled with various summations of year left behind and always present guesses about the future. I certainly am not above that and I’ll probably add a line or two of my own in next few days, but I also wanted to finish my little javascript i18n library before the year ends. I don’t want it to turn into a pumpkin at midnight like some girl’s ride back home.

You know, sort of a present for everyone as it befits this holiday.

Alas, it’s taking longer then planned. So many things to do and so little time. Since trip to Stockholm is just around the corner, I decided to release what I believe by now to be practically usable piece of localization code. If you’re interested just in the goods, then you can see new javascript file here and demo here .

There have been few changes since last time . The whole thing has been objectified, but I kept few functions ( stripStr , stripStrML and new one printf ) outside of a class, since they’re too general to belong there. Nice thing about new class is that instead of looking for globally defined translation dictionary, it’s initialized with one. This also means you can use more than one translation object or translation dictionary per page, which sounds cool even if not all that useful.

I made a small correction to method toEntity . A bug was pointed out to me by Opera browser , which is a great browser for testing against standards, if not common sense. I might think it’s OK to fetch a character out of a string with their index value, as you would fetch an element from a list or an object, but I would be wrong. That’s why a string method charAt was defined and if working everywhere except in Opera is not good enough for you, then you must use this method. So, I did.

I also renamed the function _ . It’s a nifty name widely used in other languages, but it doesn’t work quite like that when it’s a method in an object. init.js demonstrates how you can still use it by defining an anonymous function.

This is it for now. I think the library is actually usable, but it’s also lacking few things. printf provides now a method of easily stitching stings together and even using parameters in translations. However, it does require that those parameters are listed in same order as in original text. Better than previously, but still often awkward.

What’s missing is also a tool to translate between javascript dictionary/object and a widely used translation format like GNU’s gettext . I’m currently working on this and I hope to have something usable ready in next few days.

Last but not least, it needs a useful documentation on how to use it and work with it. It will get it.

Update: It turns out my code might be usable, but it’s certainly not good. Some issues were listed in later post and some I discovered just recently. For instance it won’t work if you’re trying to translate text on buttons or if text to be translated includes HTML tags (case of tags is not preserved in DOM tree, which wouldn’t be a problem if Firefox and IE defaulted to the same one).