ActionlogsHelper::loadTranslationFiles()
can fail over on:
(Look at the extension paths for all of those)
Originally posted by @mbabker in #22701 (comment)
Labels |
Added:
?
|
Labels |
Added:
J3 Issue
|
Labels |
Removed:
J3 Issue
|
Labels |
Added:
J3 Issue
|
is this a god fit for ActionlogsHelper
?
shouldn't be an api feature ?
I'm going to work on a full PR for this issue (and #22701) primarily with specific reference to com_installer. The heart of the issue, from what I can see, is that the ActionLogs component doesn't load the correct language files. There are 2 reasons for this:
As @mbabker points out amodule could be frontend or backend so we need to know which language file to use.
There is a further issue (in general, not just com_installer) which is that for components the language string could be in a frontend OR backend language file so it should load one and check for a key and loading the other if needed, before falling back to .sys.ini files as a backstop.
My starting point is that com_installer manage extensions DOES already get the correct language files/strings to ActionLogs is just being sloppy from com_installer's point of view. So we need to mimic the translation algorithm from com_installer/manage - in essence using the content of the extension table as opposed to the name from the manifest file. We have the $eid so this is doable without much effort, but we risk duplicating the code from within com_installer.
So, a question before I dive in, are we ok replicating some of the com_installer code or should it be moved to a 'library'??
Some of the loader logic could probably be a library helper method.
As for figuring out the right client, right now that's not being stored in the messages, we need to add that for extension CRUD actions to distinguish admin and site languages, modules, and templates at a minimum.
Status | New | ⇒ | Discussion |
@GeraintEdwards did you ever write anything?
Category | ⇒ | com_csp |
Status | Discussion | ⇒ | Closed |
Closed_Date | 0000-00-00 00:00:00 | ⇒ | 2019-07-19 15:52:41 |
Closed_By | ⇒ | mbabker |
Afaik, templates names are never translated. Therefore no need to translate the name when installing, updating. (See our core templates as example). Modifying a template file is not added yet to actionlogs, but it would be the same situation if that was added.
When modifying a template style (admin or site), actions pick up the title of the style, therefore this also does not need to be translated.
In both cases loading the ini file is no use imho.
Modules.
When modifying a module (admin or site), actions pick up the title of the module, therefore this also does not need to be translated.
We do need the ini when installing, updating.
Site Components
we do need to load the ini.
I propose to load the lang in each case instead of globally (which also includes the code for templates, but can be omitted if my analysis above is accepted. In fact, the
tpl
case could be totally ignored)I know it is heavy code, but I tested it ok here. It is somehow similar to what you propose here for the extension name:
#22701 (comment)
What do you think?