Plugin Project: WP Multilingual

(The page is still named “bilingual”, but we got ambitious.)

The aim of this project is to provide a comprehensive solution for bloggers who blog in several languages using the WordPress blogging software. Several of us have been using a mixture of existing solutions and personal hacks. Now, with someone who actually knows how to code PHP on board, we are set to take this a step forward.

• Chris' page
• Morgan's page

You can subscribe to the RSS2 feed for this section (namespace) of Palimpsest (this wiki) here.

Found at http://dev.wp-plugins.org/browser/multilingual/trunk/

From — chris waigl 2005/01/14 15:17

• Using the variable name $lang might be to general and lead to conflicts with other plugins
  • PHP functions have local scope only, so as long as we don’t global $lang; it doesn’t interfere with anything else.
• Language codes: better use lang_locale codes throughout? (what’s the difference between “_” and “-” in the codes anyway?) At one point, those codes need to be linked up with localization files (.mo) for WordPress, which use this notation (have to).
  • The language codes in the list use a combination of ISO 639, SIL, and ISO 3166-1 Alpha-2 codes. Specifically with Chinese, which has 5 dialect variations but only one ISO 639 code, I added the SIL codes to distinguish them. I decided to use underscores to join the 639 and SIL codes, and dashes to join that with Alpha-2 codes, which will allow me to filter and convert them as necessary. The WP language codes use [639]_[Alpha-2], whereas browsers use [639]-[Alpha-2] or just [639]. That’s why I wrote resolve_post_lang() to attempt to intelligently resolve the discrepancies between the code constructs and figure out the right one to display.
• Why $_SERVER[’HTTP_USER_AGENT’] and not $_SERVER[’HTTP_ACCEPT_LANGUAGE’]? (just curious)
  • ‘Cause I didn’t think of that. I’ll add a check for that before the HTTP_USER_AGENT.