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

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

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

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

Any news on this?

should be fixed by #44243