feat(lang): resolve fallback language from config, not hardcoded #10

Closed
opened 2026-06-02 07:25:43 +02:00 by michael · 1 comment
Owner

Problem

resolve_lang() currently falls back to hardcoded "en" when no locale
is found in ctx. This is a silent assumption that may not match the
operator's intent.

Background

Language resolution belongs in the wrapper/config layer, not in the
module. The module takes what ctx provides. A default fallback language
should come from config (e.g. fragjan.conf or the host project config),
not be hardcoded.

Current behaviour

function M.resolve_lang(ctx)
  if ctx and ctx.user_locale then
    return ctx.user_locale:match("^([a-z]+)") or "en"
  end
  if ctx and ctx.lang then return ctx.lang end
  return "en"  -- hardcoded fallback
end

os.getenv() calls were removed in the same cleanup pass (DAW/daw-modul-berhtjan-core#8).

Required changes

  • Define fallback language in config (host project or fragjan.conf)
  • Pass resolved fallback into ctx before calling resolve_lang()
  • resolve_lang() should not need a hardcoded default

Context

Part of the broader i18n topic which needs a dedicated design pass.
This issue tracks the specific resolve_lang() gap only.

Acceptance criteria

  • Default fallback language comes from config, not hardcoded
  • resolve_lang() has no hardcoded language string
  • ctx contract documented (ctx.lang, ctx.user_locale)
## Problem resolve_lang() currently falls back to hardcoded "en" when no locale is found in ctx. This is a silent assumption that may not match the operator's intent. ## Background Language resolution belongs in the wrapper/config layer, not in the module. The module takes what ctx provides. A default fallback language should come from config (e.g. fragjan.conf or the host project config), not be hardcoded. ## Current behaviour ```lua function M.resolve_lang(ctx) if ctx and ctx.user_locale then return ctx.user_locale:match("^([a-z]+)") or "en" end if ctx and ctx.lang then return ctx.lang end return "en" -- hardcoded fallback end ``` os.getenv() calls were removed in the same cleanup pass (DAW/daw-modul-berhtjan-core#8). ## Required changes - Define fallback language in config (host project or fragjan.conf) - Pass resolved fallback into ctx before calling resolve_lang() - resolve_lang() should not need a hardcoded default ## Context Part of the broader i18n topic which needs a dedicated design pass. This issue tracks the specific resolve_lang() gap only. ## Acceptance criteria - [ ] Default fallback language comes from config, not hardcoded - [ ] resolve_lang() has no hardcoded language string - [ ] ctx contract documented (ctx.lang, ctx.user_locale)
Author
Owner

Resolved as part of the 2.1 migration (v2.1.0).

lang.resolve_lang(ctx) no longer contains any hardcoded fallback
language. The resolution chain is now: ctx.user_locale ->
ctx.lang -> daw_error/v1 (no_language_resolvable). The host/adapter
resolves any default and puts it into ctx.lang before calling --
lang.lua itself invents nothing.

resolve_label() received the same treatment: a new default_lang
parameter (sourced from ctx.default_lang by callers), no hardcoded
'en', and no nondeterministic pairs() fallback either.

Resolved as part of the 2.1 migration (v2.1.0). lang.resolve_lang(ctx) no longer contains any hardcoded fallback language. The resolution chain is now: ctx.user_locale -> ctx.lang -> daw_error/v1 (no_language_resolvable). The host/adapter resolves any default and puts it into ctx.lang before calling -- lang.lua itself invents nothing. resolve_label() received the same treatment: a new default_lang parameter (sourced from ctx.default_lang by callers), no hardcoded 'en', and no nondeterministic pairs() fallback either.
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
DAW/daw-modul-berhtjan-core#10
No description provided.