Voting starts in March for the Drupal Association Board election.
- Properly migrate date + date-formats/types + regional + locale system settings into configuration.
The data that needs to be managed includes:
- A variable for the site timezone
- A variable for the user timezone
- A variable for the first day of the week
- Variables for the date format preferences for each type of date format (short, medium, long, and custom)
- A table of date formats that needs to be removed and replaced with configuration
- A table of date format types that needs to be removed and replaced with configuration
- A table of localized date format types that needs to be removed and replaced with configuration
The variables are straight-forward. But there are open questions:
- How to name the new configuration objects?
- Which config object holds which variables?
- How to handle custom date formats? (vs. pre-defined system date formats that have to exist)
The tables are going to be more complex:
- The current system provides a way for modules to add values, and a UI for users to add values in the UI. Both need to be retained.
- The date format locale tables will have some of the complexities of the conversion of multilingual values to CMI.
For the naming of this and the rest of the configuration that needs to be updated, how about this:
date format variables - system.date:format.value
date format table - system.date:format.options
date format type table - system.date:format.types
date format locale table - system.date:format.locale
Then change the two date-related settings in the regional config:
date_timezone - system.date:timezone
date_first_day - system.date:first_day
This would give us a way to get a config object using the 'system.date' prefix for all the date-related configuration, and 'system.date.format' for all the date format configuration.
Concrete conversion issues
- - Includes site timezone and first day
- - Date format variables
Some issues that can help provide guidance on how to attack these problems include:
- - The problems of how to convert the contact categories table are similar to the problems we have for the date format tables.
- - The multilingual configuration has to solve many of the same problems we need to solve
- - We may need to have meta information in our yml files, so we need to follow this issue
- - We probably need to use the capabilities of the 'Configurable Thingies' patch