Provide default localisations via module_name.string.yml

Thanks for the suggestion and work on this @stmh and @SolimanHarkas.

I am wondering if providing translation should be part of this module. Drupal.org already suggest a way to provide translation via PO files as described here https://www.drupal.org/community/contributor-guide/reference-information... →

Could you please list the pros and cons of doing it via *.string.yml ?

@D34dMan I'm looking for a code-based solution that allows me to manage all translations for my custom strings in a single spot. PO files split things up by language, and the Texts module uses a custom content entity, so I can't deploy it or put it in versioning. This module seems like a great fit if it were to support translations.

that is also my use case. It reduces complexity in my modules, because all initial translations are in one file.

After studying this task I see this could greatly enhance the user experience.

To move this forward here is my proposal,

1. Add support for accepting string translations via Yaml Plugin definition
2. Add support for accepting "plural" translations via Yaml Plugin Definition
3. Introduce new Translation service with a higher priority than our Default translation service, but lower than Custom String Translation servicwe, which would provide translation from Yaml definitions (for singular as well as Plural)
4. Add support to "export" translation as PO files, with options to include "custom" translation in the exported PO files or not.

Preferably Point #3 can be implemented via a sub module so that it can be turned ON/OFF as desired.