This issue used to describe hardcoded English across the shell navigation, Context Inspector, Run Log, Diagnostics and Flow screens, and it asked for the localization guard's skip list to be removed. That work has since shipped. LocalizationSourceTest now scans every file under ui/screens instead of a hand-written list, and the seven files the old description named contain no Text("...") literals at all. Please don't go looking for those skips. They're gone.
What's left is the copy the guard structurally cannot see, because it matches on Compose call shapes like Text("...") and contentDescription = "...". Copy that reaches the screen some other way slips straight past it.
Confirmed sites
app/src/main/java/com/opentasker/ui/screens/ContextInspectorScreen.kt
:857 a status pill built as label = "Waiting for sources". It's a named argument on a helper, not a Text call, so the pattern misses it.
app/src/main/java/com/opentasker/ui/screens/ActiveAutomationViewModel.kt
:1561 and :1565 the diagnostic report share sheet. EXTRA_SUBJECT and the createChooser title are both English literals, and both are visible the moment the sheet opens.:1729 and :1733 the run source recorded as "Manual run". This one ends up in the Run Log, so it's user-visible text stored as data.:2364 and :2373 the document picker labels "Tasker XML file" and "OpenTasker bundle".
app/src/main/java/com/opentasker/core/flow/AutomationFlowStrings.kt
:141, :144, :146 and the rest of EnglishAutomationFlowStrings. The production screen calls AutomationFlowStrings.from(resources) so this is a fallback rather than a live defect, but AutomationFlowGraph still defaults its strings parameter to English. Worth checking whether any production path reaches a graph built without resources.
A note on "Manual run"
Run sources are persisted, so switching that literal to a resource lookup at the write site would leave old rows in English and translate new ones. The run log wants a stable key written to the database and the label resolved at render time. That part is a design decision, not a mechanical swap, so feel free to leave it and take the others.
What done looks like
The literals above resolve through R.string, and LocalizationSourceTest gains patterns that would catch them coming back. The current patterns are in the forbiddenPatterns map near the top of the test. Adding a label = "..." case covers most of what's listed here.
Don't widen the guard so far that it flags log messages, exception text, or internal keys. AppLogger calls and IllegalStateException messages are deliberately English and stay that way. Presentation code is also forbidden from rendering throwable text, so validation failures carry resource ids through UiRejection in UiMessages.kt rather than a message string.
Scope
One file is a perfectly good pull request, and small ones are easier to review than one large one. Comment with what you're taking so two people don't land on the same file.
Worth knowing before you start: no translations are checked in yet. res/ has values/ and values-night/ and nothing else, so this work is what makes a first translation possible rather than something that fixes a visibly broken translated build.
This issue used to describe hardcoded English across the shell navigation, Context Inspector, Run Log, Diagnostics and Flow screens, and it asked for the localization guard's skip list to be removed. That work has since shipped.
LocalizationSourceTestnow scans every file underui/screensinstead of a hand-written list, and the seven files the old description named contain noText("...")literals at all. Please don't go looking for those skips. They're gone.What's left is the copy the guard structurally cannot see, because it matches on Compose call shapes like
Text("...")andcontentDescription = "...". Copy that reaches the screen some other way slips straight past it.Confirmed sites
app/src/main/java/com/opentasker/ui/screens/ContextInspectorScreen.kt:857a status pill built aslabel = "Waiting for sources". It's a named argument on a helper, not aTextcall, so the pattern misses it.app/src/main/java/com/opentasker/ui/screens/ActiveAutomationViewModel.kt:1561and:1565the diagnostic report share sheet.EXTRA_SUBJECTand thecreateChoosertitle are both English literals, and both are visible the moment the sheet opens.:1729and:1733the run source recorded as"Manual run". This one ends up in the Run Log, so it's user-visible text stored as data.:2364and:2373the document picker labels"Tasker XML file"and"OpenTasker bundle".app/src/main/java/com/opentasker/core/flow/AutomationFlowStrings.kt:141,:144,:146and the rest ofEnglishAutomationFlowStrings. The production screen callsAutomationFlowStrings.from(resources)so this is a fallback rather than a live defect, butAutomationFlowGraphstill defaults itsstringsparameter toEnglish. Worth checking whether any production path reaches a graph built without resources.A note on
"Manual run"Run sources are persisted, so switching that literal to a resource lookup at the write site would leave old rows in English and translate new ones. The run log wants a stable key written to the database and the label resolved at render time. That part is a design decision, not a mechanical swap, so feel free to leave it and take the others.
What done looks like
The literals above resolve through
R.string, andLocalizationSourceTestgains patterns that would catch them coming back. The current patterns are in theforbiddenPatternsmap near the top of the test. Adding alabel = "..."case covers most of what's listed here.Don't widen the guard so far that it flags log messages, exception text, or internal keys.
AppLoggercalls andIllegalStateExceptionmessages are deliberately English and stay that way. Presentation code is also forbidden from rendering throwable text, so validation failures carry resource ids throughUiRejectioninUiMessages.ktrather than a message string.Scope
One file is a perfectly good pull request, and small ones are easier to review than one large one. Comment with what you're taking so two people don't land on the same file.
Worth knowing before you start: no translations are checked in yet.
res/hasvalues/andvalues-night/and nothing else, so this work is what makes a first translation possible rather than something that fixes a visibly broken translated build.