That still doesnt really address the non-standard way that languages are handled

That still doesnt really address the non-standard way that languages are handled

Correct, but at least if you select Russian and you have no russian overrides, it will tell you that (Empty State) and give you the button to Add a new russian override.

These are all quick changes above and would fix some of the confusions I believe.

The issue with your approach is that without trying to create an override you wouldnt know what email templates are available and what they contain

The issue with your approach is that without trying to create an override you wouldnt know what email templates are available and what they contain

You could say the same about modules now.

The way someone is going to use this is:

• User gets an email when developing the site, admin says "oh crap thats ugly, lets fix this"
• Admin comes to Mail Template Overrides
• Clicks New
• Searches for "the ugly email by name"
• Selects it
• Sees the ugly email, makes his changes, clicks save

Also, currently, if you have filtered your emails by English (en-GB) and you navigate away, when you come back to System -> Mail Templates the filter is still there, so you dont get to see the list of "available types of email" anyway even now!

Right now you have to CLEAR the filter before you can see the list "available types of email" before you can select another one.

With my proposal, you would simply just click NEW and select the email to override, the list view filter would remain intact.

@PhilETaylor, If you mentioned me, I will say that I like your idea.

The first thing I thought when I first opened the email templates page was "why so many?" After all, I really may not need 95% of the templates. That is why I will support Phil's main message.

In addition, without adding to my Issue, I will add that the search by templates does not work either (it may not work at all in all components - I'm not sure). I didn’t even use Russian - it definitely doesn’t work there :)).

So, open the templates page. The clue briefly states that this is a mail search. OK. I enter the title of the first template - Actionlogs. Found, the search works. Cleared. I keep typing the title - now GLOBAL. Not found - DOES NOT work.

OK. I enter the title of the extension. For example, Contacts. Didn't find, doesn't work? I enter Messaging. Also did not find it.

OK. I enter Notification. Finds options where Notification is part of an ID. What for? I entered without ID :.

I spent about 15 minutes on options. A little messy described, but try and you play with the search. The main thing is that the search works partially. Those. it works incorrectly.

I'll fork the search issues for you to a new issue. #33659 Currently it looks like the search only searches the ID (which is non-numeric and the last column)

maybe i just dont grasp your explanation

A bit like this (ignore language at the moment)

The list view will then allow us to have a DELETE button too - because at the moment there is no way to remove an override.

ok i get it now.

Do you think this is worth pursuing (watch video) ? I think it brings the UI much closer (ignoring language issues at the moment deliberately)

Still to do - add checkboxes in list view, (work out how to have multiple languages in Joomla 4), fix flags/languages, add save&close as its own button, allow deletion of an override

If you want to see with your own eyes follow the repo/branch here https://github.com/philetaylor/joomla-cms/tree/mailtemplates ITS RAW AT THE MOMENT AND NO WHERE NEAR RELEASE/CLEANED UP - basically just a load of copy and paste to get this far as a POC.

If you think this has better UI and has a chance of getting merged then I'll complete it.

Select a mail template to customise

I think that sounds better ;)

Go for it. Now I understand its starting to make sense. Still not 100% sure how you are doing multlingual but I guess it will become obvious.

Still not 100% sure how you are doing multlingual but I guess it will become obvious.

Nor me yet haha. But it can't be any worse than it is already :) and can't be any worse than it used to be.

I first have to find a way to make Joomla 4 multilingual - is there a dummy language pack you are all using for Joomla 4 ?

1. Install french and persian
2. use the multilingual sample data plugin from the home dashboard
3. job done

That still doesnt really address the non-standard way that languages are handled

What do you consider the "standard way"? Is that using the Multilingual Associations and translating side by side?

Does this whet your appetite to get you all giddy and excited @brianteeman ?

Not the words I would use but its much more than lipstick on a pig

At this point it's basically a rewrite and not just lipstick unfortunately

thats why I said its much more than lipstick ;)

Of course technically its just a bug fix

get it submitted today

It's no where near ready, but luckily it will all be backward compatible (so far) so probably not make it into 4.0 beta so might have to wait for 4.1 as no maintainer has showed any interest yet

I think it is good idea, in general. Maybe more clear for end User.

However it still need some kind of a registry of available email templates.
Then in theory it also could solve existing issue "How extensions can add their 'templates'".

However it still need some kind of a registry of available email templates.

There is already this. My branch makes it look like this:

Then in theory it also could solve existing issue "How extensions can add their 'templates'".

They will do it in the same way, inserting a line in the #__mail_templates table - for now - although it would be a hell of a lot better if that was a Plugin trigger and that extensions could register their templates by plugin hooks.

At the moment the only change I have made at the db level is to add a id column with auto increment in the #__mail_templates table - my aim was to keep the underlying table intact and rewrite the extension from scratch - pretty much

Ive made good progress, just need a modal view for associations and then to tidy everything up, but there is no rush, I doubt this will be allowed in Joomla 4.0.0 anyway - unless @wilsonge makes that commitment Im not busting a gut to speed up the development over and above other bug fixes and my paying work.

They will do it in the same way, inserting a line in the #__mail_templates table - for now - although it would be a hell of a lot better if that was a Plugin trigger and that extensions could register their templates by plugin hooks.

Not every extension developers agree with you, some may get shocked that they need to insert something in to DB on their own :)

I did not design this, it was like this when I started :-)

"The Joomla Way™" would be to define an email as XML right :-) yuck :)

One thing that sets Symfony (and even WordPress) apart from Joomla, is their considerable extensibility by dispatching events. Something Joomla is very bad at doing (doing right).

Use of event instead of XML is better of course. The problem comes when need to trigger something in component at specific event. Yeah that old thing. Good solution would be merge component/module/plugin in to "single extension". But it another topic.

sorry, wrong button

So i fully agree the UI is better. Kinda unconvinced if the UX of searching for the template is really an improvement. But I do agree it's probably better than we have now.

Wondering for languages whether selecting the language from the off (on a multilang site) would make more sense (kinda like for modules how you have to select site/admin). Then the default screen can be the tiled select a template rather than the empty state screen...

So i fully agree the UI is better.

Phew

Kinda unconvinced if the UX of searching for the template is really an improvement. But I do agree it's probably better than we have now.

Im just reusing the concept, the concept of selecting a new "thing" this way is already in Joomla 4 with the selecting of modules to add to a dashboard etc.

Wondering for languages ...

Im implementing Associations the way that Articles does. So After you have selected the template you want to override, you can set the language while editing that, in the dropdown, just like you can in Articles.

I think the screenshots/videos so far in this thread dont show that yet. But basically it will be the same language handling as com_content doesn't it (as most of my work is copy and paste from there anyway haha)

Then the default screen can be the tiled select a template rather than the empty state screen...

The empty state is that Joomla will use all the default provided templates, and all the default templates provided by 3pd. This page doesn't need to know about languages - it is simply seeing if there is one, more or none templates already overridden. If more than zero then its not empty state and the list of templates overrides already created - regardless of language - would be shown. Then the user can filter just like they can on any multi lingual list view.

Im implementing Associations the way that Articles does. So After you have selected the template you want to override, you can set the language while editing that, in the dropdown, just like you can in Articles.

I totally got that from the propogate button and stuff :D but i don't think it makes as much sense here. With an article/modules etc you have to link two (unknown to Joomla) entities together.

With this you have a single translation for a known entity (the email). so you should be able to produce the links to all associate emails without ever needing to explicitly associate. Being able to hop between them obviously still useful however.

But given there's only ever 1 translation per language per email feels like there should be a smarter solution somehow...

One of the main criticism of Mail Templates UI was the non-standard way languages were handled

Eg:

@brianteeman That still doesnt really address the non-standard way that languages are handled

Therefore using associations seems to meet that head on.

The propogate etc will be cleaned up eventually. I was just please to finally get that custom field even displaying hahah

But given there's only ever 1 translation per language per email feels like there should be a smarter solution somehow...

But you could have a 10 language website, but only want to change the certain email for one language... :) No idea why, but it can be done :)

I mean somehow feels like cause template name + Lang is unique we can exploit that. But consistency is fine too of course

Im implementing Associations the way that Articles does.

Please without overengineering. .
I agree with @wilsonge , current template_id + lang already provide a way to get needed template, or "Associations".

&template_id=blabla -> loads site default language
&template_id=blabla&language=en-DB -> load English
...

overengineering

overengineering? If you think what I propose as over engineering, rather than simply implementing what Joomla already does, and has done for years, then we have a bigger issue and I might as well stop work on this completely.

Associations is the de facto way of handling translations in Joomla. It provides a side by side view to assist in translating and has been a part of Joomla for many years.

What you are now asking me to do is abandon implementing the "standard way that languages are handled" in Joomla and design a different system, at short notice, that has already been criticised previously in the Mail Templates interface as being "simply the wrong approach to languages"

I'll revert all my changes, and start again. Maybe in smaller PRs that might actually be less of a waste of my time and get approval for each step.

any chance of you completing and submitting this as a PR please

This would be great for 4.2 @roland-d

@brianteeman I totally agree.

@PhilETaylor So if you are willing to do this, I am happy to include this in 4.2.

As for the question on how to handle multi-language, the mail templates are also just language strings. Can´t we do this the same way as Language Overrides work. Select an extension in a dropdown and select the language in another dropdown.

any chance of you completing and submitting this as a PR please

This stalled for 2 reasons.

1. I ran out of time and steam caused by
2. No one could agree on which implementation they wanted and accused it of being over engineered when all I did was implement the way that Joomla implements multi-lingual association for content articles as asked for by Brian

The branch is still there if someone else wants to pick it up