Steph has a good preliminary list. Quoting:

• add a small “language” text input to post.php (with a default value) (used dropdown with frequent langs)
• add an “other language excerpt” textarea, which posts to the corresponding custom value (unlimited number of title/excerpt/post values for different languages)
• display the “other language excerpt” at the top of each post
• provide a function to return the post language, and the other-excerpt language (so it can be declared in a lang attribute, allowing the use of language-dependent CSS formatting, in addition to being semantically correct) done
• if this is not already possible with the date function in the WordPress core, provide an alternative date function which will format the date correctly corresponding on the language of the post
• optional: figure out a way to adapt text like “comments”, “categories” etc. to the post language; make the plugin usable with more than two languages.

Other points:

• provide a function that returns all available languages so that the users can easily create a navigation bar that changes the default viewing language for the blog done
• send the excerpt/content stuff through the appropriate formatting filters
• get the preferred viewing language from the browser (via _SERVER[’HTTP_ACCEPT_LANGUAGE’]?) and store/retrieve from a cookie
• tie the preferred language to WP localisation
• add “title” attributes to automatically generated links
• systematically generate correct “lang” and “xml-lang” tags for all the bits and pieces
• make <!–more–> tags work with multi-version posts
• check that everything works with pages as well as with posts

In the long run:

• compatibility with the language picker plugin? (conversion tool for old posts?)
• provide a multilingual theme (outside/in addition to the main plugin download)
• provide the ability to machine-translate single posts to additional languages (is there a free, web-based service with a useable API?)

Localizing a blog isn’t quite the same as localizing software. In addition to the blog entries proper there are several types of strings a user might want to have available in other-language versions:

• template-structure related (dates, archive link text, form labels …)
• other bits of text that are hard-coded in the template (eg, the text above or below the comment form that provides directions for commenters, a supplementary descriptive string, footer text …)
• strings that are entered through the admin screen (categorie names, link descriptions, link categories …)

The first point could be understood to concern the localization of the blogging tool. The two others are blog-specific. Currently, WordPress supplies (partial) translations for the first two types of strings via gettext and __() and _e() functions.

There is no mechanism to provide other-language versions for the third type.

Another problem is that even when translations are available, a blogger may not be satisfied with the text that is provided, either in any of the languages used, or in the blog’s default languages. A single unsatisfactory language version, and the gettext mechanism breaks down. The solution – user-edited .po files – is too complex for the typical blogger.

An alternative to using gettext throughout would be to store user-supplied translations for whichever string the user wishes in a user-editable file (with a web interface supplied, eg in the options screen). Which file format? XML maybe.

The plugin itself would still be localized with its own .po/mo files – but this only concerns the strings used in administrating the plugin, not those that appear on the blog.

• Jason’s language picker plugin
• The (in-)famous bunny hack
• Some ideas by Daniel Glazman in particular about styling outgoing links to indicate the document language
• Stuff markup suggestions by Kevin Marks