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

Problem/Motivation

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

Dots are used to mark the separation of path elements of a materialized path. In other words, consider in everyday usage "Section 1.3.4" or in CMI "system.modules.enabled". It's very very confusing to use them in meta element names.

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.

Some proposed resolution

  • Replace .list with *
  • Replace the dot in .definition and .include with either slash or > for example /include.

Remaining tasks

asap

  • 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.
but should give examples of the meta files.

API changes

no api changes expected. (just implementation changes)

Related

#1851502: Better placement of meta files for configuration metadata (for translation)

Comments

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.

chx’s picture

#188 said "mixup of config names and $definition elements was very very confusing". #240 said "I don't think having two alternate syntaxes is going to make things easier. It will make things harder to understand. We need to agree on one syntax IMHO. "

Whether you call it .meta or .configuration, it's immaterial but -- get rid of .label and .type. It's insanely confusing and the amount of writing you need to do is so small it doesn't matter.

YesCT’s picture

Current #1648930-244: Introduce configuration schema and use for translation approach. Just documenting it. Not lobbying for it.
These are not all the files from the patch. These are just the usual examples that have been used often and are in the comment blocks.

System

For example, for the config file core/modules/system/config/system.site.yml:

name: Drupal
mail: ''
slogan: ''
page:
  403: ''
  404: ''
  front: user
admin_compact_mode: '0'

The metadata in core/modules/system/meta/system.site.yml:

name:
  .label: 'Site name'
  .type: text
mail:
  .label: 'Site mail'
slogan:
  .label: 'Site slogan'
  .type: text
page:
  .label: 'Default pages'
  403:
    .label: 'Default 403 (access denied) page'
  404:
    .label: 'Default 404 (not found) page'
  front:
    .label: 'Default front page'

Mail

part of core/modules/user/config/user.mail.yml

status_blocked:
  body: "[user:name],\n\nYour account on [site:name] has been blocked.\n\n--  [site:name] team"
  subject: 'Account details for [user:name] at [site:name] (blocked)'
status_canceled:
  body: "[user:name],\n\nYour account on [site:name] has been canceled.\n\n--  [site:name] team"
  subject: 'Account details for [user:name] at [site:name] (canceled)'

part of core/modules/user/meta/user.mail.yml

.label: 'User mails'
.list:
  .label: 'Mail text'
  subject:
    .label: 'Subject'
    .type: text
  body:
    .label: 'Body'
    .type: text

image, example of include

core/modules/image/config/image.style.medium.yml

name: medium
label: Medium (220x220)
effects:
  bddf0d06-42f9-4c75-a700-a33cafa25ea0:
    name: image_scale
    data:
      width: '220'
      height: '220'
      upscale: '1'
    weight: '0'
    ieid: bddf0d06-42f9-4c75-a700-a33cafa25ea0

core/modules/image/meta/image.style.%.yml

name:
  .label: 'Machine name'
label:
  .label: 'Label'
  .type: text
effects:
  .label: 'Style effects'
  .list:
    .label: 'Image effect'
    weight:
      .label: 'Weight'
      .type: integer
    ieid:
      .label: 'IEID'
    name:
      .label: 'Machine name'
    data:
      .include: 'image.effect.[%parent.name]'
      .label: 'Data'

core/modules/image/meta/image.effect.image_scale.yml

width:
  .label: 'Width'
  .type: integer
height:
  .label: 'Height'
  .type: integer
upscale:
  .label: 'Upscale'
  .type: boolean
YesCT’s picture

Issue tags: -D8MI, -sprint, -language-config, -VDC

Note just showing the syntax changes does not give the intent of the changes, as there were also internal representation changes discussed. But at this point, people seem happy with the internal structure (see @yched's most recent comments on the original issue and the detail from #211, #216, #217-#222 and patch in #226, and a d8mi irc meeting mintues http://groups.drupal.org/node/268783#comment-855033)

Hopefully this will not be a discussion of the internal representation (if we need to have a discussion of that... I guess it would be in the main issue if that is not committed yet. or if that needs to happen in the future, after it's committed, we would open a follow up for internal representation.)

Forgive the places I have used names or not provided them. It was not always clear (or worth the time to go back and digest) if people were endorsing or complaining.

(Partial) History of syntax of the meta file contents.

(not to blame people, just to provide context)

I dont really understand the history before about 180. And we probably dont need to go back further anyway.

Thanks to all.

189.

From @chx
#1648930-189: Introduce configuration schema and use for translation

-  .label: 'Machine name'
-  .type: string
+  .meta:
+    label: 'Machine name'
+    type: string
 label:
-  .label: 'Label'
-  .type: text
+  .meta:
+    label: 'Label'
+    type: text
 effects:
-  .label: 'Style effects'
-  .list: '1'
-  .list settings:
-    elements name: 'image.style.effects.%'
-    elements key: 'name'
+  .meta:
+    label: 'Style effects'
+    list: '1'
+    list settings:
+      elements name: 'image.style.effects.%'

193.

From @chx
#1648930-193: Introduce configuration schema and use for translation
.meta -> .definition

+++ b/core/modules/image/meta/image.style.%.ymlundefined
+name:
+  .definition:
+    label: 'Machine name'
+    type: string
+label:
+  .definition:
+    label: 'Label'
+    type: text
+effects:
+  .definition:
+    label: 'Style effects'
+    list: '1'
+    list settings:
+      elements name: 'image.style.effects.%'

200.

#1648930-200: Introduce configuration schema and use for translation
I brought up order of things (on the same level). It was pointed out that the computer did not mind because they were associative arrays.

211.

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

- image.style.%.yml (provided by image.module, which defines ImageStyle config entity)
name:
  .definition:
    label: 'Machine name'
    type: string
label:
  .definition:
    label: 'Label'
    type: text
effects:
  .definition:
    label: 'Style effects'
    loop_on: 'image.style.effects.%'

222.

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

Drop all 'list settings'.
- Add '.include' directive with some replaceable [variables], ...
- Add '.element metadata' directive that will contain the metadata for nested elements

224.

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

list: '1'
.element metadata:

and replacing it with
.list

226.

#1648930-226: Introduce configuration schema and use for translation by @Jose Reyero

metadata: removed 'string' type (default), not quoting types (suggested by @YesCT)

228.

#1648930-228: Introduce configuration schema and use for translation by @Jose Reyero

fter talking with @yched again on irc and checking the image code we came to the conclusion that for image style effects, all the information depends on the container (image style) and only the 'data' array is specific of each effect.
This is basically supported by the existing code with an small addition: to include the specific effect, we need to use for the include a value that is on the containing data so we need something like this:
effects:
  .list:
    name:
      ...
    data:
      .include: 'image.effect.[%parent.name]'

Nothe the name we need to use is not in the 'data' array but one level higher.
This last patch supports this and other more complex naming schemes in case we need it, like:
- Parents multiple levels higher: [%parent.%parent.%parent.keyname]
- Values a few levels below: [.key.subkey.subsubkey]

230.

+++ b/core/modules/image/meta/image.effect.image_scale.yml
@@ -0,0 +1,5 @@
+.include: 'image.effect.image_resize'
+upscale:
+  .definition:
+    label: 'Upscale'
+    type: boolean

231.

#1648930-231: Introduce configuration schema and use for translation by @Jose Reyero

The multiple levels of %parent or the nested properties [name1.name2] may not be needed eventually but right now we are dealing with the lack of consistency and definition in the configuration data across modules, and also the configuration system itself has serious issues to figure out depencencies, like the latest addition in the form of 'manifest' configuration.

236.

#1648930-236: Introduce configuration schema and use for translation by @Jose Reyero

Metadata for image effects now without includes, @yched #230 [....] Added back '.label' and '.type' as a shorthand for .definition['label'] and .definition['type']. The reason for this is making metadata easier to write and read, while still supporting the full '.definition' array.

Really, as I've experienced myself when writing (big) views metadata, needing to write always the '.definition' array is a pain.
I've created some views metadata with plugins/fields/filters/etc/etc to see whether it fits nicely with the new model, includes, etc, and the answer is yes. The only issue is with plugin definitions written in hook_views_data() (see node.view.inc) but I think that needs to be upgraded anyway in views to use something else (because otherwise we cannot determine dependencies from the views data)

244.

Implied .definition (still in the internal structure), . added in front of .label and .type

#1648930-244: Introduce configuration schema and use for translation by @Jose Reyero

metadata in modules to use '.label', '.type'

diff --git a/core/modules/image/meta/image.style.%.yml b/core/modules/image/meta/image.style.%.yml

 name:
-  .definition:
-    label: 'Machine name'
+  .label: 'Machine name'
 label:
-  .definition:
-    label: 'Label'
-    type: text
+  .label: 'Label'
+  .type: text
 effects:
-  .definition:
-    label: 'Style effects'
+  .label: 'Style effects'
   .list:
-    .definition:
-      label: 'Image effect'
+    .label: 'Image effect'
     weight:
-      .definition:
-        label: 'Weight'
-        type: integer
+      .label: 'Weight'
+      .type: integer
     ieid:
-      .definition:
-        label: 'IEID'
+      .label: 'IEID'
     name:
-      .definition:
-        label: 'Machine name'
+      .label: 'Machine name'
     data:
       .include: 'image.effect.[%parent.name]'
-      .definition:
-        label: 'Data'
YesCT’s picture

Issue tags: +D8MI, +sprint, +language-config, +VDC

adding back tags.

YesCT’s picture

adding back tags.

Jose Reyero’s picture

Title: polish file format of configuration metadata (for translation) » Polish file format of configuration metadata (for translation)

Some notes, just to add some more background information into the issue:
- While any of the proposed formats will work for the machine, the goal of this is to make metadata easier to read and write by module maintainers.
- We don't need to rush this since we can script the changes for any format so my suggestion is we try to write some more metadata files for complex cases (views, node types if we get them in the config system, etc..)
- There are two kinds of properties we need to get into the metadata:
a) Description of the configuration structure. So far we've got '.include' and '.list'.
b) The TypedData API definition of the element. So far: '.type', '.label', '.definition'.
(Thus being familiar with both, configuration structure for complex cases like views and the full typed data api specification will help understanding the problem).
- Since the goal of this is to make the format human-readable, I think side by side comparisons will be helpful for any format proposed.

As an example (for image.style.%.yml) :

Format A Format B
name:
  .label: 'Machine name'
label:
  .label: 'Label'
  .type: text
effects:
  .label: 'Style effects'
  .list:
    .label: 'Image effect'
    weight:
      .label: 'Weight'
      .type: integer
    ieid:
      .label: 'IEID'
    name:
      .label: 'Machine name'
    data:
      .include: 'image.effect.[%parent.name]'
      .label: 'Data'
name:
  .definition:
     label: 'Machine name'
label:
  .definition:
     label: 'Label'
     type: text
effects:
  .definition:
     label: 'Style effects'
  .list:
    .definition:
       label: 'Image effect'
    weight:
      .definition:
        label: 'Weight'
        type: integer
    ieid:
      .definition:
        label: 'IEID'
    name:
      .definition:
        label: 'Machine name'
    data:
      .include: 'image.effect.[%parent.name]'
      .definition:
         label: 'Data'
chx’s picture

Status: Postponed » Closed (won't fix)

.list and .include already mars the simplicity (but when had multilingual cared about anything being simple?) of just using .definition. If we can't have a single dot property, it doesn't mater. All multilingual API is extremely confusing, it was always so, apparently always will be, so please, carry on undeterred.

chx’s picture

Status: Closed (won't fix) » Postponed

But, of course, noone will accept me won't fixing this so I reopen although I do not know why :/

Gábor Hojtsy’s picture

@chx: the .include was requested / suggested by @yched due to complexities in how plugins are used in Drupal, it was not added for the fun of making this complex because it is multilingual.

I personally don't see a reason in terms of the format that we could not include the "include" element under a .definition (vs. besides it like it is now). It is a special syntax element that we need to explain either way.

chx’s picture

The fundamental problem with the dot is that while I understand it was chosen as no config name ever can have a dot in it as CMI explode() on dot, it is also an extremely common character for marking a materialized path, even if you do not know that by name, for an example of everyday usage, consider something like Section 1.3.4 As I look at a meta file like that I want to create a reading from the root to the leaf driven by the dots arriving to complete nonsense and confusion. (Edit: of course CMI itself uses the dot to create such a path)

If you want (I am not sure whether anyone cares, noone but me complained about this in the mother issue but then again noone but me opened an issue against field_get_items either while everyone was just whining on IRC, twitter and blog posts so it might be that people are not happy they just don't want to fight) so if you want to, then consider using another character and maybe different characters for list and include and a different for definition. There are a lot of characters that can not occur in a filename especially on Windows : ? * < > " | / \. Slash for example makes an XPath-y expression which looks good to me. Maybe /include and /list and *definition? Or just prefix them with a star? Use the star instead of .list and use /include and >definition? There are a lot of possibilities.

chx’s picture

Issue summary: View changes

Updated issue summary link related other polish followup for file location and naming.

chx’s picture

Issue summary: View changes

Updated issue summary.

sun’s picture

Incorporating existing concepts and syntaxes:

- Annotations (doesn't fly if we have to parse this as YAML though)
- Shell/command line

name:
  #label: 'Machine name'
label:
  #label: 'Label'
  #type: text
effects:
  #label: 'Style effects'
  *:
    #label: 'Image effect'
    weight:
      #label: 'Weight'
      #type: integer
    ieid:
      #label: 'IEID'
    name:
      #label: 'Machine name'
    data:
      #label: 'Data'
      < image.effect.[%parent.name]

- # annotation-alike comment to denote metadata properties.
- * wildcard to indicate a list.
- < to read in another file.

That said, the include/piping doesn't look exactly right to me.

Why is the include an include and not a non-primitive type instead?

 effects:
   #label: 'Style effects'
   *:
     #label: 'Image effect'
+    #type: image.effect.[name]
...
     name:
       #label: 'Machine name'
     data:
       #label: 'Data'
-      < image.effect.[%parent.name]
Jose Reyero’s picture

Abot the special character to use for marking properties I don't have any special preference, but the dot seems to be the only one 'safe' at this point. Only because there are no specs about how properties can and cannot be named in config files.

Btw, the '#' won't work because as it is used for yaml comments, it is filtered out by the parser.

chx’s picture

Only because there are no specs about how properties can and cannot be named in config files. <= files. Files have restrictions. While you probably could create any filename programatically (perhaps not the slash on a Unix system) working with the is seriously inconvenient. I thought we had this discussion when the metadata files wanted to contain * in them...? We can file a separate issue to have config boink you over the head with a pretty exception if you want to name your config |<>|

Gábor Hojtsy’s picture

@chx: I could see how file naming gets into question when the file name pattern is looked at, but how are file naming restrictions relevant for the keys inside the .yml files? I feel like I'm not getting some connection here.

chx’s picture

The keys available to meta are the keys that are invalid to CMI and CMI keys are / can be filenames. Yes, it's possible to have separate restrictions for config($objectname)->get($keyname) $objectname and $keyname but let's avoid that at all costs.

Jose Reyero’s picture

Maybe the problem we have is that the configuration system doesn't define anything at all about filenames (config names) nor keynames within files so we are completely lost about what we can use for each (besides OS filename restrictions) ??

And I wouldn't ask for a harcoded validation, but a single documentation line telling us what is what.

So far I only know config names must be something that can be a filename with dots in it and that keynames are something that is split on dots to map it to an array.

So please, does anyone here know something I don't?. And please don't just tell me, but point me to the line withing Drupal core where that is documented.

Otherwise I am afraid the only real option we have for metadata keys, as ugly as it may be, are dots.

YesCT’s picture

One initial confusion I had understanding the meta files was why there was sometimes a type and sometimes not.

As I understand it, if there is no type specified, then the default is "string" and strings are not translatable. Examples are machine names, IEID..

Lists don't have types.. but what it seems to me is that they are a type.. like:

name:
  .label: 'Machine name'
label:
  .label: 'Label'
  .type: text
effects:
  .label: 'Style effects'
  .type: list
    .label: 'Image effect'
    weight:
      .label: 'Weight'
      .type: integer
    ieid:
      .label: 'IEID'
    name:
      .label: 'Machine name'
    data:
      .include: 'image.effect.[%parent.name]'
      .label: 'Data'
effects:
  .label: 'Style effects' //this is the label/description for the list?
  .type: list //effects is a list of stuff
    .label: 'Image effect' //this is the label/description for the list? uh?
    weight: //this is a list item
      .label: 'Weight'
      .type: integer

Maybe it would help to have an example that includes more than one effect?

chx’s picture

#17, we make our own rules. If we need to, we can add it to the doxygen of config(), Drupal\Core\Config\Config::get() etc.

Jose Reyero’s picture

#17, we make our own rules. If we need to,

Well, yes, good point :-)

So:
1. What is the char/chars we are going to save (aka forbid from config names) for marking up metadata names?
2. Are we discussing just a character or is there anything else in the format that needs fixing?

effulgentsia’s picture

Here's a thought: what if instead of needing a meta file per config file (or set of files with the same structure), we make one meta file per module. And make its format:

CMI_OBJECT_NAME:
  CMI_KEY:
    DEFINITION_KEY: DEFINITION_VALUE

That way, it's a known 3-level structure, and we allow CMI_KEY to contain "." and "%" as needed, rather than needing the meta file to follow the CMI tree.

I'm attaching a patch to show what I mean. This replaces all the meta files from #1648930-284: Introduce configuration schema and use for translation to follow this suggestion.

Additionally, I'm attaching a "min" file that contains the bare minimum needed for identifying what is translatable. My point in doing this is that while full metadata may be cool in theory, it's also a DX pain, and maybe isn't worth introducing until we have real use cases for them (e.g., if we end up implementing a Validation API). Perhaps it makes sense to start with the minimum, and then progressively add more metadata entries in the file as we have reason to? Note that this "min" file doesn't include the 'label' values. We currently have these labels in the forms where the configuration is edited, so duplicating them in a meta file is another DX pain. However, I'd be all for re-adding them here, if we also make the forms use this info rather than duplicating it.

Gábor Hojtsy’s picture

@effulgentsia: I'm curious how would this new file format apply to plugin data which can show up at any depth in a structure. Such as views plugin metadata, which I believe allows for that by design. Would you define it as many times with the same definition as it could appear in arbitrary nested depths in config?

As for the minimal format, well, it is not really minimal if you consider you only want to identify the translatable strings. You could cut it down even further and only define the translatable things (which don't need type since they should all be single strings). So in your minimal format everything is either a type: text or list: true. You can just as well include this as the "value" for the CMI key then and avoid one level of nesting, unless you invision other types of information would be relevant in the minimal format (which I doubt).

Anyway, I still remember the days when webchick and Dries were freaked out that Drupal 8 cannot be called a multilingual system if you cannot go and translate the site name. Well, even if we implement the metadata fully to how it is proposed in the current RTBC patch it would not be possible to do in core, because obviously we lack the form generation, validation and save code (and have no hope to have anything like that in D8). However, if we implement something like your proposed minimal format, we cannot even say core supports a contrib config translation UI in any useful way. Why?

1. Yes, it would identify translatable items, which should be extracted and translated on localize.drupal.org. It will not identify multilingual items, such as the site logo URL, which should not be extracted for localize.drupal.org but should be translatable in any case on a site (lots of logos have a tagline for example that should be translated). A contrib module's generated translation UI for the site information would include both the site name and site logo.

2. The text type information and CMI keys are far from enough to generate any form that we can honestly present to actual users. Having labels was a minimal support for a translation UI, but if we don't even have that, a contrib module's only choice would be to generate a form with bare CMI keys, no descriptions and no supporting context. Is that a shippable UI even in a contrib module? Well, I don't think it is. So the config translation contrib module would need to redefine all config metadata from the ground up again anyway (nesting, inclusion, etc) to define the labels for all of core at least. Also then contrib module authors will see no example to build on, so they will not define any supporting data for these translation UIs either, so this one single config translation contrib will need to define the metadata for other modules as well (and/or we will be back in the bridge module proliferation state where we are in Drupal 7, so you have views and i18n and then need views_i18n module to bridge the two). That is not even one step ahead of where i18n module was in Drupal 7. At least we could hopefully still inject the translations for CMI pieces with the CMI override system, if it stands the test of time that is (see #1859110: Circular dependencies and hidden bugs with configuration overrides).

Last summer I posted this summary of what i18n in Drupal 7 does to describe objects (metadata), inject translations (context and overrides) and generate translation forms, see http://groups.drupal.org/node/152929 - we have been explaining these over and over again in different discussions and meetings in Denver, Barcelona, Berkeley, etc. and it seems there is some collective understanding of the requirements when everybody is at one place but then after a while it fades and the "why the hell is this so complex" feeling takes hold and the requirements are ignored in further proposals.

The initial goal of the D8MI initiative was to not need a contrib module for config translation but that would have needed a whole rework of all configuration forms and workflows, that CMI did not even plan to touch. So given we had enough on our plate, we stepped back to a position where core would only provide supporting data for a contrib solution. If we step back from the most of the supporting data as well, then it is mostly all on contrib like in Drupal 7, and the only improvement we gain from CMI will be that the contrib module will have a little easier time to inject the overrides. (If the metadata is constrained to identifying translatables, it just plugs in a regression since exportables already identified their translatables with t() in Drupal 7).

Jose Reyero’s picture

Just in case someone wants to check documentation for inspiration, here are a few ideas and links:
- Yup, YAML spec supports metadata (see types and tags), http://www.yaml.org/spec/1.2/spec.html
- Unfortunately, the Symfony YAML parser does not, http://symfony.com/doc/2.0/components/yaml.html
- Interesting about mapping classes in YAML, http://docs.doctrine-project.org/en/2.0.x/reference/yaml-mapping.html
- Kwalify Schema definition for YAML, http://www.kuwata-lab.com/kwalify/
- Rx: Simple, Extensible Schemata http://rx.codesimply.com/

sun’s picture

I like @effulgentsia's idea and proposal in #21, as it keeps the data together in one place, and thus, that $module.config.yml config metadata YAML file will live next to, e.g., $module.routing.yml, which is equally a YAML file that defines all static routes that belong to a module. So I think that makes sense from a DX perspective.

I wonder whether we could combine one of the ideas in #12 into that — treating the definition for a sub-key as a non-primitive 'type'; i.e., this:

image.style.%:
  name:
    type: machine_name
    label: Machine name
  label:
    type: text
    label: Label
  effects:
    type: list
  effects.%.name:
    type: machine_name
  effects.%.weight:
    type: integer
    label: Weight
  effects.%.data:
    type: 'image.effect.data.[effects.%.name]'

image.effect.data.image_crop:
...

I.e., instead of 'include', we define the entire element to be of a certain 'type'.

That said, we could as well do something like this:

image.style.%:
  name:
    type: machine_name
    label: Machine name
  label:
    type: text
    label: Label
  effects:
    type: list
  effects.%:
    type: image.effect

image.effect:
  name:
    type: machine_name
  weight:
    type: integer
    label: Weight
  data:
    type: 'image.effect.data.[name]'

image.effect.data.image_crop:
...
Jose Reyero’s picture

Well, I like the format in #24 too (the second one).

Only some concerns (that I don't think would be hard to fix) about it:
- By using types like that we are doing away with the TypedData API, which I wouldn't oppose because so far it has given us more trouble than benefits. So maybe it is a better idea after all.
- Not all the metadata for an object is in the same module. Another module may define additional image effects that are used in image styles. (The other patch prefetches all metadata names, not a problem, so we can do something similar parsing *all* the files in advance and merging all in a big array)
- Views is a bit harder than that with multiple levels of plugins (plugins that use plugins). But again I don't think this is a blocker, we can make them fit into this schema, just it would be good to see how they look like to prevent ugly surprises.)
- We may need a merging strategy for modules to add their bits into other module's metadata, just for the record (I wish we had node types into CMI to see an example of this).

That said I don't really have the time anymore to embark into another one like #1648930: Introduce configuration schema and use for translation so all I can help here with will be some reviews. But I may be able to take care of adding the localization part back, later, if you want to drop it from this one so we can focus on metadata format only.

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, type and label and not relevant anymore and actual work is happening in #1861640: Provide config metadata solely for translation with the express goal of having a format that people can agree on out of the gate. No need for followups.

Gábor Hojtsy’s picture

Issue summary: View changes

Updated issue summary.