bcit-ci / CodeIgniter

Open Source PHP Framework (originally from EllisLab)
https://codeigniter.com/
MIT License
18.27k stars 7.61k forks source link

Calendar language #4763

Closed ik0 closed 8 years ago

ik0 commented 8 years ago

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.

narfbg commented 8 years ago

Explain this better please, I don't understand what the "old behavior" or "language variables" that you're referring to are.

ik0 commented 8 years ago

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 ?!?

narfbg commented 8 years ago

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.

ik0 commented 8 years ago

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.

narfbg commented 8 years ago

Just changing the application-wide language configuration at runtime - that's the whole point, loading each language separately is ineffective.