ApiController: Unable to load the requested language file

[xenogenesi]

To aid in creating multilingual sites, the controller will automatically parse the Accept-Language header and attempt to load the language file specified in $this->language_file in that idiom/language. If that language file doesn't exist, it will default to the 'application' language file.

The controller try to use the idiom suggested by the browser, raising an error if the file doesn't exist, is this expected?

Shouldn't at least try to fallback to the default language in config? Or I'm missing something?

[xenogenesi]

@lonnieezell thanks but this fix set a default language if the browser doesn't suggest any, the problem remain if the browser does suggest one (or more) because detectLanguage return $return_langs and the constructor load the request->lang unconditionally, just try to set a different preferred language in your browser and browse to an ApiController url.

CI's system/core/Lang.php: CI_Lang::load():

...
if ($found !== TRUE)
{
    show_error('Unable to load the requested language file: language/'.$idiom.'/'.$langfile);
}
...

I don't see any way in system/core/Lang.php to check if the $idiom.'/'.$langfile exist, but this mean an ApiController based controller should provide every possible idiom suggested by the browser, I'm wrong?

BTW: Happy new year!

[lonnieezell]

Oh, dang, you're right. I read your initial post incorrectly. I will need to add a check to see if that folder and file exists within the APIController to avoid that, or extend the Lang library. I won't have anytime today, but should be able to look at that tomorrow night or Monday.

[lonnieezell]

Got a chance to look at this today. For now, a fix is in place with one caveat that I don't think is too big of one: you must have a folder within /application/languages that matches the language name. If no mapping exists in $this->lang_map than it will simply be the ISO code for that language.

The only issue I can see with this is that there might be cases where the language files exist within modules but not in the main application. However, I think that's going to be a rare enough case to be okay here. If you're supporting languages for portions of the API you'd likely have some main language strings for the overall API, if only for the common error messages you'd want to be able to send back.

Fixed in: 66d82f6

[xenogenesi]

Thanks, it works, nice idea to check the directory, so the error is still raised if the lang file is missing and that's good, the user probably just forgot to create it.

The only side-effect is the is_dir I/O time for each suggested language but I guess is just some other teardrop in the ocean.

About the module, maybe ../language could be checked instead? (relative to controller with some magic? maybe php's reflection?)
Should work both for an application and a module controller, CI_Lang::load() support a path argument

@param string $alt_path Alternative path to look for the language file

Notice if $alt_path is empty an alternative path for packages is checked, I know too few about packages to tell if using $alt_path break something.