Either avoid or explicitly test binary encoding in default configuration

Maybe there's a way to prevent use of binary encoding? I mean some setting in SF

FYI x03 originally this comes from #532512: Plural string storage is broken, editing UI is missing and #851362: Add hash column to {locales_source} to query faster locale strings still open

IMO, we should drop the separator and migrate to a real array, because the plural variants list is an indexed array:

# String containing plural variants,
separated by EXT.
plural_label:
  type: label
  label: 'Plural variants'

# List of plural variants.
plural_label:
  type: sequence
  label: 'Plural variants'
  sequence:
    type: label
    label: 'Plural variant'

format_plural_string: "1 place\x03@count places"

format_plural_string:
  - '1 place'
  - '@count places'

The YAML encoder knows to deal with cases when a variant is missing. For example the Romanian language has 3 plural variants but if a variant, for some reasons, is missing, the encoder will preserve the deltas:

[
  0 => '1 loc',
  // The 2nd variant is missed.
  2 =>  '@count de locuri',
]

will be encoded as

format_plural_string:
  0: '1 loc'
  2: '@count de locuri'

With current code the above case would be represented as:

format_plural_string: "1 loc\x03\x03@count de locuri"

EDIT: Changed the proposed schema from mapping to sequence.

This is a first POC patch based on the idea from #4. Note that only the plural label storage in config entities is covered here. The handling of plurals by PluralTranslatableMarkup is left untouched, to be eventually discussed in a followup.

EDIT: Also this is proposing a way to deprecate config schemas, which probably needs an approval first as policy.

Fixing tests.

More test fixes.

Split off #2997100: Introduce a way to deprecate config schemas. Postponing this.

This change will require changes to the POTX module as that's designed to find plural delimiters in config strings - see https://git.drupalcode.org/search?utf8=%E2%9C%93&snippets=&scope=&reposi...

This fix is tricky - I'm not sure that changing this to an array is going to be simple.

As this is blocked on #2997100: Introduce a way to deprecate config schemas and that is 9.1.x, let's move this too.

Provided a patch on top of #2997100: Introduce a way to deprecate config schemas just to see the tests. Will take a look at potx module.

for what its worth there is not a way to disable the automatic conversion to use !!binary

@alexpott, you mean there could be other circumstances (other than plural variants) that would produce !!binary conversions?

@claudiu.cristea I mean there's no obvious way of handling our use-case and keeping the single string with the separator without doing upstream (i.e. Symfony) work.

@alexpott, for me it’s more than the binary encoding issue. On a YAML serialization we are serializing twice the plural label, once with our concatenation array serializer and then with the YAML one. The same happens with the PHP or any other serializer. In fact, as the plural label is an indexed array, any serialializer on Earth knows how to serialize it. A human, inspecting a YAML file is more familiar with a sequence comparing to a concatenated string. I’ve already discussed this with Gabor in #2765065-10: Allow plurals on bundle labels.

@claudiu.cristea I agree but that's a big step for POTX to take - it needs to find these special arrays and process them accordingly. And making change in POTX and re has always proven tricky.

I think your solution of actually using an array is probably the correct one - but it means we've got a lot of work to get all the moving parts to move at the right time.

Blocker commited

I definitely like the before vs after in the change record 🤩

Looks like the necessary changes in POTX are the hard blocker here. But … where does that code live? 😅 I guess I've been lucky to not have to deal with that in 15 years of contributing to Drupal 😳

Oh, and excellent work on #2997100: Introduce a way to deprecate config schemas, even if this did not yet land, #2997100 alone is a super valuable contribution! 😊🙏

@Wim Leers

> Looks like the necessary changes in POTX are the hard blocker here. But … where does that code live?

here -> https://www.drupal.org/project/potx

Here's a module that might save anyone who want clean plural variants in the exported YAML: https://www.drupal.org/project/plural_serialization

(maybe the idea could be moved in core?)

The whole logic is here https://git.drupalcode.org/project/plural_serialization/-/blob/1.x/src/E...