[eluser]esra[/eluser]
Personally, the lack of a decent i18n solution for CI is a pet peave of mine. It's something I have told myself was needed, but other priorities in life always seem to prevent it from happening.
The spagetti code in osCommerce sucks, but support for multiple languages in the core for both language strings and database content is fantastic. osCommerce supports both a default language (as does CI) and a current language. The 'current language' value is the language selected last by the end user during their previous visit (by selecting a language option from a view partial; an infobox in osCommerce terminology) and is stored in the user's cookie and the current session. Upon later visits to the same site, the cookie information is retrieved and used when opening subsequent sessions. With the existance of a global current language variable, the variable value can be used to determine which set of supported language strings to use and what language-specific database content to use.
I would imagine that the need for a current language was considered in the design of CI, but was not supported since sessions are optional. The current Language library was probably based on that requirement.
The trick to handling database content is to either include a foreign key for a language_id or to populate a language column with a idiom name from a select list, possibly generated by a helper from a languages array or config file. For something like the content table in a CMS, the content_id and language_id columns should be assigned to a unique key, or both fields should be treated jointly as a primary key for the content table, or primary/foreign key relationships can be used in queries. For osCommerce, common information that remained the same for all instances of content resided in one table and a second table was used to store language-specific instances of the content.
Following the above should provide the basis for application-specific i18n support. What's lacking to create a complete i18n solution is a Validation library which can conditionally use extended UTF-8 string handlers when required or mbstring when loaded by php.ini. You might note that the Kohana framework solved most of these issues, so a PHP4/PHP5 compatible solution for CI should be possible. The Language library also needs to be extended to support a current language value and a method should probably be provided to switch between languages based on current language selection.
Language selection can be handled in other ways. osCommerce provides a infobox (a partial or view fragment in CI terms) for language selection. It's also possible to automatically detect the users language using an IP locator (e.g., GeoIP) and code to determine the user's country based on their IP address. Earlier, a similar solution was used in the Rapyd library to detect the users language.
So, the underlying infrastructure for a decent i18n solution already exists at the system level. Writing extended Validation and Language libraries can solve the application-specific and module-specific aspects. Some helpers could be created to support extended UTF-8 string handlers by converting the php-utf8 string handlers on SourceForge (by Harry Fuecks) to CI helpers. The Validation library could use these helpers as well as your controllers and views.
