Accessibility: add internal component translations

[RasmusKjeldgaard]

Draft notes

• Setting translation from locale only happens on initialization, but added a method to update it. Is this sufficient or do we need to be reactive?
  • I guess for most of our consumers language change will not be dynamic, but instead reload another build of the application. So maybe sufficient for now?
• Thouht about providing a way to overwrite or add new translations but ended up de-scoping it

Which issue does this PR close?

This PR closes #3694 closes #942

What is the new behavior?

Does this PR introduce a breaking change?

• Yes
• No

Are there any additional context?

Checklist:

The following tasks should be carried out in sequence in order to follow the process of contributing correctly.

Reminders

• Make sure you have implemented tests following the guidelines in: "The good: Test".
• Make sure you have updated the cookbook with examples and showcases (for bug fixes, enhancements & new components).

Review

• Determine if your changes are a fix, feature or breaking-change, and add the matching label to your PR. If it is tooling, dependency updates or similar, add ignore-for-release.
• Do a self-review.
• Request that the changes are code-reviewed
• Request that the changes are UX reviewed (only necessary if your PR introduces visual changes)

When the pull request has been approved it will be merged to develop by Team Kirby.

[Fuzzy3]

Really good reflections in your draft notes ! I don't think there would be a more clean way of handling translations than this, for such a small set of translations. let's not bring out the big hammer and do reactiveness before it is actually an identified need. good PR, great scope ! ❤️

[Fuzzy3]

Don't know if destructuring is more readable 🤔

Suggested change

	const baseLocaleId = localeId.split('-')[0];
	const [baseLocaleId] = localeId.split('-');

[RasmusKjeldgaard]

In this case I think it reads a bit better that you can go "split string and take the first substring" rather than having to understand the destructuring part 🤔 So I'll leave it as is if ok.

[Fuzzy3]

Well... I guess there could be a scenario where the currentTranslation was changed to danish earlier - and then I guess we are not falling back to english. I don't think that is a likely scenario though 😆

[RasmusKjeldgaard]

Good point, I'll make it so it takes the fallback value from the activeTranslation instead 😘

[jakobe]

Great work, Raz 👌🏻

I like the scoping you've done, we can always later add support for changes to the locale 👍🏻

Maybe we can shorten the syntax a bit? I.e.
Consuming component:

constructor(
    ...,
    public translations: TranslationService
  ) {

Template binding:
[attr.aria-label]="translations.get('previousMonth')"

and then in TranslationService:

get(key: keyof Translation): string {
  return this.currentTranslation[key];
}