Having support for anything but neutral cultures takes us far into YAGNI-land, so we change the name of "cultureCode" to "languageCode" and start normalizing inputs to culture-neutral two/three letter ISO-639 codes.
We should continue to accept culture specific inputs (en_GB, en_US, en-GB, en-US), but should always normalize this (in the database) as a culture neutral code (ie. en).
This is a breaking change. There should not be made any attempts to convert existing data in the database.
### Tasks
- [x] Rename cultureCode to languageCode in localizationset
- [x] Change normalization to always store culture-neutral codes
- [ ] Add e2e-test
### Threat modelling
- [x] Does this change introduce any potential security issues? No
Acceptance criteria
GIVEN a service owner creating a dialog with localization sets
WHEN a localization set contains a culture specifc language code (eg. "en_US" or "en-US")
THEN the code should be normalized to its culture neutral code (eg. "en") and stored as such in the database
Introduction
Having support for anything but neutral cultures takes us far into YAGNI-land, so we change the name of "cultureCode" to "languageCode" and start normalizing inputs to culture-neutral two/three letter ISO-639 codes.
Description
See discussion on https://altinndevops.slack.com/archives/C06FTKW146B/p1715858314202269?thread_ts=1715770039.305999&cid=C06FTKW146B
We should continue to accept culture specific inputs (en_GB, en_US, en-GB, en-US), but should always normalize this (in the database) as a culture neutral code (ie. en).
This is a breaking change. There should not be made any attempts to convert existing data in the database.
Acceptance criteria
GIVEN a service owner creating a dialog with localization sets WHEN a localization set contains a culture specifc language code (eg. "en_US" or "en-US") THEN the code should be normalized to its culture neutral code (eg. "en") and stored as such in the database