OpenTasker ships in 14 languages, but a translated build still shows scattered English because several secondary surfaces bypass string resources entirely. The shell navigation and top bar, the retention picker, ViewModel snackbar and toast messages, and the Context Inspector, Run Log, Diagnostics and Flow screens all have hardcoded English text.
The slightly embarrassing detail: unused resources like nav_*, empty_profiles_* and workspace_* already exist in strings.xml, waiting for exactly this. And the localization guard test deliberately skips these files, which is how the situation survived this long.
Files involved, all under app/src/main/java/com/opentasker/ui/:
screens/ActiveAutomationUi.kt and ActiveAutomationViewModel.ktContextInspectorScreen.ktRunLogScreenContent.kt and RunLogFilters.ktDiagnosticsScreen.ktAutomationFlowGraph.kt
What done looks like: text on these screens resolves through R.string, ViewModel messages carry resource IDs that get resolved at the collector, and the guard test (app/src/test/java/com/opentasker/ui/LocalizationSourceTest.kt) covers the files it currently skips.
This is a good first contribution if you know your way around Android string resources. You don't need to take all of it, one screen is a perfectly good PR, and honestly I'd rather review six small ones than one giant one. Comment which file you're taking so we don't collide.
OpenTasker ships in 14 languages, but a translated build still shows scattered English because several secondary surfaces bypass string resources entirely. The shell navigation and top bar, the retention picker, ViewModel snackbar and toast messages, and the Context Inspector, Run Log, Diagnostics and Flow screens all have hardcoded English text.
The slightly embarrassing detail: unused resources like
nav_*,empty_profiles_*andworkspace_*already exist instrings.xml, waiting for exactly this. And the localization guard test deliberately skips these files, which is how the situation survived this long.Files involved, all under
app/src/main/java/com/opentasker/ui/:screens/ActiveAutomationUi.ktandActiveAutomationViewModel.ktContextInspectorScreen.ktRunLogScreenContent.ktandRunLogFilters.ktDiagnosticsScreen.ktAutomationFlowGraph.ktWhat done looks like: text on these screens resolves through
R.string, ViewModel messages carry resource IDs that get resolved at the collector, and the guard test (app/src/test/java/com/opentasker/ui/LocalizationSourceTest.kt) covers the files it currently skips.This is a good first contribution if you know your way around Android string resources. You don't need to take all of it, one screen is a perfectly good PR, and honestly I'd rather review six small ones than one giant one. Comment which file you're taking so we don't collide.