Follow up for #1648930: Introduce configuration schema and use for translation


The file location and names in #1648930: Introduce configuration schema and use for translation work but discussing many ways regarding the specific file locations and names is distracting that critical issue.
The discussion of the file location and naming convention needs a dedicated and non-rushed place to polish it and come up with something really nice.
This can happen after feature freeze.

Proposed resolution

I'll copy the relevant comments from the originating issue into the first few comments on this new issue, and then I'll summarize the approaches here in the issue summary.

Remaining tasks


  • copy the relevant suggestions from original issue
  • summarize them in the issue summary

after feature freeze or at least when people want a break from feature freeze tasks

  • discuss pros and cons
  • decide on a approach to pursue
  • mock up examples
  • implement code changes

User interface changes

no ui changes.

API changes

no api changes anticipated. (just implementation of location of files)


#1851498: Polish file format of configuration metadata (for translation)


webchick’s picture

Status: Active » Postponed

Postponing this until the CMI i18n patch is in; no sense in holding up other features in the meantime.

YesCT’s picture

1. meta location and names

Here are the current locations, and names, of the meta files that the patch adds from #1648930-247: Introduce configuration schema and use for translation. Just documenting it. Not lobbying for it.

Generated this list with: $ grep yml config_metadata-1648930-247.patch | grep +++ | cut -f2 -d" " | sed 'sxb/xx'


2. an (*the*) include in a meta

We have one (or so grep says) example with an include:

$ grep -R include core/modules/*/meta/*.yml 
core/modules/image/meta/      .include: 'image.effect.[]'

3. config names and locations

Here are the config names and locations (at least at the time of this posting)

YesCT’s picture

I'm a little less clear on location, so I didn't add much history. Please feel free to add any history you think is relevant, or just add new ideas.
The new include format I think helped reduce some concerns about implying merging based on location.


names and % patterns
#1648930-222: Introduce configuration schema and use for translation by @Jose Reyero

Example: image.effect.image_scale.yml
• Note this adds an explicit 'include' for the common image.effect properties (% is not replaced anymore)
• We are doing nested includes here: '' includes 'image.effect.[name]' which includes 'image.effect.%'


#1648930-237: Introduce configuration schema and use for translation

, it now seems odd to me that we have .definition inside the yaml files, but the folder name is meta. Can we rename to definition? I also find it odd for this folder to be outside of the config directory. If it's possible to move into the config directory without messing up existing CMI code, let's do that. Otherwise, how about renaming it to config_definition until such time as we're able to move it inside?


#1648930-238: Introduce configuration schema and use for translation

Neither ./meta nor ./definition directories really make sense to me. I'd actually prefer to go back to to '.meta' keys in the metadata files, just because it's shorter and equally gets the point across. And in light of that and earlier comments, a ./meta directory within an extension doesn't really make sense, because there is no relationship to config there. I'd see two possible resolutions: 1) Either change ./meta into ./meta/config on the grounds/idea that we might have further stuff that could use metadata like this, 2) Move ./meta into ./config/meta (inherently accepting the fact that this would prevent a "meta" context to exist for configuration, since all subdirectories should be considered as context override sources).
Jose Reyero’s picture

Title: polish placement of meta files for configuration metadata (for translation) » Better placement of meta files for configuration metadata (for translation)

On top of the location of the generic metadata files (that I really don't mind that much since any folder would work) we have the specific issue of metadata for plugins, that may need to be addressed differently maybe:
- Adding it as annotations into the plugin classes (which I'm not a big fan of)
- Placing it side by side with the plugin classes, in the same folder the class is, for which we may need to define some specific namespace in the configuration names (like 'plugin.*') to be able to resolve it to the right folder.
- Having one or more levels of subdirectories in the main metadata folder for each module. Example:

meta/ (this would be generic metadata not for plugins)
meta/views/display/page.yml (this would be the place for views' display plugins)

This is an example of how views metadata looks like when trying to describe properties for plugins (not complete yet):

Gábor Hojtsy’s picture

Status: Postponed » Closed (duplicate)
Issue tags: -sprint, -VDC

With the form generation concept discarded in #1648930: Introduce configuration schema and use for translation actual work is happening in #1861640: Provide config metadata solely for translation with the express goal of having a format/placement that people can agree on out of the gate. No need for followups.