Goal
- 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.
Other thoughts:
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
- #1571632: Convert regional settings to configuration system - Includes site timezone and first day
- #1708542: Convert systems date and time admin form to configuration system - Date format variables
Related issues
Some issues that can help provide guidance on how to attack these problems include:
- #1588422: Convert contact categories to configuration system - The problems of how to convert the contact categories table are similar to the problems we have for the date format tables.
- #1616594: META: Implement multilingual CMI - The multilingual configuration has to solve many of the same problems we need to solve
- #1648930: Introduce configuration schema and use for translation - We may need to have meta information in our yml files, so we need to follow this issue
- #1668820: Concept, base class, and interface for Configurables (e.g., node types, image styles, vocabularies, views, etc) - We probably need to use the capabilities of the 'Configurable Thingies' patch
Comment | File | Size | Author |
---|---|---|---|
#20 | d8_date.patch | 31.09 KB | cosmicdreams |
#18 | IMG_20120913_154059.jpg | 30.68 KB | cosmicdreams |
Comments
Comment #1
Gábor HojtsyConversion of date format setup sooner than later is an important step for Drupal 8 Multilingual Initiative so we can ensure all the multilingual underpinnings are well taken care of (some of which might require pre-feature freeze changes).
Comment #2
dagmarTagging
Comment #2.0
dagmarMake the list a list.
Comment #3
sunI still wonder whether we shouldn't simply have a
system.locale
config object that combines all the regional/date configuration.Meanwhile, I think that would make most sense.
Also, unless there's a misunderstanding, the issue summary suggested to put all the individual config keys into separate config objects/files; essentially leading to a range of config objects that only contain a single key. However, we're combining configuration by topics into single config objects/files. I've therefore adjusted the issue summary accordingly.
The system module would have to ensure that the predefined formats cannot be deleted from the config (and only custom formats can be added).
Alternatively, and if I get the summary right, then System module might have to know about the owner/origin of a date format. This could be accomplished by turning the format sub-keys into arrays, each:
However, I'm also not sure whether that functionality is strictly necessary to keep -- do we actually know whether there are any contrib modules that define their own date formats? I'd imagine that those modules could as well just add a new date format to the system.locale configuration upon installation, and, be done with it.
Comment #4
Lars Toomre CreditAttribution: Lars Toomre commented@sun I am confused. Why are you referencing *.locale.yml? This issue is about date and time configuration, which presumably can be included in a *.locale.yml file.
Locale information/configuration includes additional information to date and time, like language, currency, location, etc. This issue is strictly about date and time which is complicated enough in itself.
Comment #5
sunSorry for the potential confusion. I'm not referencing Locale module.
I'm precisely suggesting
system.locale.yml
as the config object to hold date + timezone + regional + country configuration.The underlying idea for combining them is that there's hardly a case in which you need date but not timezone configuration. The same potentially applies to the default country config, too (although it's hard to validate that, since it's not used in core).
If we go with
system.date
now, then that would cause an almost emptysystem.regional
config file, which only contains the default country config.Aside from that, I feel uncomfortable with putting each date format in its own config object. I think we want to combine them into one config object, since it is very likely that the system needs other date formats in the very same request.
Comment #6
Gábor HojtsyAs for confusion with Locale module, we hope to rename it sooner or later to Interface translation module or something similar, now that it does NOT handle anything related to locale (such as languages or currency). It is not 100% that would happen, but AFAIS it can happen up to Feb, it is not a new feature :)
Comment #7
KarenS CreditAttribution: KarenS commentedI'm not suggesting that each selected format have its own file, I'm making a suggestion for the way the file is named. Your example is more or less the file I was imagining (a single file with all the values), except that you're still calling these 'system.format' and there are lots of other 'format' values that we haven't addressed yet. These particular variables are the assignments of a selected format for each format type. Still to be converted are the list of all possible formats, the list of all formats grouped by localization, and the list of all format types. What are we going to call all those things if we already used the name 'system.format'? I was trying to give the names more clarity so when we get done they will all make sense by discussing all these names at once.
The odd man out here is country, everything else is about dates. Throwing all these date values into a file that does not even contain the word 'date' just so 'country' isn't alone seems odd to me. I think the names should be intuitive, and arbitrarily calling date values 'locale' is not intuitive, IMO. The only reason we're using this name at all is really because that's where it got placed in the admin menu a long time ago, not a good reason for locking those names in.
Comment #8
sunStill some confusion there ;) #3 calls them
system.locale : format
, sosystem.locale
is the config object, andformat
is a key within.We don't have an official standard for how to reference keys within config objects in communication and documentation yet, but so far we went with a colon as delimiter/separator; i.e.,
config.object.name:key.subkey
That said, you're right in that the key should be
date.format
, which would lead to keys:Alternatively, we can go with a
system.date
config object, which holds all date + timezone + format settings. Leaving the country + potential future currency settings tosystem.regional
orsystem.locale
or similar.Comment #9
KarenS CreditAttribution: KarenS commentedSo my example for the ultimate design would be something like the following, where 'value' contains the things now stored in the date variables, 'options' contains the values now in the date_formats table, 'types' contains the values now stored in the date_format_type table, and 'locale' contains the values now stored in the date_format_locale table. I'm not sure of how the table values need to be constructed or if all those values would be in the same yml file or different ones, just trying to create a vision for how it will be named.
Comment #10
sunok, let's simply assume we go with
system.date
for now. :)There are a couple of further details involved though:
I think the 'locale' keys/values will most likely vanish entirely. That is, because localization of configuration data will be handled through context plugins for the config system that are capable of overriding config values. This will approx. look like the following:
I.e.: we'll have the original file + a Language module override for a specific language, which is merged into the original when the particular language context is active.
That's essentially the multilingual (not translatable) aspect of configuration that @Jose is working on. The ground for that has been laid with #1646580: Implement Config Events and Listeners, and storage realms for localized configuration but isn't actually used yet - which explains why @Gábor Hojtsy is eager to have some config in core that needs it. :)
I'm not really able to make sense of the 'options' and 'types' sub-keys... What are they for?
In any case, I think this needs to be simplified. :) (That said, even though I signed off the original date formats/types patch some years ago, I never really understood why we have and need as much as 3 database tables for handling date formats... this system really deserves some huge simplification ;))
Comment #11
KarenS CreditAttribution: KarenS commentedOptions are all the possible date formats your system knows about. You can add as many as you like because we can't possibly know all the formats someone might want to use. They are currently stored in a table that needs to be converted to CMI. Before they were in a table they were hard-coded in core and you couldn't alter them.
Types are all the types of dates your system knows about. Core gives you 'long', 'medium', and 'short'. You can add others, either in the UI or modules can provide them in code. That lets you create a 'time' type and a 'date' type, for instance, as well as the core types that have both time and date. They are also stored in a table that needs to be converted to CMI. Before they were stored in a table they were hard-coded in core and you couldn't alter them.
The original variables let you decide which format you want to use as your 'short' format, 'medium', and 'long' format. Those are variables that we've had for a long time, as long as I've used Drupal.
The locale table makes is possible to say that 'short' looks different in France than it does in America, and ditto for all your other types. And that mapping is currently stored in a table. I have no idea how that was handled before we added this table. [Edit - I think there was no way to do this before we added this table.]
Yes it is complex, but I'm not sure there is any easier way to allow people to set default date formats for their system and have locale-specific variations of them. Lots of people have looked at this and no one who understands what all the problems are has come up with any better ideas, this was the best solution we could find, and it was a joint effort of a lot of people who do a lot of work on multilingual sites.
Comment #12
sunLet me try to make sense of #11 and "translate" it into simplicity:
I'll use pseudo-code to keep things small.
"Options are all the possible date formats your system knows about."
That's:
"Types are all the types of dates your system knows about."
That's:
"The original variables let you decide which format you want to use as your 'short' format, 'medium', and 'long' format."
If we want to retain a facility for "mapping" type identifiers to formats (not sure whether we want), then that would be:
"The locale table makes is possible to say that 'short' looks different in France than it does in America"
Yeah. As mentioned, that's localization of configuration, not to be baked into the original config objects.
Comment #13
KarenS CreditAttribution: KarenS commentedNot quite. You're assuming the only format options we need are the ones that are already assigned to variables. That format options table provides the list of all the possible formats to use, some of which are not currently being used. There has to be a place where this option list is stored, and that list can't be limited to the formats that have been assigned to format types. The list also can't be limited to the short list of formats that core is interested in. Users have to be able to extend the list. They now can see a list of all the formats that core has created, plus all the formats they created that they think they might need in the future plus all the formats that contrib modules have provided.
Similarly, the format type table may include types that haven't been used yet. For instance, in the UI someone can create a new format type and perhaps not immediately assign a format to it. I guess if they do that we could say we won't save the new format type and you can use the keys of the variables to retrieve a list only of types in use. But there still would be a problem because the format type is what you use in Views and formatters, so someone could create a new format type, set up a number of fields to use that type, and just not get around to assigning the type a format. If we save the configuration of their system at that point and don't save the unmapped formats, their fields will be using format types that won't get saved so things will be out of sync. Do we want to create this possibility?
Do you really want to re-invent this whole system right now? Can't we just get what we have into CMI and think about that later?
Comment #14
sunTo respond to the last question first:
The problem I see with the current, complex system is that types and formats would have to be converted into two independent Configurables (ConfigEntities), because they can be configured independently, in addition to the static list of formats being used in production; including proper handling of created/deleted/updated types and formats when staging/importing configuration.
However, the actual, resulting effect of all this immense amount of configuration is just a single list of key/value pairs being used at runtime. This list contains a couple of predefined formats that ought to always exist, and can be extended with custom formats added by the site admin.
Converting this list into configuration and implementing the required staging/import logic is relatively straight-forward.
Contrary to that, implementing the types/formats/mapping with the inherently required individual Configurables directly means to have to handle dependencies between the individual configuration items, as well as figuring out what to do in case a dependency cannot be resolved for any reason.
Thus, when comparing these two possible directions, it indeed makes sense to evaluate whether the complexity absolutely has to be retained, or whether a configuration-based system for date formats cannot look much simpler.
Comment #15
KarenS CreditAttribution: KarenS commentedI don't understand how to create whatever it is that you're trying to describe, so there's nothing I can do with this and I'm blocked. Maybe someone else understands how to do what you're describing without breaking the functionality we have now.
Comment #16
cosmicdreams CreditAttribution: cosmicdreams commented@sun, @KarenS and date-in-D8 team met today to discuss this issue.
I'm going to try to implement a patch that implements this tomorrow night so that we have something concrete to look through / discuss. Should I add that patch here or the #1571632: Convert regional settings to configuration system issue?
Comment #17
cosmicdreams CreditAttribution: cosmicdreams commented@sun my understand of your idea is illustrated with the following picture:
see below
1. use CMI's localization to relate Date Formats and Date Types
2. Denormalize Date Formats and Date Types so that Types are the keys and Formats are the values of an associative array
3. Convert "Options" into state.
Do I have that right?
Comment #18
cosmicdreams CreditAttribution: cosmicdreams commentedsecond try at the picture
Comment #19
cosmicdreams CreditAttribution: cosmicdreams commentedI'm working on this tonight. I'm going to start with the latest patch available from #1571632: Convert regional settings to configuration system and go from there.
Comment #20
cosmicdreams CreditAttribution: cosmicdreams commentedOK, this is obviously unfinished. But I started down the path of converting the obvious variable_gets and sets for date based config and quickly found functions such as a system_date_* that have been tasked with retrieving information about date formats and types from the system and from third party modules.
If we aim for the objective of storing all information about date_formats in configuration files we'll likely need to change these functions as well since they current pull information about date formats and types from the db.
Things I tried:
Questions:
if they wanted to add type / format pairs?
I hope this patch serves as a continuation of our conversation here. Let's keep this going.
Comment #21
sunYes, I think that's basically the structure and functionality I meant in #12.
Yeah, we did the same with other config defined "in-code" elsewhere already; e.g., modules were able to define default image styles/effects through special module hooks. Those are entirely gone. All configuration has to be saved explicitly instead.
Explicit saving and thus declaration of configuration is required to properly resolve dependencies in configuration as well as for staging configuration between servers.
Therefore, the removal of these date type/format hooks is expected, and actually required.
--
On the patch: As long as we're using this issue/patch to hash out the goal and vision only, that's fine. However, the actual changes should really happen separately, back in the respective implementation issues.
Comment #22
cosmicdreams CreditAttribution: cosmicdreams commentedIn order to pull data formats and types from other modules we'll need to access those module's config files. do we need to establish a new naming convention for that purpose?
Comment #23
cosmicdreams CreditAttribution: cosmicdreams commentedThe structure of a date_type and date format would need to change. But I don't think this simple pattern fits.
date_types and date_formats CAN be merged, but maintaining the human readable and machine_readable names are important (I think). I also think that the properties:
would be obsolete now that CMI would provide the localization of this config. Therefore the new formats part of the config would look like this
also:
Comment #24
cosmicdreams CreditAttribution: cosmicdreams commentedHere's some simple follow-up todos I'm finding along the way, most of which that aren't related to this:
#1787950: Undocumented functions in system.module
#1788588: Remove unused variables from SimpleTest's WebTestBase
#1788602: _locale_rebuild_js has a switch that doesn't properly break on cases
#1788608: system_modules_confirm_form, line 1079, if ($form) is always true
#1788610: hook_update_N has unreachable UpdateException
Comment #25
KarenS CreditAttribution: KarenS commented#1571632: Convert regional settings to configuration system now has a patch with a rework of the date format system to simplify it along these lines. That doesn't yet address how to localize the format, but looks like it may work all right for non-localized formats.
Comment #26
KarenS CreditAttribution: KarenS commented#1571632: Convert regional settings to configuration system has landed and I think it addresses the main concern that triggered this issue. There's no point in keeping this open as a meta issue since it's totally out of date now. I'm not sure where localization of date formats stands or if there's still a problem, but if so this issue is not going to be much help. Most of the discussion in this issue got incorporated into the regional settings patch. So I'm going to mark it fixed.
Comment #27
KarenS CreditAttribution: KarenS commentedActually, this ended up being a duplicate of the regional settings patch, so I'm marking it as that.
Comment #27.0
KarenS CreditAttribution: KarenS commentedUpdated issue summary.