dev/translation#67 - Allow translation of fields which lack an explicit HTML type #20606
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
…it HTML type _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.)
|
(Standard links)
|
|
@totten I'm ok with this but I can't help wonder if we should go with specific opt ins - ie
|
|
@eileenmcnaughton Yeah, long term, we probably need to do something like that. For the interim, it's kinda handy that it doesn't activate at all - unless there's a some kind of hook-listener. (It means that the system remains inert by default.) Of course, we could probably add an alternate toggle somehow. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Overview
The
Translationentity 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 their HTML widget is textual.
After
String fields can be flagged as translatable - if their HTML widget is either textual or undefined.
Comments
civicrm_msg_template(msg_subject,msg_text,msg_html) to marked as translatable.data_typeandhtml_typeconstraints were introduced during a much earlier draft. At that time, the list of fields wasopen-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.html_typedata forMessageTemplate. (But I don't know if this will have other side-effects.)