Skip to the Main Content

Note:These pages make extensive use of the latest XHTML and CSS Standards. They ought to look great in any standards-compliant modern browser. Unfortunately, they will probably look horrible in older browsers, like Netscape 4.x and IE 4.x. Moreover, many posts use MathML, which is, currently only supported in Mozilla. My best suggestion (and you will thank me when surfing an ever-increasing number of sites on the web which have been crafted to use the new standards) is to upgrade to the latest version of your browser. If that's not possible, consider moving to the Standards-compliant and open-source Mozilla browser.

February 17, 2005

Internationalization and Trackbacks

The Trackback Specification makes no mention of character encodings, and MovableType’s original implementation was blissfully ignorant of any such notion. The sender of a Trackback ping sent a string of bytes (which represented a string of characters in charset of his blog) and the recipient dutifully published that string of bytes on his blog. If the recipient’s charsethappened not to be the same as that of the sender, well, then, the result was gibberish.

The most recent versions of MovableType convey the sender’s charset in the HTTP headers of the Trackback. But the recipient doesn’t actually do anything with the information.

As a result, I had a slowly increasing number of gibberish Trackbacks on my blog, with no end in sight.

If you want something done right …

The first order of business is to realize that — somewhere along the line — we need to transcode the Trackback from the sender’s character encoding to the recipient’s. We can do this either before saving the Trackback to the database or after, when we go to build the actual blog pages.

It sounds tempting to do it once and for all and get it over with. But …

Perhaps the sender didn’t specify an encoding. Or perhaps he did, but specified it incorrectly (that Korean blog is supposedly utf-8, but the Trackback was euc-kr). Once we’ve transcoded and stored the result in the database, it’s pretty hard to recover. Better to store the original in the database, along with any charset information we may have received, and do the transcoding later. If we need to, we can add/correct the charset information and rebuild.

So the first order of business is to add a new column to the mt_tbping table:

The next order of business is to capture the character encoding specified in the HTTP headers and store it in the database. While we’re at it, I’m not sure why MovableType decides to truncate utf-8 strings at a fixed number of bytes, rather than a fixed number of characters. That seems like a recipe for disaster, so I commented it out.

Now, at this point, I could have made an enhancement. It’s very unlikely that a random string of bytes is valid utf-8. So, even if the Trackback Headers do not specify an encoding, it’s possible to test whether the Trackback could be utf-8 and set the charset accordingly. E.g.:

For the time being, I’ve decided to forgo automated charset-guessing. If I get a lot of utf-8-encoded Trackbacks without a charset declaration, I’ll reconsider that.

Finally, we need to ensure that things get transcoded when the pages are built. The magic happens in _transcode_text(). We use Text::Iconv to convert from the original encoding to utf-8 and then we use Encode (if necessary) to convert from utf-8 to the blog’s native encoding.

I then went back into the database and defined charsets for all the “bad” Trackbacks, rebuilt a few pages and …

So, have at it! Trackback this entry and we’ll see what breaks.

Update:

Fixed an inadvertently-dropped bit of patch code for lib/MT/Template/Context.pm above.

Update (2/18/2005):

For those benighted souls, who think that “Use utf-8.” is the solution to all i18n issues, here’s some data to think about. 93% of the Trackbacks here are plain ASCII. It really doesn’t matter whether (or what) encoding you declare for them. The remaining ones are about equally divided between iso-8859-1, like this Icelandic Trackback and utf-8, like this Japanese one. And, even after you’ve gotten the encoding right, there are still serious bidi issues to be resolved, as in this Urdu Trackback.

Note:

I should have said that Sam Ruby has been doing pretty much the same thing for half a year now. He transcodes incoming Trackbacks on receipt (and he “auto-detects” utf-8). As you might expect, this occasionally fails.

Posted by distler at February 17, 2005 1:04 PM

TrackBack URL for this Entry: http://golem.ph.utexas.edu/cgi-bin/MT-3.0/dxy-tb.fcgi/514

9 Comments & 9 Trackbacks

Re: Internationalization and Trackbacks

This is quite interesting, in part because I am now making a plug-in which will automatically decode trackbacks for russian blogs (where you can generally have only 2 encodings - cp1251 and utf8).

As MT has a hook for that it looks like you don’t have to modify the source. However, the expression used for matching UTF-8 does not always work for me - I send in sample strings in UTF-8 and they don’t get flagged. The data contains lots of non-latin text so it should not look as ASCII, still scratching my head on how to solve this. Maybe you have any ideas on how to solve this?

Safety First

If you are willing to do the transcoding at the time of receipt (and store the transcoded result in the database), then you ought to be able to do it with a plugin.

A couple of thing held me up.

Newer trackback implementations send the charset information in the HTTP headers, but I was not able to see how a plugin could access that information without modifying the MT source code.

Older trackback implementations send no charset information at all. So, at some point, you’re going to need to guess(/determine) their encodings.

You can try to guess the encoding, but, as that Korean trackback showed me, I don’t think you can do it reliably. The code to detect utf-8 does work (I tested it with the trackbacks on my blog), but there really isn’t a way to detect other encodings reliably (if at all).

Perhaps my approach is overly conservative but, after weighing the alternatives, I decided that keeping the original data on hand, so that I could — as a last resort — set the encoding manually, was the safest approach.

Not onlym the whole thing is flawed

Well, in principle russian letters do not intersect in UTF-8 and CP-1251 behalf ONE letter which is used very seldom (following whe spelling rules - only in names of people and companies), so the detection should ‘just work’ in this case.

What I wanted to achieve is a ‘dropin’ implementation (so that you can just install the plugin and never think about it anymore). It would be also nice to have a button in ‘Plugin actions’ panel like “MT-TrackDecode: decode selected pings” or such (which would allow to preview your decoding, choose a charset and finally conver the pings to your PublishCharset). But first things first.

Unfortunately this is my first experience with Perl and all of the ‘characters-bytes’ thing in recent version drives me nuts. In PHP it is much simpler…. For example, I am curious if you can efficiently ‘unpack’ what MT gives you back into strings from bytes instead of hacking on MT’s module.

What is really needed (IMO) is:

A clarification in TrackBack specs that specifies, that all trackbacks should be sent in UTF-8, with a charset header

MT should probably use the Encode::from_to when sending a ping to convert the outgoing ping into UTF-8 from the publish charset of the blog

Maybe there should be a way to specify a ‘fallback’ character set if the strings are not matched as UTF for incoming pings (for instance, it will be ISO for you and CP-1251 for most of the russian blogs, a japanese charset for japanese users etc. - but I digress)

Someone has to try to raise these issues in mt-dev. I don’t know if anybody will listen to me there, though. What is most annoying is that (being put off by these issues) russian bloggers just disable trackbacks after installing MovableType, and they never get used. And that’s what I would like to change.

Even more - a community of russian bloggers is currently writing an extension of standard TrackBack, which explicitly specifies that, should a ping be sent in invalid UTF-8 it should be rejected right away. Maybe this is also a good solution, however, I want to accept and send pings to people who use the same language as I and have blogs in this language. Besides, isn’t it nice if I send you a ping and russian-speaking visitors of your blog can read it along with your entry?

P.S. This is what happens when you implement web-services without agreeing on character sets first (i.e. without Unicode)

Spooged

Yes, the Trackback specification is spooged because it makes no mention of charset encodings.

I agree that declaring an encoding should be REQUIRED. I agree that there should be a default charset, if none is declared. But you cannot make that default charset blog-dependent. That way lies madness. The default charset should be iso-8859-1 (the default charset of HTTP) or utf-8 (the default charset of XML).

I disagree that you should REQUIRE that one particular charset (even a “nice” one like utf-8) be used. It doesn’t eliminate the need for transcoding. In fact, it can only increase the number of transcoding operations required (e.g., two CP-1251 blogs exchanging a trackback would require two transcodings, instead of zero), for little actual benefit.

I’ve filed a bug report with SixApart, pointing to this implementation. We’ll see what happens.

While I sympathise with the desire to create a plugin which would fix this problem of trackbacks, I don’t think you can implement a good solution using a plugin. Rather than implement a bad (or, at least, inadequate) solution, I think we should hack the MT source code, and hope that 6A eventually adopts our solution.

Russian Trackbacks

Of the four sent without charset headers, two had the tb_charset parameter set manually after they were received and stored in the database.

The remaining two are gibberish (as one would expect).

Now, remember, I don’t try to autodetect utf-8 (though I could) and there’s no way I could auto-detect windows-1251. However, it’s trivial (a couple of mouse-clicks) to correct the lack of encoding information after the fact.

Well this is trackback spam our way!

URL and MPF in the beginning stand for multipart-form-data and x-www-urlencoded (how the ping is being sent). I think I am encoding the latter correctly in my test pinger so…. strange.

My test pinger now sends 3 pings in 3 flavors:

Both in UTF-8, KOI-8 and CP-1251, as multipart-form-data and as URL-encoded (with charset header and without). That’s what the starting letters stand for actually.

Btw. I easilly got access to ENV from inside my plugin - strange you couldn’t. I will send you the plugin shortly, I think I will include something called “TrackDecodeFallbackCharset” - charset which will be used if the incoming ping is not flagged as UTF-8 and no header is provided, so that the user can set this for himself in mt.cfg

About mouseclicks - do you get additional edit fields in MT when you add properties to it’s objects?

Thanks for all the plugins

My memory is a little hazy on the environment variable issue. In the end, what I wanted to do — store the trackbacks in their original form, and transcode them on output, at least until we were absolutely sure we’d determined the charset correctly — required hacking the source code. Once I realized that, the other bits — which could have been done via an MT 3.x plugin — just seemed easier to implement directly in MT, rather than via a plugin.

A future enhancement is to provide a utility so that, once you are sure you’ve determined the trackback’s charset correctly, you can — with the click of a mouse — transcode it to your blog’s PublishCharset once and for all.

About mouseclicks - do you get additional edit fields in MT when you add properties to it’s objects?

No, though that’s another enhancement I’d like to add. Right now, I rely on a GUI MySQL client to edit the tbping table directly.

Re: Thanks for all the plugins

It works by first scanning the header, then matching the string as utf-8 and finally doing a ‘fallback’ to a predefined character set (I use windows-1251 but you can also specify your own). Of course it is not that safe but in this case I decided to compromise the integrity of the ping in favor of plug&play. Usually you cannot get both when you automagically guess the charsets.

Read the post Movable Type UpgradeWeblog: ProcrastinationExcerpt: I have upgraded to Movable Type 3.32 and have made modifications to run it natively with Unicode. I like some of the new features (better Unicode support and tags). If there are any problems due to the upgrade, drop me a line.Tracked: September 18, 2006 10:28 AM