Voting starts in March for the Drupal Association Board election.
Instead of doing a really complicated typeddata implementation inwe could just ship with the bare minimum metadata enough for potx to be able to extract the strings from the config files shipping with modules and to be able to create forms based on this metadata. For example, image styles could have the following metadata:
name: label: 'Machine name' label: label: 'Label' translate: TRUE effects: label: 'Style effects' repeats: TRUE effects.* label: 'Image effect' effects.*.name: label: 'Machine name' effects.*.weight: label: 'Weight' effects.*.ieid: label: 'IEID' effects.*.data: label: 'Data' include: 'image.effect.[effects.*.name]'
Note that repeats TRUE here is a hint to the UI that a repetition will happen and nothing else.
I would say this could ship in the same directory as the config and we could and should install as we do with config and add a ui: key so that people can mark parts translateable from the UI even if it's not something potx wants to -- the 404 page can be like this. When installing, expand the translate: TRUE into ui: TRUE, translate: TRUE. This is why everything has a label, so that everything can be marked for ui translation as the site demands.
Given we already have a locale override system, the UI just needs to grab the keys from config, compare to metadata, provide the form for UI: true keys, save to the overridden config, end.
Also when installing we can just run the translate: TRUE keys through t() to pull in .po provisioned values and save in the locale override again.
The metadata is never used at any other time, just install and config translate ui. Thus the cost of matching the config keys to foo.*.bar.*.baz is negligible.
As for potx, reads the config file, creates the keys, reads the meta, checks for translate: TRUE, knows what strings to extract and it only needs a YAML reader and a few dozen lines of code.
No typeddata, no nothing, straight as an arrow, small and easy. Some complication might arise from the image.style.meta.%.yml / image.style.meta.large.yml file which we likely want to keep as it was in the parent issue but I think we will extremely rarely need a specific version so that's ok.