On URL internationalisation October 9th, 2008

My confrère Simon Batistoni, internationalisation engineer at flickr wrote a very interesting article¹ on URL internationalisation.

There are two possible schools of thought on this – one which would argue that the photo page http://www.flickr.com/photos/hitherto/257018778/ with a French interface is materially different to the same page when presented with an English interface. The French page, we might argue, should be named http://fr.flickr.com/photos/hitherto/257018778/, http://www.flickr.com/fr-FR/photos/hitherto/257018778/ or something similar.
On the other hand (and, in fact, the hand we eventually chose), the real “resource” here is the photo (and associated metadata) which the page points to – the interface is immaterial to the content we’re presenting. The big advantage of this approach, especially in a multi-lingual world, is that everyone gets the experience best suited to them.

Simon also emphases the major downside of internationalising a website with one single, immaterial interface.

The biggest downside to our current URL approach comes when search engines try to index our content. Since we don’t have language-specific URLs (and search engine crawlers aren’t in the habit of changing their language settings and retaining the necessary cookies), everything which search engines index on Flickr comes from our English-language interface.

He also says that “the core of what we do is focused around images” and he’s very right. Actually, choosing one method or another depends a lot of your content.
In Flickr’s case, the main content is a photo. To me it doesn’t really matter in which language I watch a photo on a website, it doesn’t affect its perception or its understanding.

In Last.fm’s case, the content is multiple. There is music —granted— but also lots of text. How many people are dragged by music from Google to Last.fm? Not many. On the other hand the artist biographies, journals, events, shoutboxes do. In this case, having separate interfaces is the right way to do it². Web crawlers reference the content in the different languages and increases the visibility of the very same website in the different languages.

But yeah, I think the Flickr guys made the right decision.

Footnotes

1. Well I guess it is interesting if you have a minimum of interest in Internationalisation. ↩
2. Although I would not recommend having a multi-domain website, it adds a heck of complexity. ↩

Trackback

Apple’s Copland October 7th, 2008

That’s what I call a massive management failure. Very interesting reading.

In 1989, managers at Apple had a meeting to plan the future course of Mac OS development. Ideas were written on index cards; features that seemed simple enough to implement in the short term (like adding color to the user interface) were written on blue cards, while more advanced ideas (like an object-oriented file system) were written on pink cards. Development of the ideas contained on both sets of cards was to proceed in parallel, and the two projects were known simply as “blue” and “pink”. Apple intended to have the “blue” team release an updated version of the existing Macintosh operating system in the 1990–1991 timeframe, and the “pink” team to release an entirely new OS around 1993.

The “blue” team delivered what became known as System 7 on May 13, 1991, but the “pink” team suffered from second-system effect and continued to slip its release into the indefinite future. Some of the reason for this can be traced to problems that would become widespread at Apple as time went on; as “pink” became delayed, engineers on the project jumped ship to work on “blue” instead, leaving the “pink” team constantly struggling for staffing. Management basically ignored these sorts of problems, leading to continual problems with delivering working products. In the case of “pink”, development eventually slowed to the point that the project was moribund, and Apple semi-abandoned it by spinning it off to form Taligent.

Read more

Trackback

magic_join model creation and rails 2 October 7th, 2008

If you are using Josh Susser’s clean magic_join solution to automagically create a join record an entry on a join table, you might well notice it doesn’t work with rails 2:

protected method `with_scope' called for #<Class:0x2109ddc>

Indeed the with_scope method is now protected.

In lieu of:

class Contributor < ActiveRecord::Base
  has_many :contributions, :dependent => :destroy
  has_many :books, :through => :contributions do
    def push_with_attributes(book, join_attrs)
      Contribution.with_scope(:create => join_attrs) { self << book }
    end
  end
end

Do:

class Contributor < ActiveRecord::Base
  has_many :contributions, :dependent => :destroy
  has_many :books, :through => :contributions do
    def push_with_attributes(book, join_attrs)
      Contribution.send(:with_scope, :create => join_attrs) { self << book }
    end
  end
end

Trackback

On machine translation September 28th, 2008

A typical story occurred in early machine translation efforts, which were generously funded by the U.S. National Research Council in an attempt to speed up the translation of Russian scientific papers in the wake of the Sputnik launch in 1957. […] The famous re-translation of “the spirit is willing but the flesh is weak” as “the vodka is good but the meat is rotten” illustrates the difficulties encountered.

Trackback