Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
This is basically a followup to #1533286: Add support for Variable module, we should review all user facing strings that are strings that are stored in config and decide whether they really need to be in config or could just be plain translatable strings - things like the shipping quote error messages and credit card validation failure messages immediately come to mind, there is no need for these to be configurable in a different way to most other strings in Drupal.
Comment | File | Size | Author |
---|---|---|---|
#5 | remove-config-strings.patch | 8.91 KB | longwave |
|
Comments
Comment #2
longwaveComment #3
TR CreditAttribution: TR commentedI believe strings in configs are already translatable using core - configs have an inherited language key, defaults to en, and providing a translation is as simple as creating a copy of the configuration with the appropriate language key and string content. No need to involve the Variable module here.
Comment #4
longwaveYes, it's true that configuration is now translatable in core - but I don't see why some of these strings are configuration in the first place, and we are very inconsistent on what is configurable and what is not.
Why do we provide a UI to allow users to modify the description of the shipping quote checkout pane in the shipping quote settings page, or part of the customer information pane text, but no other text in the checkout page panes? Similarly we provide obscure settings pages for the shipping quote and credit card error messages, but no other error messages. These all appear to date from the D5/D6 days and feel like they should just be wrapped in t() only, perhaps making them a bit more generic as well - and then users can modify them in the same way they would modify any other UI text in Drupal.
Comment #5
longwaveComment #6
longwaveCommitted.