In a beautiful 320+ comment thread we discussed introducing a metadata format for configuration in Drupal 8 to use for identifying translatable strings, potentially generate translation forms for configuration (or per-group or per-domain configuration) and possibly other uses (such as validation).
Our primary use case is multilingual configuration, and our efforts were not successful to get the change in core. If we want to be able to translate views, content types, user notification email text, and so on at least as shipped with core and contributed modules (even if not the configuration you create on your own site), we have no way to avoid solving this problem.
The most contentious question that contributed to the original patch series being turned down was how metadata is defined for configuration (file format and underlying system used), where (file naming and placement) and how you refer to metadata of outside dependencies. To explore this problem space, we now have not less than three parallel efforts lead by a star lineup of core contributors, @chx, @effulgentsia and @reyero. We all want to productively push forward and move on to other things once this one is successfully resolved, so your feedback is welcome on all three issues:
- One using kwalify and typed data: #1866610: Yet another schema format for Drupal configuration (Based on kwalify)
- Another one using typed data only: #1865300: Introduce configuration definition file format and API for reading it
- And finally one not even using typed data: #1861640: Provide config metadata solely for translation
For a short summary of how we ended up needing a metadata system of some sort, see https://drupal.org/node/1648930#comment-6840700 (and/or the design goals in the original metadata issue summary). If you have questions, find us on in IRC and on the issues!
Thanks a lot for your input!