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"

[oneserv-heuser]

@niclashoyer Can you assign this issue to me please

[oneserv-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.

[oneserv-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.

[oneserv-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.