add translation for weekdays

[jonathan-martz]

"Monday","Montag" "Tuesday","Dienstag" "Wednesday","Mittwoch" "Thursday","Donnerstag" "Friday","Freitag" "Saturday","Samstag" "Sunday","Sonntag" "Mo","Mo" "Tu","Di" "We","Mi" "Th","Do" "Fr","Fr" "Sa","Sa" "Su","So" "Mon","Mo" "Tue","Di" "Wed","Mi" "Thu","Do" "Fri","Fr" "Sat","Sa" "Sun","So"

[t-heuser]

@niclashoyer Can you assign this issue to me please

[t-heuser]

@niclashoyer Are there already any strings in the de_DE.csv file which are not generated by the check_new.php script?

If not I'd suggest to keep it like that and create a new package which we can call something like additional Locale Pack and add that as suggestion to the composer.json.

If we'd do it like that we would have a "clean" translation package and simultaneously an additional package where we can add any strings which are not directly used by Magento but commonly used (like weekdays, etc.).

[niclashoyer]

Yes, we already have some translations for popular modules like Amasty_Cart oder Amasty_GdprCookie which should be separated. I think we'd need to extend check_new.php to recognize this, as Magento will spit out any strings to translate from all extensions that are installed where the command php bin/magento i18n:collect-phrases -m is run.

This may be in line with #190, so we need to decide if we can and want to provide several versions of the language pack from this repository (which would need a more sophisticated deployment process) or if we split it up.

[t-heuser]

I think it would be more convient to have one repository and merge files via a deployment process. I think it would be way less maintenance effort.

This approach would result in 4 version:

• Magento Base Formal
• Magento Base Informal
• Additional Formal
• Additional Informal

The only problem I see here is that the deployment process could lead to errors when merging the files. And I have no clue how to create 4 different packages on packagist from 1 repository 😄

[niclashoyer]

I think it is discouraged by composer/packagist, a workaround may be to just have repositories as package-placeholders that this repo pushes into. Or maybe it is possible to release in different branches. But I don't know how that works with tags then.

[t-heuser]

I guess the best would be to have package placeholder repositories. So that means there would be 5 repos, 1 of them the main repo where the work happens and the other 4 are published to packagist and automatically released by a deployment process.

Sounds reasonable to me. And like a lot of work to do.