Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Mail notifying about new article is not properly built when site and backend languages are different #39228

Open
phunsoft opened this issue Nov 16, 2022 · 12 comments

Comments

@phunsoft
Copy link

phunsoft commented Nov 16, 2022

Steps to reproduce the issue

  1. Set the default administrator language in the backend to en-GB.
  2. Set the default site language in the backend to de-CH. (I tried also with de-DE, and fr-FR: Same result.)
  3. Enable Email on New Site Article in the Content - Joomla plugin.
  4. Log into frontend, create a new article and save.

Expected result

Joomla should send a message with

  • subject like [site name] New Article
  • body like A new Article has been submitted by 'firstname lastname' entitled 'title of the article'.

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:

  • subject is (literally) COM_MESSAGES_NEW_MESSAGE
  • body is(literally) COM_MESSAGES_NEW_MESSAGE_BODY

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:

COM_MESSAGES_NEW_MESSAGE="[{SITENAME}] – {SUBJECT}"
COM_MESSAGES_NEW_MESSAGE_BODY="{MESSAGE}"

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)

  • Joomla 4.2.5 with all named language packs at same level.
  • Template is (based on) Cassiopeia
  • PHP 8.0.10

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 "COM_MESSAGES_..." 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.

@phunsoft
Copy link
Author

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?


This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/39228.

@SharkyKZ
Copy link
Contributor

It's because Joomla\CMS\Mail\MailTemplate relies on global language instance.

@phunsoft
Copy link
Author

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


This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/39228.

@joomdonation
Copy link
Contributor

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?

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.

@phunsoft
Copy link
Author

@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...

Global $language instance versus multiple instances

Your comment regarding the $language instances triggers some questions:

  1. If there is a global $language instance which does not have com_messages.ini loaded, why are the language keys in question being resolved when the languages are the same, but not when they differ?
  2. I conclude that there is -- at least in the case where the languages are the same -- a second $language instance, which must have com_messages.ini loaded. And the keys in question are being resolved using this second instance. And how would using a second instance fit the comments that Joomla\CMS\Mail\MailTemplate relies on global $language instance?
  3. If 2. is correct, why would there not be a second instance in the case where the languages are different, or if there is that second intance, why would it not have 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.

Conclusion

I still think there is a bug in this processing, or possibly a conceptual problem.

Changing the Mail Templates

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.


This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/39228.

@joomdonation
Copy link
Contributor

joomdonation commented Nov 18, 2022

@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 :

  1. 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

  2. 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 :).

@phunsoft
Copy link
Author

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


This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/39228.

@joomdonation
Copy link
Contributor

You're welcome. One day we will fix it so that you don't have to use workaround :).

@phunsoft
Copy link
Author

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.


This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/39228.

@joomdonation
Copy link
Contributor

Not that hard. I just haven't looked at it carefully enough to if it is safe to change without causing any unexpected behaviors.

@Lumiga
Copy link

Lumiga commented Jan 4, 2023

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.


This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/39228.

@Hackwar Hackwar added the bug label Feb 22, 2023
@nidzo80
Copy link

nidzo80 commented Jun 3, 2024

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


This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/39228.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

7 participants