Unhide message admin UI core extension

The message admin UI core extension is intended as a replacement for the core Message templates screens - as part of our process of deprecating the core screens through extensions. Currently it ships hidden

I'm creating this to get the steps to unhide the core message template admin UI.

The key reason it is still hidden is that it provides the opportunity to create translated versions of core workflow message templates - but core still does not send them out.

So we need to clarify what needs to be done to fill that gap - checklist first, then discussion

• Add a new formatLocale allowing this to be toggled separately to tsLocale - we already do this via a setting
• Add Subscriber for Translate to load a translation on get calls &, if available, change formatLocale and probably tsLocale (current use cases do not require the tsLocale change but that 'feels right')
• Language variant translations should load if available
• Add setLanguage to the GenericTrait
• Within MessageTemplate.render load the contact's preferred language & use setLanguage if not null.
• Within the message template UI ensure the formattingLocale is set when rendering
• Allow WorkflowMessageTemplates to be found from outside core - this is just a case of expanding the file search for them which we left tight to start with
• Message admin UI doesn't show the tokens available to it (even though they should be able to be determined.) It DOES show mailing ones - odd

Rendering

This is the key issue - when the render function is called in sendMessageTemplate (which is used to send out workflow emails within core) it needs to load the contact's language and call setLanguage. The responsibility for handling setLanguage is then on the Translation entity - which should ONLY take action if it can find a usable translation (this means we are not faffing with format localisation if we are not doing anything else) and it should change formatLocale (new) at that point and probably tsLocale.

Note that this means

• We are retrieving translations under get circumstances but they are not used in where or other clauses - the usage is for when the calling class does not know if a translation is in place

Interaction with existing api code Currently the DAOActionTrait implements setLanguage. When used the I18nSubscriber kicks in and calls setLocale which then

• if the site is NOT mutli-language it does NOTHING
• if the site IS multi-language then it either throws an exception if the language is not valid OR changes the dbLocale and the tsLocale if it is valid.

The only change that needs to be made here is to DO NOTHING rather than throw an exception if the language is not valid. There is otherwise no conflict with allowing the I18nSubscriber to make a decision based on the multilingual setting at the translation code from making a decision based on whether there is a translation for that entity availlable.

*** language variants*** We have some WMF code for this but basically if you speak Canadian French and only a French French translation exists you should get that, rather than the US English

Format locale Format locale is a bit tricksy since what makes sense varies - eg. US site sends an email to NZ user would ideally

• format dates to en_NZ
• format currency to en_US

Why? well the US dates can be confusing to an NZ user so NZ dates are much better. However, if you choose en_NZ for the currency the refence to it being in NZD will be dropped - which is something an NZ user is likely to be looking for to make sure. By always using the en_US you can also predict in smarty if it is likely to be there and (eg. add `{if currencyCode === 'USD'}currencyCode{/if}

Since our date formatting is currently only marginally localised I think we can ignore it for now & understand that for 'language variants' then only load the translated one.