The issue #3293384: Respect selected language for alert proposed that alerts only show on pages that match the alert language, but there are also use cases where it is desirable for translated pages to display an untranslated alert.
For example, a page for a public park needs an alert because of a wildfire, zombie apocalypse or other life-threatening emergency. The alert needs to go on the site, but there isn't time to have the content translated. It should be possible to display the alert in the original language on translated pages.
Add a configuration option to fall back on the original language, set to false by default. This way, the current behavior is retained when the module is updated.
In SitewideAlertManager::activeSitewideAlerts, check the configuration before filtering the collection on the current language.
| Comment | File | Size | Author |
|---|---|---|---|
| #12 | sitewide_alert-show_untranslated-3389209-3.1.x.patch | 4.33 KB | johan den hollander |
Show commandsStart within a Git clone of the project using the version control instructions.
Or, if you do not have SSH keys set up on git.drupalcode.org:
changes
Comments
Comment #3
chrissnyderComment #4
arantxioI've tested this and it seems to be working, but i think it would be better if we add a option on the specific alerts once this is enabled. Now it will always show untranslated items, even if you don't want it to.
Comment #5
calebtr commentedIf that level of customization is needed, it might be better to replace the query with a view. Is there room in the roadmap for that?
Comment #6
smustgrave commentedComment #7
chrissnyderThis issue hasn't received any significant updates in the past 12 months. If you think it is still relevant, you are encouraged to reopen and update it.
Comment #9
calebtr commentedRe-opening because we still need and use this functionality. I'm happy to work on tests, but I had asked module maintainers for advice on the best approach.
@arantxio suggested in #4 (#3389209-4: Make behavior of alerts on translated pages configurable) that this behavior should be configurable on a per-alert basis.
Translation behavior isn't typically configured on an entity-by-entity basis, at least not for content. But we could satisfy that use case if a site added a custom field and displayed a list of alerts from a view.
So, module maintainers, does it make sense to work on using a view for this module instead of a db query?
If not, do you agree with @arantxio's comment?
Comment #10
calebtr commentedComment #12
johan den hollander commentedTo make this compatible with the 3.1 version I first commited on the MR branch, but this may not be the right way. I could not find a way to create 3.1.x fork for this issue. So instead I added a 3.1.x patch.
Comment #13
chrissnyderComment #16
chrissnyderThank you for the patch Johan! I created and pushed up a new 3.1.x branch with this change.
Comment #20
chrissnyderComment #21
chrissnyder