Summary

Several user-facing strings introduced in v0.7.38 (and at least one older one) are not localizable: some are referenced via intl.t() but missing from en-us.yaml, and some are hardcoded in templates without going through the i18n path at all. The result is that on any non-en locale (e.g. uz-uz), the sidebar and the new map/routing settings pages show literal Missing translation "..." strings or remain stuck in English even when surrounding labels translate correctly.

This is not a regression of the locale machinery — locale resolution works fine for keys that exist. It's purely missing keys / unwrapped strings.

Affected strings

Group A — Hardcoded (no intl.t() call)

Found at /fleet-ops/settings/routing:

• "Routing Optimization Engine" — the label above the second dropdown
• "Choose which engine should optimize stop order before the route is rendered." — the helper description directly below it

For comparison, the sibling "Routing Service" label on the same page is properly translated via intl.t(). So these two strings appear to have been added without going through the i18n path.

Group B — Missing YAML keys (referenced via intl.t() but undefined)

These keys are called from frontend code but are absent from console/translations/extensions/fleetops-engine/en-us.yaml. With a non-en locale they render as literal Missing translation "<key>" for locale "<locale>":

$ grep -E '^  map:|settings.map' \
    console/translations/extensions/fleetops-engine/en-us.yaml
# (no output for any of the keys above)

Reproduction

1. Install v0.7.38
2. Run console with any non-en locale (e.g. uz-uz)
3. Open /fleet-ops — sidebar shows Missing translation "menu.map" for locale "uz-uz"
4. Click that link → navigates to /fleet-ops/settings/map where the page title, section heading, dropdown label, and help text all render as Missing translation "settings.map.*"
5. Open /fleet-ops/settings/routing — "Routing Optimization Engine" / "Choose which engine should optimize..." remain English even when the surrounding labels render in the user's locale

Suggested fix

For Group B (missing YAML keys): add the following to console/translations/extensions/fleetops-engine/en-us.yaml:

menu:
  # ... existing keys
  map: Map

settings:
  map:
    fleet-ops-map-settings: Fleet-Ops Map Settings
    configure-map: Configure Map
    map-provider: Map Provider
    map-provider-help-text: Choose how the map is rendered (tile provider).

For Group A (hardcoded strings): wrap the two /fleet-ops/settings/routing strings in {{t "..."}} (or intl.t in JS) and add corresponding YAML keys, e.g. under routing-settings:. The page already has working translations for "Routing Service" / "Distance Unit" / "Configure Routing", so these two are outliers.

Workaround for downstream consumers

Group B keys can be worked around in a downstream <locale>.yaml because of Ember's locale fallback chain (<locale> → en-us → key string). For example, adding menu.map: Harita to uz-uz.yaml recovers the missing sidebar label.

Group A strings cannot be localized downstream without patching engine assets, since they don't go through intl.t() at all. These need an upstream fix.

Environment

• Fleetbase: v0.7.38
• @fleetbase/fleetops-engine@0.6.46
• Locale tested: uz-uz (consistent for any non-en locale)
• All keys above were absent from the en-us yaml as of v0.7.38