Make recipes translatable

At least YAML 1.2 allows for tags that allow us to define custom data types https://yaml.org/spec/1.2.2/#tags, then we would need to respond to the !translate type with wrapping it in translation at runtime and extracting it statically. Not sure how wide support for this is in tools.

key: 12
another: !translate This text will be translated

The default (failsafe) schema of YAML does not include !translate, however

All nodes with the “!” non-specific tag are resolved, by the standard convention, to “tag:yaml.org,2002:seq”, “tag:yaml.org,2002:map” or “tag:yaml.org,2002:str”, according to their kind.

per https://yaml.org/spec/1.2.2/#failsafe-schema -- which I understand that tools are expected to resolve custom tags as sequence, map or string based on which syntax was used above them. So !translate followed by a string would/should be understood as string when applied to a string by a YAML tool following the failsafe schema.

Adding related issues.

We'll need to figure out too:

* Potx support
* l.d.org support: we need to run potx on general projects that include a recipe.yml.

Any news here?

Looks like the Symfony YAML parser supports custom tags: https://symfony.com/doc/current/components/yaml.html#parsing-and-dumping...

Maybe something we could take advantage of here?

About having "recipes" as a thing - meaning the recipe's yaml strings - being translatable, can't we just use the same approach used for module's yml files? - I mean something like adding the files here.. (potx module) https://git.drupalcode.org/project/potx/-/blob/8.x-1.x/yaml_translation_...

Then the other big issue is having the content included in the recipes - Default content? - translated which may be a whole different story - and issue.

I think the pieces of the recipe where translatable pieces may appear are not predictable like that? Which is why I suggested !translate in #3 above. Or do you see a way we can predictably say which parts will be translatable? I think they would depend on whether the config they reference for example are translatable, which I'm not sure we can resolve?

The content is already translatable. Default Content exports translations and core imports them, and I'm pretty sure we have test coverage of that.

@gábor hojtsy
Not sure about which parts need to be translated, just trying to identify the pieces of this issue and noting this should be somehow part of how Drupal handles translation for generic yml files, though these ones may be more complex..

@phenaproxima,
You're right, default content is translatable. What we are missing though is some workflow to be able to translate that default content and include those translations with the CMS distribution. Same happens for Drupal's Umami profile, which includes English and Spanish in the download.

So we need to either keep this default content editable / translatable somewhere online, and then include it in the downloadable package, for every language, which I don't think is easy/doable with current infrastructure, or..

... maybe find some way for translatable strings in content to be extracted and available on LDO for translation, then downloaded on the fly, kind of like configuration translations... or...

... extend LDO to translate texts in default content, make the translated content downloadable... or....

well, I don't know, just pointing out the issue and that we need some new and fresh approach for this.

Being able to easily edit the translations is a separate problem from being able to translate them I think. Let's try to focus on translating recipes here?

Maybe symphonies approach can help here?
https://symfony.com/doc/current/translation.html

They have a way to handle yml files according to their docs as well and Drupal is based on it, isn't it?

I have to agree with @gàbor #13 about focusing on the recipes stuff first, not default content for now.

About extending yaml format / parsers, though it may open some interesting options, I don't think that is really what we need.

I've been playing around with strings, recipes, configurations and translations and as I see the problem, besides translating the strings in recipe.yml which looks like a trivial one, see ✨ Extract strings from Recipes Active translating the configuration shipped with recipes looks pretty much like the issue with module's configuration, only the yml files - and the schemas - are organized differently.

The main feature for having all these - modules, themes, recipes? - translated is being able to extract the translatable strings, for which we need basically to locate the configuration files and the configuration schema and that is the potx module, right? However, I've been running some tests and it looks like for individual modules, it also fails when extracting the strings for configuration whose schema is not in the module itself - still not sure whether having the module including the schema around will help.

When editing / installing the Recipe the modules providing the configuration schema are supposed to be available / installed so configuration translation will work just fine provided we have the translations available. So the only piece that is left is being able to parse the recipe package by itself and extract the translatable strings and that must be done by the potx or similar module.

I'm thinking two options right now that could also help with modules' strings: one is having the schema files located and loaded dynamically which may get really complex, and the other is having the Recipe / module providing some po file with these extra strings - that could be also generated by potx extended module but with the module and all the dependencies installed.

1. I think ✨ Extract strings from Recipes Active is a good one and simple one to make the labels of the recipes itself translatable.

2. Also config shipped with the recipes should be translatable (is it already?).

3. But finally what's not yet being solved and where I suggested the in-place YAML format support is config action values, eg. if you have a config action that updates the title of the a menu item or a views display etc that will save as-is and not translated.

2. Also config shipped with the recipes should be translatable (is it already?).

Yes, it should. AFAIK the missing piece here is the strings not getting extracted by potx.

3. ... where I suggested the in-place YAML format support is config action values ...

Ok, this is the part I was missing. Yes, I think these YAML tags look like a good option.

>> 2. Also config shipped with the recipes should be translatable (is it already?).

> Yes, it should. AFAIK the missing piece here is the strings not getting extracted by potx.

I wouldn't expect changes needed at potx for shipped config, but we probably need l.d.o to parse general projects and check if they are recipes looking at composer.json?

Today, I met with the multilingual track leads for Drupal CMS, and we determined that this issue -- with all its extensive implications -- is our main technical blocker.

I'm new to multilingual stuff (I live in 'Murica and therefore am only fluent in one language), but I'm eager to learn. Please forgive any ignorance on my part. :)

From my cursory research, I see four distinct phases emerging here:

1. We need to make sure all translatable strings are extracted from recipes. That includes all translatable strings in the recipe's config, the translatable values used in config actions, and the translatable metadata in recipe.yml. Ensuring that all of these things are extracted properly is clearly the foundation of everything else to come, and it looks like @jose reyero has already been making some headway here.
2. Once we have all the necessary strings extracted, we need to ensure they get onto localize.drupal.org. I don't know how this works, but I assume it will involve @drumm making some infrastructure changes.
3. Once a particular recipe has translations available on localize.drupal.org, we need some way to make those translations accessible to the recipe runner. We could change the recipe system so it tries to download the translations before applying the recipes -- like the way it handles modules, if my understanding is correct -- but I think that might prove quite fraught, since recipes are very composable and might be built on a bigger stack comprised of dozens of other recipes. I currently lean towards creating a Composer plugin that downloads a recipe's translations in the local filesystem at the same time as the recipe itself is installed by Composer, but that's merely one possibility; I'm certainly open to other options.
4. Finally, the recipe runner has to be sure that translations are properly applied! I'm not sure exactly how this will work, but it seems pretty certain that the underlying infrastructure for this already exists in core, so I imagine that this part of it would be reasonably straightforward.

I'd like to propose we turn this issue into a meta, organized around these four phases, with specific lists of issues that need to be fixed for each phase to be complete.