I have tested this item ✅ successfully on 3767d85

I have tested this item ✅ successfully on 3767d85

RTC

Why hardcode strings ? why not load language file before JLog::add? i.e:
$lang = JFactory::getLanguage();
$lang->load('lib_joomla', JPATH_ADMINISTRATOR, $lang->getTag());


Had same problem with those keys on pre 3.6.1...

In this case there is no result when you call $lang = JFactory::getLanguage(); so it's not that the language files aren't loaded - but we don't even know what language object you are using in some edge cases. Hence the hardcoded string

At that point we know which language string we are looking for and where it's located. I would consider this PR as a hack :P

Except we don't know where it's located as we have no knowledge of what language we are in - as that information is also stored in the language object...

Sorry, I wouldn't post my example before testing it, code from my example works as expected, when selected en-GB for backend we get english string(s), and i.e. pl-PL shows polish string. Only after my test i found this PR.

Just updated my 'problematic' site to 3.6.2 which include this PR and all i get is
Warning
JLIB_APPLICATION_ERROR_COMPONENT_NOT_LOADING

event on backend login page (login form) - to be clear my code also show this messages at backend login form.

Created new site with staging and configured extension to make an issue that should correct message, all I get is (at login screen and after login there is same result):

So the problem here, at least for the frontend, comes from JApplicationSite::initialiseApp(). Specifically this line which is the first call to the component helper to load a component's parameters and happens when the user is a guest. The loader method loads all of the components and stores the data into memory (so one SQL query for the entire run). If you go back to that line I referenced, you'll note it is long before we've decided what language the user should have their text displayed in, which may not be the same language that the system detects.

There's another call to the component helper to get the com_languages parameters that may also be triggered before the language object is actually loaded even if you are not a guest. So now we have two points in that one method which may end up calling this method that was patched with the hardcoded strings before Joomla is aware of what language the text should be displayed in.

It's not the loader's responsibility to load language keys. Actually, nothing in JComponentHelper should be language aware, but every error message before the Platform/Framework split was pushed through the translation system; this causes more issues than it solves IMO. Two things we need to fix are pushing every error message to the end user by way of the message queue (logging to the "jerror" category does this too) and having Exception messages in the code translated (the code base is in English so internal error messages should be too; if you want localized error messages you need to implement proper error handling layers to catch errors and convert their messages to human/context friendly messages so you don't end up with something like "JUser: :_load: Unable to load user with ID: 42").

Ok, I get the picture... Im just a casual Joomla coder to say at least :P

But could anyone test if this PR actually works??

@mbabker as you can see at my screenshot this language key is still visible, not even hard coded strings are visible:

I did some checking and this code of yours fails when JFactory::$language is set - tested with code like this (that was inserted at line https://github.com/joomla/joomla-cms/pull/11119/files#diff-a9ca78ba0a2d4e122abeb2b5a906dc55R503):
$lang = JFactory::$language;
$msg = $lang->getTag();
get me $msg == 'en-GB'

so test at https://github.com/joomla/joomla-cms/pull/11119/files#diff-a9ca78ba0a2d4e122abeb2b5a906dc55R495 gives message with
JLIB_APPLICATION_ERROR_COMPONENT_NOT_LOADING.

Don't know how to test this (at my screenshots you can see some 3rd party extension, not freeware...).

Something is causing a JLanguage instance to be created before the application expects it if you're still getting untranslated keys. That part I can't help you with unfortunately, I just know that there are a few code paths which when followed could result in the error handling side of JComponentHelper::load() being triggered before the application has created the JLanguage object at the expected point and that's the condition this works around explicitly.

The other possibility is that your error is coming from something being done in a system plugin's constructor or onAfterInitialise event. The library language file is loaded after that event is dispatched, so I guess there is a short period of time where the required language files aren't loaded into the language store.

@mbabker #11842 (comment)
Works ok with #11842