Feature summary (what you would like to be able to do and where):

Consider adding support for multiple translation procedures (i.e., sets of selections and transformations) per template field.

Use case(s) (list the steps that you performed to discover that problem, and describe the actual underlying problem which you want to solve. Do not describe only a solution):

The current approach is that we have one single procedure per translation template field. As a result, the sequence of transformation steps is applied to the output of all selection steps combined. However, there may be a case where we would like to apply a set of transformations to the outputs of some selections, and another set of transformations to the output of some other selections. This is not easily possible with the current approach.

We do have support for non-unique fields; i.e., fields that may be included more than once in a given translation template. However, this is only used by "control" fields, whose output is not included in the final citation[1], and it is not clear how we should combine the output of multiple same-type fields.

Benefits (why should this be implemented?):

The current approach of "unique vs non-unique" fields, each having one single procedure, may be relatively straightforwardly be replaced with an "all unique" fields, each having one or more procedures, each with a series of independent selection and transformation steps. The output of these procedures (all arrays of strings, as in the current approach) would be combined by simply concatenating them.

The validation of this (plural) procedureS output would proceed just like we are validating our (singular) procedure output right now.

Because procedure outputs would be concatenated and validation occurs on a per-array-item basis, all outputs from all procedures should be valid for the whole procedures output to be valid. This is compatible with our current approach of many force-required control fields.

[1] The output of "Control" fields are used to decide on the applicability of the translation template they belong to. They are force-required fields.