Open phunsoft opened 1 year ago
Someone coincidentally reported the same issue on "Stack Exchange - Joomla" yesterday, see Workflow question: How to fix missing com_messages text?. I had answered my findings about languages being set to different ones and got response:
Interesting! I had English (UK) as the only language for both site & admin, but didn't have it selected as the admin default. I've changed that and will see if it resolves anything.
So it seems this is only dependent on the default language settings?
It's because Joomla\CMS\Mail\MailTemplate
relies on global language instance.
@SharkyKZ Do you mean to say, that one cannot have the backend in one language, say English, and the frontend in a different language?
But even if so, why would different default languages lead to a specific language file (administrator\language\<lang>\com_messages.ini
) not being loaded at all?
But even if so, why would different default languages lead to a specific language file (administrator\language\
\com_messages.ini) not being loaded at all?
Actually, it is loaded, but to a different $language instance. As @SharkyKZ mentioned, Joomla\CMS\Mail\MailTemplate
relies on global language instance, and that global language instance does not have com_messages.ini loaded (it's not language aware - a bug if you ask me)
As of right now, I don't know if change Joomla\CMS\Mail\MailTemplate
to have it language aware to solve this issue is safe or not. For the time being, you can use this workaround. Go to System -> Mail Templates , find that mail template, that mail template for each language, save it so that the subject and message of the template is saved with right string instead of being language items by default and it will work well.
@joomdonation Thanks. Let me first make clEar that my knowledge of the internals of Joomla are (still) very limited. So please bear with me and with what I write. Anyway, here I go...
Your comment regarding the $language instances triggers some questions:
com_messages.ini
loaded, why are the language keys in question being resolved when the languages are the same, but not when they differ? Joomla\CMS\Mail\MailTemplate
relies on global $language instance?com_messages.ini
loaded in this case alone?Even so Joomla\CMS\Mail\MailTemplate
does not seem to be language aware, the behaviour should be consistent: Language keys from com_messages.ini
should always be resolved, or should never be resolved, irrespective of the language settings.
I still think there is a bug in this processing, or possibly a conceptual problem.
Interesting: The mail template as shown in the editor does not show the language keys (e.g. COM_MESSAGES_NEW_MESSAGE
), but the resolves values from, probably, the com_messages.ini
corresponding to the current backend language.
Yes, this a better workaround than having to keep site and administrator languages equal. I prefer to have the backend in English.
@phunsoft To understand this issue, please look at this code https://github.com/joomla/joomla-cms/blob/4.2-dev/administrator/components/com_messages/src/Model/MessageModel.php#L358-L359 . You will also have to look at the code here https://github.com/joomla/joomla-cms/blob/4.2-dev/libraries/src/Language/Language.php#L287 to understand how Language::getInstance
works and the issue will become clear :
In case your frontend language is the same with backend language (assume the user who is receiving the message use default language) , then the Language::getInstance
in this line of code https://github.com/joomla/joomla-cms/blob/4.2-dev/administrator/components/com_messages/src/Model/MessageModel.php#L358 will return the global language instance, thus com_messages language file is loaded into that global language instance and it could resolve com_messages language item
In case the language is different, Language::getInstance
will return a new language instance (it is cached base on language as you can see from the code). So loading com_messages language file here does not change the global language instance, thus it could not resolve com_messages language item
As mentioned before, I agree that it is a bug here. I can see a solution, but I am unsure that it will be safe to make the change. So I pinged the author of this Mail Template feature so that he will have a look and we can discuss further if needed. For the time being, changing mail templates as I mentioned is an option
Otherwise, change setting of the user account (which receives system message) to have backend language same with frontend would be another choice.
Hope my explanation is clear to you. Understand this will require some code reading skill :).
@joomdonation Thanks a lot for the pointers into the code. I'll go and have a look, since I'm curious to better understand the internals. I do have enough code reading skills, but as someone which does not yet understand all the compex concepts behind a certain software, it takes time to get into it.
I had implemented the "keep languaes equal" workaround, but like the template workaround much better, so I switched to the latter.
As a side note: Someone coicidentially reported the same problem on Stackexchange - Joomla. I had answered with the language workaround and will update with the template workaround now.
Thanks for your time. Much appreciated!
You're welcome. One day we will fix it so that you don't have to use workaround :).
If this would turn out to be too complex to solve for what ever reasons, I could think of a required post-installation step after installing a new languge: Create localized mail templates for all installed ones. And this could be supported by a message shown under System -> Warnings, or System -> Instllation Messages, if there are mail templates which do not have a localized version for each language that is installed.
Just a thought that came to my mind.
Not that hard. I just haven't looked at it carefully enough to if it is safe to change without causing any unexpected behaviors.
It looks like this only happens with sites upgraded form joomla 3 to joomla 4. When you use a fresh Joomla 4 installation you don't have this issue and will get a nice Private message email when a article is created do the setting in the Private message "Email New Messages" turned ON.
So it looks like that joomla 3 upgraded sites to Joomla 4 don't use the language file \language\com_content.ini to sent the e-mail messages. Instead of that they use the \administrator\en-GB\com_messages.ini file.
Fresh Joomla 5.1 Problem with Privacy: Request Export of Data (Admin) and Privacy: Request Removal of Data (Admin) e-mails. Frontend is in Swedish and if Backend is in English, e-mail sent to Administrator contains only COM_MESSAGES_NEW_MESSAGE COM_MESSAGES_NEW_MESSAGE_BODY
If both languages are set as Swedish, e-mail displays O.K. but in Swedish.
I don't get what is workaround here?
Joomla forum thresd: https://forum.joomla.org/viewtopic.php?t=1009444#p3722752
I had the same problem and I solved it opening and saving the mail templates. In the database table #__mail_templates I had the entry
com_messages.new_message | com_messages | | COM_MESSAGES_NEW_MESSAGE | COM_MESSAGES_NEW_MESSAGE_BODY
I went to System -> Mail Templates and opened the mail template for "Messages: New message " in each language I have installed ans saved it
In the database I have now two new entries
and the mails are now correct
This is still buggy. See also #42353 and #43503 Had this problem again with mailtemplate for automsg component. When changing Dutch mail template and saving it, it creates an entry in database and English is used again.
Steps to reproduce the issue
en-GB
.de-CH
. (I tried also withde-DE
, andfr-FR
: Same result.)Content - Joomla
plugin.Expected result
Joomla should send a message with
Actual result
This works fine when the default language in the backend is set to the same language for "Administrator", and "Site".
With "Site", and "Administrator" default languages set to different languages, a mail is still being sent, but:
Above constants are language file KEYs, which are defined in file
administrator\language\<lang>\com_messages.ini
(where<lang>
is any of the above the language codes) as follows:Somehow the those keys are resolved to the corresponding values when languages are equal, but are not resolved when they are different.
System information (as much as possible)
This bug probably existed since Joomla 4.0 (and under PHP 7.x), I just hadn't time to investigate until now.
Additional comments
I was debugging locally using "Eclipse for PHP" to find out what's going on. Here is the result:
Class "Language" (
libraries/src/Language/Language.php
) has a property$strings
, which is an array to hold all "known" language "KEY=value" pairs to be used in translation. This array has some 1900 entries in the context where the notification mail is being prepared and finally sent by the "Content - Joomla" plugin.This array holds above "KEY=value" pairs (and some 70 more "COMMESSAGES..." keys) that are loaded from language file
administrator/language/<lang>/com_messages.ini
in the cases where the "Site", and "Administrator" languages match. Therefore a mail is being sent out as desired. This file is present for all the languages I've tested with, and the Keys in question are defined equally in each of the language variants.
In the case where the languages are different, it seems that this language file is not being loaded at all into the
$strings
array. Therefore the mail being sent out has the language keys in subject and body, instead of the desired text.Attachments
I'm attaching some files with information from the Eclipse debug sessions for both cases.
A summary of the test cases and results New article and language setting testing resulting mail summary.txt
Some snippets of the debug session with selected variables listed. New article and language setting testing with languages equal.txt
Complete array
$strings
in the language object. New article and language setting testing with languages equals $lang--strings[].txtSome snippets of the debug session with selected variables listed. New article and language setting testing with languages different.txt
Complete array
$strings
in the language object. New article and language setting testing with languages different $lang--strings[].txt