[i18n] Add new consolidation global i18n module

[wax911]

AniTrend Issue Guidelines

Before opening a new issue, please take a moment to review our community guidelines to make the contribution process easy and effective for everyone involved.

You may find an answer in closed issues:
https://github.com/AniTrend/anitrend-v2/issues?q=is%3Aissue+is%3Aclosed

Feature Information

Objective: Consolidate global string resources, plurals, and locale-aware formatting into a dedicated common:i18n module for cross-feature reuse and consistent localization.

Goals

• Provide a single source of truth for global/localized strings used across modules.
• Enable modular consumption: features depend on common:i18n instead of scattering strings.
• Support Compose and View usage with standard Android resources and helper APIs.

Scope

• Move common strings (generic labels, common section titles, button texts) into common:i18n.
• Keep feature-specific copy in their respective modules to avoid tight coupling.
• Provide utility helpers for date/time/currency formatting if needed later (out of initial scope).

Module Layout

common/i18n/
  build.gradle.kts
  src/main/res/values/strings.xml
  src/main/res/values-*/strings.xml (localized variants)
  src/main/kotlin/co/anitrend/common/i18n/
    Compose.kt (optional composables/extensions)
    Strings.kt (optional typed accessors)

Adoption Plan

1. Create the common:i18n module and add it to settings.gradle.
2. Seed it with baseline global strings:
   • Rankings title, generic actions (OK/Cancel), etc.
3. Incrementally migrate strings:
   • When touching a feature, move eligible global strings.
   • Replace usages: stringResource(co.anitrend.common.i18n.R.string.xxx).

Guidelines

• Global vs Feature:
  • If text appears across multiple modules/screens or is domain-agnostic → i18n.
  • If text is tightly coupled to a feature’s domain → keep in feature module.
• Naming:
  • Use descriptive, stable names; avoid module-specific prefixes in i18n.
• Plurals:
  • Prefer plurals for countable text; provide singular/other.

Risks & Mitigations

• Large initial migration effort → adopt incremental approach.
• Resource ID churn → maintain stable keys; deprecate old keys gradually if needed.
• Build graph complexity → keep i18n dependency as low-level common to avoid cycles.

Open Questions

• Do we centralize date/time formatting utilities here or in android:core? (Recommend: keep in core; i18n focuses on strings.)
• Should we provide typed wrappers for common strings to reduce raw ID usage? (Optional.)

Done Criteria (Phase 1)

• i18n module exists with baseline strings and is consumable from a feature.
• At least one feature updated to read a string from i18n.
• Documentation updated for contribution guidelines on string placement.