branch i18n: setLanguage, namespace/domain and output->cache

[xenogenesi]

Not an issue, just FYI.

For a project where I need to manage multiple languages I'm using your classes (with gettext):

APP/core/MY_URI.php
APP/MY_third_party/myth/Localization/I18n.php

So far is working great, I only needed to add a little patch on myth/Localization/I18n.php:setLanguage in order to avoid collisions with output->cache (output->cache doesn't consider the lang segment and would have the same md5 filename)

I'm using a trimmed version of CI and in my load sequence there's only core/Router between core/MY_URI and core/Output, no places for the user to change cache_path, thought setLanguage would be the best place for a callback, a config evaluation or an event trigger.

Currently I'm just using a fast but raw patch:

     $this->config->set_item('language', CURRENT_LANGUAGE);
+    $this->config->set_item('cache_path', APPPATH."cache/".$languages[ $lang_segment ]."/");

[lonnieezell]

Glad to hear it's working out for you! And I like the solution with cache path there, though I'd want to check for the config setting for cache path and go from there... but I like it. Will definitely implement.

Thanks for the idea!

[xenogenesi]

@lonnieezell I've moved the call to set to the end of setLanguage before the return, called always, else the default language would save in cache/ and not in cache/language/.

+        $this->config->set_item('cache_path', APPPATH."cache/".$this->config->item('language')."/");

I was using built-in output's cache, but the project I'm working on, once generated, is really static, so I moved to a more static solution (and the hosting cache for static files can take place)

So I think would be better to have a callback (event trigger) here instead of a wired cache_path.

Also, I think I'll have to patch the current i18n to not use CI's config language, I want to keep only english for CI's built-in messages, gettext for site translations, if I understand correctly once you set the config language, CI will look for this language for every built-in message, I don't want to install lang translations.

I'm telling you about this because I think would be nice to have a generic implementation where the user can choose to use the official CI's config language or not.