There is no localisation infrastructure in the project at all (verified 2026-08-26): no intl, no flutter_localizations, no AppLocalizations, no Locale handling anywhere. A rough grep finds ~215 hardcoded English strings across lib/pages, lib/widgets and lib/editor_shared, and that understates it.
This belongs alongside #45. They are not the same requirement, but they are the same refactor: both mean walking every widget and fixing how it presents itself to a user who is not the default assumed one. Doing them in one pass is far cheaper than two, and both are near-impossible to retrofit cleanly later.
There are three distinct layers here, in increasing order of difficulty.
UI translation is the easy one — extract strings, add flutter_localizations, wire a locale. Mechanical but broad.
Bilingual map output is the commercially urgent one, and it is a label-layout feature rather than a translation feature. The Welsh Language (Wales) Measure 2011 places a statutory duty on Welsh public bodies, and the Standards require Welsh to appear first (above or to the left of English) with equal visibility and prominence. Transport for Wales is renewing station signage against exactly that. So a station label needs to carry two languages with mandated ordering and equal weight — which touches the label engine, cap metrics and collision logic, not just the string. Until this exists, A&A cannot serve any Welsh authority.
Script support is the deepest. TextDirection.ltr is hardcoded throughout the render path — text_cap_metrics.dart, glyph_span.dart, canvas_painter.dart, components/canvas_objects.dart. RTL scripts will not lay out correctly in exported maps, which rules out Arabic and Hebrew markets entirely and is a genuine ceiling on the international consumer funnel.
Worth noting the second layer is a market A&A currently cannot sell into at any price, and the third is one of the few levers that raises the consumer market ceiling rather than working within it.
There is no localisation infrastructure in the project at all (verified 2026-08-26): no `intl`, no `flutter_localizations`, no `AppLocalizations`, no `Locale` handling anywhere. A rough grep finds ~215 hardcoded English strings across `lib/pages`, `lib/widgets` and `lib/editor_shared`, and that understates it.
This belongs alongside #45. They are not the same requirement, but they are the same refactor: both mean walking every widget and fixing how it presents itself to a user who is not the default assumed one. Doing them in one pass is far cheaper than two, and both are near-impossible to retrofit cleanly later.
There are three distinct layers here, in increasing order of difficulty.
UI translation is the easy one — extract strings, add `flutter_localizations`, wire a locale. Mechanical but broad.
Bilingual map output is the commercially urgent one, and it is a label-layout feature rather than a translation feature. The Welsh Language (Wales) Measure 2011 places a statutory duty on Welsh public bodies, and the Standards require Welsh to appear first (above or to the left of English) with equal visibility and prominence. Transport for Wales is renewing station signage against exactly that. So a station label needs to carry two languages with mandated ordering and equal weight — which touches the label engine, cap metrics and collision logic, not just the string. Until this exists, A&A cannot serve any Welsh authority.
Script support is the deepest. `TextDirection.ltr` is hardcoded throughout the render path — `text_cap_metrics.dart`, `glyph_span.dart`, `canvas_painter.dart`, `components/canvas_objects.dart`. RTL scripts will not lay out correctly in exported maps, which rules out Arabic and Hebrew markets entirely and is a genuine ceiling on the international consumer funnel.
Worth noting the second layer is a market A&A currently cannot sell into at any price, and the third is one of the few levers that raises the consumer market ceiling rather than working within it.
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
There is no localisation infrastructure in the project at all (verified 2026-08-26): no
intl, noflutter_localizations, noAppLocalizations, noLocalehandling anywhere. A rough grep finds ~215 hardcoded English strings acrosslib/pages,lib/widgetsandlib/editor_shared, and that understates it.This belongs alongside #45. They are not the same requirement, but they are the same refactor: both mean walking every widget and fixing how it presents itself to a user who is not the default assumed one. Doing them in one pass is far cheaper than two, and both are near-impossible to retrofit cleanly later.
There are three distinct layers here, in increasing order of difficulty.
UI translation is the easy one — extract strings, add
flutter_localizations, wire a locale. Mechanical but broad.Bilingual map output is the commercially urgent one, and it is a label-layout feature rather than a translation feature. The Welsh Language (Wales) Measure 2011 places a statutory duty on Welsh public bodies, and the Standards require Welsh to appear first (above or to the left of English) with equal visibility and prominence. Transport for Wales is renewing station signage against exactly that. So a station label needs to carry two languages with mandated ordering and equal weight — which touches the label engine, cap metrics and collision logic, not just the string. Until this exists, A&A cannot serve any Welsh authority.
Script support is the deepest.
TextDirection.ltris hardcoded throughout the render path —text_cap_metrics.dart,glyph_span.dart,canvas_painter.dart,components/canvas_objects.dart. RTL scripts will not lay out correctly in exported maps, which rules out Arabic and Hebrew markets entirely and is a genuine ceiling on the international consumer funnel.Worth noting the second layer is a market A&A currently cannot sell into at any price, and the third is one of the few levers that raises the consumer market ceiling rather than working within it.