_Overview_: The `Translation` entity can be used to translate certain fields. Currently, the field settings (`data_type`, `html_type`)
must satisfy some requirements before being translated. This change slightly relaxes those requirements.
_Before_: String fields can be flagged as translatable - but only if they a text-style HTML widget.
_After_: String fields can be flagged as translatable - if they have text-style HTML widget or no clear widget.
_Comments_: This is motivated to allow `civicrm_msg_template` (`msg_subject`, `msg_text`, `msg_html`) to marked as translatable.
The `data_type` and `html_type` constraints were introduced during a much earlier draft. At that time, the list of fields was
open-ended. Now, the list is much narrower (default=none) and requires an extra opt-in (`hook_translateFields`). Consequenty,
there's less concern about someone trying to translate an inappropriate field.
This patch seemed simplest/lowest-change, though I am open/ambivalent about any of these approaches:
* Completely remove the HTML-type constraint.
* Change the `html_type` data for `MessageTemplate`. (But I don't know if this will have other side-effects.)
public static function self_civi_api4_validate(\Civi\Api4\Event\ValidateValuesEvent $e) {
$statuses = self::getStatuses('validate');
$dataTypes = [CRM_Utils_Type::T_STRING, CRM_Utils_Type::T_TEXT, CRM_Utils_Type::T_LONGTEXT];
- $htmlTypes = ['Text', 'TextArea', 'RichTextEditor'];
+ $htmlTypes = ['Text', 'TextArea', 'RichTextEditor', ''];
foreach ($e->records as $r => $record) {
if (array_key_exists('status_id', $record) && !isset($statuses[$record['status_id']])) {