Fix locale inconsistencies and German survey launch

[CCuskley]

Proposed changes

• Updated German locale to full four letter de-DE code throughout, changing languageOptions key from de to de-DE in i18n.ts in languageOptions and baseMessages
• Changed UI option from Deutsch to Deutsch (Deutschland)
• Created a shared locale helper, findBestMatchingLocale() in i18n.ts. Pulls values from languageOptions rather tahn using hardcoded language codes, uses exact locale match if available (e.g., de-DE -> de-DE), falls back to closest match for incomplete or prefix-match only locales (e.g., de -> de-DE, es-MX->es-CO). Falls back to en-US if no match.
• Updated sessionStorage key to prevent fallback reliably to browserLocale
• Simplified getParsedLocale() in survey.ts to call findBestMatchingLocale() from i18n.ts rather than hard coding language codes.

Types of changes

What types of changes does this pull request introduce?

• Bugfix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• Refactor (non-breaking change that does not add functionality but makes code cleaner or more efficient)
• Tests (new or updated tests)
• Styles (changes to code styling)
• CI (continuous integration changes)
• Other (please describe below)

Additional Notes

[github-actions]

Visit the preview URL for this PR (updated for commit 02fc40b):

https://hs-levante-admin-dev--pr810-fix-full-language-co-muyup727.web.app

_{(expires Thu, 19 Feb 2026 15:59:56 GMT)}

_{🔥 via Firebase Hosting GitHub Action 🌎}

_{Sign: 7889bff1da3bcc333d7422b9fc863c65b3962be7}

[digital-pro]

I think the code itself is fine. I wyorry about two things:

• Existing users with locale either en or de, and making sure they migrate gracefully.
• Task audio is stored under en and de, so some combination of @CCuskley and @zwatson2001 need to decide if it will still work. We should almost certainly rename those folders (like we did es to es-CO), but that will in turn require some updates to _translations.

[CCuskley]

I think the code itself is fine. I wyorry about two things:

* Existing users with locale either en or de, and making sure they migrate gracefully.

* Task audio is stored under en and de, so some combination of @CCuskley and @zwatson2001 need to decide if it will still work. We should almost certainly rename those folders (like we did es to es-CO), but that will in turn require some updates to _translations.

I think the new findBestMatchingLocale() helper should resolve the first problem: if a user has a locale like en, it will resolve to en-US; de will resolve to de-DE. This is generalised so e.g., es falls back to es-CO; when pt-BR comes, pt-PT would resolve to pt-BR etc etc. Basically if it's only a two letter code it looks for the best match.

But that's only dashboard side - I think this shouldn't affect tasks themselves because the variant sets the language code, but will confirm with @zwatson2001. Even if it does set the language code separately, we want to make sure it matches the dashbaord one.

[fhconte]

LGTM