Closed ik0 closed 8 years ago
Explain this better please, I don't understand what the "old behavior" or "language variables" that you're referring to are.
Old behavior - I mean before this commit https://github.com/bcit-ci/CodeIgniter/commit/03404890a5a0ea9c5e02c235a94312741bdf05b2
By "language variables" I mean it's get more complicate for application logic (at least in my case). Usually I decide which language to load at beginning, than generate custom calendar template, which use some of these language specific variables, and than load and generate calendar. Now I have to check language again after loading calendar library and reload calendar language file, after it has been loaded already in Calendar constructor. I think this is unnecessary.
I followed issues which this commit closes, but I don't understand why now it's better ?!?
Since the library can't work without translations, it automatically loads the ones for the configured language ... I still don't see how that could be a problem for you.
It become problem after I upgraded CodeIgniter and it overrides already loaded calendar language file with default language from config.php (not what my visitor expect), and with current version of constructor I have to load calendar language file again to overwrite phrases again. If you this think this is OK, I've already workaround it.
Just changing the application-wide language configuration at runtime - that's the whole point, loading each language separately is ineffective.
Current CI_Calendar class in its constructor always load default language (line 133) :
$this->CI->lang->load('calendar');
If I want to change language I have to load another language file AFTER calendar library initialization, but in this case language file is loaded twice. I think old behavior with "if" in constructor is better. I used to load language file before call $this->load->library('calendar', $prefs); because in $prefs I need my language variables.