Migrate frontend translations from `solidus_core` to `solidus_starter_frontend`

[rainerdema]

Desired Behavior

All translations used by the starter frontend reside in solidus_core: This creates challenges during the development of the starter, as each time a translation key needs to be added, a dedicated PR in solidus is required.

Moreover, it's not consistent to have these translations in the core: They should be part of the frontend, which will then be copied into the host after installation, allowing the possibility to make changes if needed.

The plan is to conduct this transition in different stages across both repositories and:

1. Move all the deprecated translations in core to a separate locale files (e.g. solidus/core/config/locales/en.deprecated.yml).
2. Copy the file to the host application as part of the solidus installation/upgrade process.
3. In the next major release, remove the deprecated file from solidus_core and relocate it to solidus_starter_frontend.

For more details, see this conversation: https://github.com/solidusio/solidus_starter_frontend/pull/348#discussion_r1250583682

Current Behavior

Currently, any addition or change to translations requires a new pull request in solidus, as all translation keys used by the starter frontend are located in solidus_core.

Additional notes

Consider this specific key, which hasn't been added to solidus_core to avoid the needless inclusion of another key that would subsequently need to be removed: https://github.com/solidusio/solidus/pull/5208 This key will be among those directly inserted into the solidus_starter_frontend.

[fthobe]

@jarednorman can be closed

[benjaminwil]

Why was this closed? I don't see any translations in the starter frontend. Did we change strategies here?

[fthobe]

Because it's stale. If somebody wants to do this I can provide a list of all strings. I think there's a lack of demand, the starter front-end has very few strings and from what I saw many in the translation file are currently unused or used in the Admin interface but removal could cause problems for older installations. @jarednorman @kennyadsl @tvdeyen is that something you want to follow through with or did you have anything particular in mind?

[kennyadsl]

Reopening, this is not done and despite at the moment it's not a priority for anyone willing to contribute, it's helpful to keep it open to track this thing to do.

[fthobe]

@kennyadsl i can see a lot of sense in this issue thinking about it. If you people provide a guide we can slip it in.

[jarednorman]

Sorry, didn't look closely enough at this before closing.

[fthobe]

@kennyadsl so the desired outcome here is too have all translations that are frontend solely in the frontend, correct?

[benjaminwil]

Yeah!

[fthobe]

ok, I'd say we can do that.

[fthobe]

@benjaminwil @MadelineCollier is there any clear separation in the new admin of what is needed where? I looked at this and I feel this becomes dramatically easier when the new admin is done if we clean strings there and in starter and throw afterwards everything out that's not needed.