Support for YAML anchors

General
1

Are YAML anchors officially supported in the configuration file and UI configuraiton on the project website? I saw them here being used:

When I tried them in combination with languages_mapping and android_code they did not work. The output was like using android_code without languages_mapping.

2

Maybe, just maybe, this thing can be supported by CLI or by Github Actions

I never tested, but if this staff works, CLI is the place where it can work. With default integration like Github or BitBucked it, most likely, will not work, because of connector strict logic.

Why you need them? Just curious. If you have a good workflow idea, maybe it’s better to ask for a feature request? Please describe step by step what you need to achieve, probably using out-of-box tools would be even faster to see the final result.

3

Someone decided to do a deep development :slight_smile:

@TiroliTemar is kinda right, anchors are not supported in integrations, but they should work in CLI. And as far as CLI and integration are excluding each other, you need to choose which one to use.

Config like this one should work for CLI

files:
  - "source": "some source path 1"
    "translation": "/%two_letters_code%/%original_file_name%"
    "type": "type of source 1"
    "languages_mapping": &anchor
      "two_letters_code":
        "fr": "fr-FR"
        "de": "de-DE"
  - "source": "some source path 2"
    "translation": "/%two_letters_code%/%original_file_name%"
    "type": "type of source 2"
    "languages_mapping": *anchor
4

But @tbsprs if you decide to switch to CLI, keep in mind that some time ago I was told in private conversation that it’s better to have a configuration for lang mapping in the project itself, because this CLI mapping may soon disappear and remain in project only. I have no timeline, maybe it’s even 3+ years, still…

5

Language mapping support in the crowdin.yml configuration file will not disappear.

1 Like
6

Hello all,

@DuuanVanVaagh @tbsprs

I can confirm that we don’t have any plans (at least, for now) to remove the support of language mapping in CLI.

Quite a lot of people use this feature because it creates additional advantages in cases where users want to follow the principle of configuration-as-code.

1 Like
7

Thank you for the status update.

I agree that configuration-as-code makes very much sense. No doubt here.

Regarding the usage of the web interface and CLI I would appreciate if you can make it very clear in the documentation if there are differences in the supported features. For now, I only saw project id and API token being required for CLI (alternatively they can be passed as shell parameters).

8

Thanks for you feedback. We’ll think about possible improvements on the matter.