Dear lazyweb,

I'm currently setting up a drupal-based site. While it's working pretty well and has allowed me to get most things done that I needed doing, there's one remaining issue that would need resolving. I tried asking for suggestions on the drupal support mailniglist and on the #drupal-support channel on freenode, but I haven't received a solution thus far. Hopefully someone reading one of the planets I'm on knows the answer.

The site would need to be multilingual. That is to say, not just the interface, but also all static content and some of the nonstatic content would need to be translated in two (at first) languages (perhaps more will follow in the future).

Using the i18n drupal module, I have been able to create alternate-language versions of some nodes, and enable a language chooser, allowing a visitor to choose a different content language for the site and seeing the site translated. However, there is one issue that needs to be resolved: the menu.

The i18n.module does not create an alternate version of a translated node; rather, it creates a new node. This node then is linked to the original node by way of some extra table that the i18n.module installs. As such, both versions of the same content will have a different node number. To give a concrete example, the Dutch version of the "about" page on the site I'm creating is node/2, whereas the English version is node/10. Since you might want to review the English version of a node even if you request the site in Dutch, you do not unexpectedly get the Dutch version anyway if you request node/10.

Since the node number is part of the URL of the node, this makes it impossible to create a link to "the about node, in whatever language is appropriate".

The i18n module also comes with a "i18nmenu" module, which allows one to translate a menu item's description using gettext. This works, but it has one fatal flaw: it does not allow to change the target of the link. As a result, and given the above, it's impossible to create a menu item for "the about node in the current language, whatever that means".

In an effort trying to work around that issue, I've come up with a number of things. Unfortunately, none of them seem to work to satisfaction.

• Create a URL alias, including the language prefix that gets added by the i18n module, and then link to the version without that language prefix from the menu: suggested by the i18n module's documentation, this does work, but has the problem that the menu system then doesn't detect that you're viewing the content which the menu has linked to. As a result, child menu entries don't get expanded, which I would need (my menu would get too convoluted if everything would be visible from the onset).
• Create a custom_url_rewrite function to change the target of the URL alias depending on the value of the $locale variable (which contains the current interface language). Turns out that this breaks the language prefix (i18n.module installs its own custom_url_rewrite function). Efforts to change my function or the i18n version of that function to change in such a way that both translations are done have failed; they seem to confuse drupal in some way. This is possibly due to the fact that the custom_url_rewrite function in i18n.module only performs one end of the translation, while my needs require both ends; I don't know enough about drupal to figure out how i18n's other side is implemented.
• Create something which will actually search for articles, in such a way that it is guaranteed that it will only return one article (e.g., by using a special taxonomy term or some such), and link to that search from the menu. This works, but only returns the teaser version of the page, requiring users to click a "read more"-type of link, which is not what you'd expect from a menu system. Ensuring that nodes to which we'll link from the menu are created so that they don't have a teaser isn't desirable, either.

At this point, I'm effectively out of ideas. If anyone has a solution (or can tell me why it isn't possible), I'll gladly hear it, either as a comment on my blog or by mail on w@uter.be.

New toys

A few days ago, I went to fetch the hardware that I'd ordered.

I don't think I've ever ordered as much in one go ever before. Well -- at least not when it wasn't for a customer.

My brother's girlfriend needed a new hard disk for her laptop, since her old one had broken (and of course she didn't have no backups, so now I'll have to find my 2,5" ATA -> desktop ATA converter and try to rescue what's there to rescue). Now since I had been planning to buy me some hardware before, and since my supplier implements an ordering fee for every order (no, they're not an end-user store), I decided to batch them up together in an effort to share the ordering fee over slightly more hardware.

I am now the proud owner of:

• A Linksys SPA921 VoIP deskphone.
• A Linksys something router with two builtin ATA ports (one FXS and one FXO). Since they didn't have an affordable ATA without the router stuff (the only ones they had without router were some 24-ish port €2000+ corporate boxes, but I don't need those), I had to pick this one. Not that I'll ever use the router bits.
• A 3Com 8port 1000BASE-T switch. As a result, I just retired my aging and flaky 5port 10BASE-T/10BASE-2 hub, and with it the single last 10BASE-2 segment in my network. After that, I moved the 100BASE-T switch to where the 10BASE-T one stood previously, and now the network is 100BASE-T at least everywhere. Not that I have the hardware to match on the other end of the connection everywhere (I don't have any Gbit NICs, and only a few 100BASE-T NICs; most of my NICs are 10BASE-T, though), but that doesn't matter.
• A Belkin 802.11g access point to replace the old and unsafe 802.11b one. Funny bit about that is that the old access point could talk 802.11x (aka the WPA variant that requires to set up a Radius server), but no WPA-PSK, whereas the new box supports WPA-PSK, but not 802.11x. Oh well.
• Two 500G SATA disks.

I also ordered a Thecus N2100, aka a "Yes box", to put the two 500G disks in — but those haven't arrived yet (still a few more days). Not that I'm even remotely interested in such an "external hard disk" type of thing, but there is some interesting stuff to be done with that hardware. Stay tuned.

Apart from the computer hardware, today I also went to Lemca in Deurne, and bought me a YFL 311 as an early birthday present to myself. I'd been in doubt between the 311 and the YFL 411, so tried both at the shop before deciding to go with the 311. While there is a difference in sound between the two (most notable in the lower octave), I didn't think the result was stunning enough to justify the €700+ extra for the 411. YMMV, of course.

I think I'll be playing a lot of music tomorrow.

Graphics hardware

Next time I need to buy a graphics board, It might be an AMD one. That, or an Intel one—Intel already provide open drivers (whereas for AMD it's still vapourware for the time being), but Intel's 3D abilities aren't as shiny. Guess it'll depend on what the hardware will be fore.

Updating Debian/m68k patches for gcc 4.2

In a perfect world, software would work perfectly. Unfortunately... well, you know the drill.

Since GCC 4.2 is upcoming, our resident GCC guy doko asked me to find someone to have a look at updating the Debian patches for GCC 4.1 so that they'd apply. Since I need to learn about GCC anyway for the Debian/ColdFire project (which nobody seems to be working on except for me), I started looking into it myself. The procedure is simple enough: uncomment lines in debian/rules.patch, and fix those m68k-specific patches that break.

The first one was easy. debian/patches/m68k-gc.dpatch has been integrated upstream, so is no longer necessary.

The second one was slightly more involved. But only slightly so; the patch tried to change libffi/src/m68k/sysv.S, which had received some three extra lines that conditionally add a .note.GNU-stack section. These three lines weren't there at first; but the .S file was otherwise entirely unchanged, so fixing this was rather easy.

The next one is, uh, pretty hard. gcc/config/m68k/m68k.md is a file of 7k LOC in the GCC-specific "RTL" pseudo-assembly language, which I'm not at all familiar with. Yet, anyway. As a bonus, the first hunk in this file which fails to apply does so because that bit of this code has been changed rather significantly from GCC 4.1 to 4.2. Meaning:

1. I need to figure out how this RTL code works
2. I need to figure out what this particular RTL code block does
3. I need to figure out what the point of this particular patch was
4. I need to figure out how to write a patch (in RTL) which semantically does the same thing as what the original patch was doing. Without breaking the changes between 4.1 and 4.2

Wish me luck. At least the first two parts are almost finished; after skimming through chapters 12 and 14 of gccint.info, this hugging code almost makes sense to me.

(oh, and if that last link doesn't make any sense to you, ask me for my fortune file at debconf)

(which is in less than a month! whee! excitement!)

Grm(b)l

It's been pointed out to me ages ago that you should not just buzz about some shiny new software and expect people to know what you're rambling about.

So, for the benefit of those of us who haven't got a clue: could you please explain what grml is?

Thanks,

Battlestar Galactica on VT4!

I just saw an ad on VT4 that they're going to be broadcasting the excellent Battlestar Galactica series—that is, the reimagined version. Caught me by surprise there, because I was actually expecting Kanaal2 to broadcast this—they're usually the SciFi channel in .be.

Not that this matters, of course. Luckily, they're also going to broadcast this at an excellent time slot: Sunday at 23:25 (or something), meaning, not prime time; as a result, I might actually be able to follow it this time around. Living together with people who like to watch prime time pulp would make watching this rather impossible during reasonable hours, otherwise. Not this time.

As it happens, I bought the original 1978 version of Battlestar Galactica only a few weeks ago. That one's a bit dated though, and not half as much fun.

VT4

In response to my Battlestar Galactica post of yesterday, Jonathan Carter wrote:

I just switched to VT4 and all I got was a login prompt

Grin. Obviously I didn't mean that VT4.

Web passwords

Thomas grumbles about websites with password policies, that make it impossible for you to use your 'standard' password which you use for other sites.

I cannot agree with him more. I have memorized a number of multi-character random passwords (generated with 'pwgen -s'), but these cannot be used on such sites; sometimes they require me to use a character that just doesn't happen to be in the password, or sometimes they're "too long", or whatever.

The worst of them all is sites which require you to change your password every so often, as I've ranted of before; after all, making people change their password too often makes it harder for them to choose a hard-to-guess password; after all, hard-to-guess passwords are often also hard-to-remember passwords, and nobody likes to memorize something useless every two months

In all, I decided not to use my secure passwords on such sites anymore. Not only do their policies usually suck, they also often have dodgy "security questions" which are easy to guess by anyone familiar with yourself. On top of that, there's usually nothing to make me believe their password database is actually secure.

Except, of course, if they have OpenID. Because then it's actually my own server where the password is verified. Whoo.