Deployment & Build Systems & Change Management

Hey guys i'm being bold here. But i couldn't figure out where to add D8 feature request so i thought i gave it a shot here.

I was wondering if what the pro's and con's are of making forms more entity'ish..

Why not make "all" the forms based on this form.entity type. Adding field (and thus widgets) would be a breeze (from a UI perspective). In core there are a few "fixed" forms like:
- the login form
- the contact form
- the password forget form
- the comments form
- the modules forms (like rating of add to cart)
- e.t.c.

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:

1. One using kwalify and typed data: #1866610: Yet another schema format for Drupal configuration (Based on kwalify)
2. Another one using typed data only: #1865300: Introduce configuration definition file format and API for reading it
3. 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!

The first DrupalCon to be held outside the U.S. and Europe will take place in Sao Paulo, Brazil, on December 6-8. I’m excited to be part of the Content Team and the track chair of the large-scale Drupal track for this important event.

It’s the first time this topic has been included in its own track at a DrupalCon. I wrote a blog post with the track description, and an invitation for anyone who is interested to present a session: http://devsu.com/labs/have-experience-large-drupal-projects-submit-session

We are holding a Field API architectural meetup in Munich the weekend before DrupalCon (Sat the 18th to Mon the 20th), next to the D8 Multilinguial Initiative sprint.

Practical info

The sprint starts at 9am the three days.

On Saturday and Sunday:

The sprinting venue is "film.coop" - http://film.coop/
Westendstraße 123, München
Access:
Subway U4 or U5, "Heimeranplatz" stop, 500m walk
Tram 18 or 19, "Trappentreustraße" stop, 200m walk

On Monday:

The sprinting venue is the DrupalCon venue itself
Westin Grand

Currently there are a few different proposals for how to do multilingual configuration:

Meta: http://drupal.org/node/1448330
Option A (sun): http://drupal.org/node/1617334
- Option C (chx): http://drupal.org/node/1617334

Option B (José): http://drupal.org/node/1616594

Helpful and colourfuldiagram: http://drupal.org/files/D8CMID8MI-2.png

Many conflicting questions/goals:

1. How much awareness does the calling code have to have about i18n?
2. Is i18n something we're baking in to configuration system, or are we better served by a more generic contextual system?