Skip to content

i18n(settings): move SettingsViewModel status messages into string resources - #643

Merged
ProdigyV21 merged 1 commit into
ProdigyV21:mainfrom
ReichiMD:claude/reichimd-i18n-cleanup-7ugm8l
Sep 5, 2026
Merged

i18n(settings): move SettingsViewModel status messages into string resources#643
ProdigyV21 merged 1 commit into
ProdigyV21:mainfrom
ReichiMD:claude/reichimd-i18n-cleanup-7ugm8l

Conversation

@ReichiMD

@ReichiMD ReichiMD commented Sep 4, 2026

Copy link
Copy Markdown
Contributor

What

Same approach as #632, applied to the status and toast messages in SettingsViewModel.

Moves the hardcoded English UI strings in the Settings ViewModel into the string resource
system and adds the German values. No behaviour changes, no logic changes.

  • 90 message sites (82 distinct texts) moved from Kotlin literals to string resources —
    toasts, IPTV and Home Server status lines, catalog-pack and catalog-discovery errors,
    ARVIO Cloud sign-in/sync feedback, Trakt/Simkl/MDBList feedback
  • 2 of them reused existing resources that were already present
    (settings_waiting_for_approval, settings_cloud_pull_no_backup_toast)
  • 82 new keys added to values/strings.xml in a matching SettingsViewModel section
    (the IPTV status line needs two variants each, with and without the EPG summary)
  • German values added to values-de/strings.xml

These messages are produced outside a composable, so they are not resolved in the ViewModel.
SettingsUiState now carries a SettingsMessage — a @StringRes id plus format args, or
Raw text for platform exception messages — and SettingsScreen resolves it with
stringResource. This is the same pattern as PlayerMessage (#641) and PluginMessage
(4691412), so the rendered language follows the language selected in the app instead of the
system language of the device. The 49 context.getString(...) calls that already resolved
these same fields in the ViewModel moved over to that mechanism as well.

Why

Approved in Discord (28 Aug): "Yes try to also bring hardcoded things into this.
That has been kinda a long time bug. They dont have to be in English yea."

This benefits all 50 language folders, not just German — untranslated locales fall
back to English exactly as before.

Notes

  • Stored values and internal keys are unchanged; only rendered text is localized.
    Follows the existing pattern from LiveCategory.kt.
  • The default Stalker portal name ("Portal 1") is persisted in StalkerPortalEntry, so it
    stays English on purpose.
  • Brand and product names (Trakt, Simkl, MDBList, Xtream, Stalker, ARVIO Cloud) are left
    untouched.
  • Log messages, telemetry strings, animation labels and the raw exception texts that come
    back from repositories are out of scope; the latter are passed through as
    SettingsMessage.Raw.
  • Build and unit tests verified on the fork (testSideloadDebugUnitTest).

Created by Claude (Anthropic) on behalf of @ReichiMD.

…sources

Moves the hardcoded English toasts, status lines and inline errors produced by
SettingsViewModel into the string resource system and adds the German values.

The messages are created outside a composable, so they are not resolved in the
ViewModel: SettingsUiState now carries a SettingsMessage (a @stringres id plus
format args, or raw text for platform exception messages) and SettingsScreen
resolves it with stringResource. This mirrors PlayerMessage/PluginMessage and
keeps the rendered language tied to the app language instead of the system
language of the device.

No behaviour changes: stored values, ids and API parameters are untouched.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01QNcHMnhSphhH3y5JNVSwwS
@github-actions github-actions Bot added the area: android Changes to the Android app or Gradle build label Sep 4, 2026
@ProdigyV21
ProdigyV21 merged commit a5857ee into ProdigyV21:main Sep 5, 2026
1 check passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

area: android Changes to the Android app or Gradle build

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants