DAW/daw-modul-berhtjan-cli
DAW/daw-modul-berhtjan-cli
2
0
Fork 0
Code Issues 5 Pull requests Projects Releases 1 Packages Wiki Activity Actions

render: fix out scope, use resolve_label, remove hardcoded strings #5

New issue
Open
opened 2026-05-26 04:16:12 +02:00 by michael · 2 comments
michael commented 2026-05-26 04:16:12 +02:00
Owner
Copy link

Findings

1. out created at module level

dawio.new() is called at module level, not per function call.
This prevents handle injection via sys.new(opts) which is the
intended mechanism for testability.

Fix: move local out = dawio.new() inside each render function,
or accept an optional out parameter.

2. core.resolve_label not used

render_form resolves labels manually:
group.label.de or group.label.en or group_id

dispatch.lua uses core.resolve_label for this.
render.lua should do the same -- requires adding
require("daw.berhtjan_core") at the top level.

3. Hardcoded German string

out:write("(keine Eintraege)") in render_table is hardcoded German.
Must be resolved via core.resolve_label once #2 is fixed.

Acceptance Criteria

  • out created per function call or passed as parameter
  • require("daw.berhtjan_core") added at top level
  • core.resolve_label used for all label resolution
  • No hardcoded natural language strings remain
  • Tests pass after changes
## Findings ### 1. `out` created at module level `dawio.new()` is called at module level, not per function call. This prevents handle injection via `sys.new(opts)` which is the intended mechanism for testability. Fix: move `local out = dawio.new()` inside each render function, or accept an optional `out` parameter. ### 2. `core.resolve_label` not used `render_form` resolves labels manually: `group.label.de or group.label.en or group_id` `dispatch.lua` uses `core.resolve_label` for this. `render.lua` should do the same -- requires adding `require("daw.berhtjan_core")` at the top level. ### 3. Hardcoded German string `out:write("(keine Eintraege)")` in `render_table` is hardcoded German. Must be resolved via `core.resolve_label` once #2 is fixed. ## Acceptance Criteria - [ ] `out` created per function call or passed as parameter - [ ] `require("daw.berhtjan_core")` added at top level - [ ] `core.resolve_label` used for all label resolution - [ ] No hardcoded natural language strings remain - [ ] Tests pass after changes
michael commented 2026-08-11 19:30:56 +02:00
Author
Owner
Copy link

Partially resolved as part of the 2.1 migration (v2.1.0).

Done:

  • require("daw.berhtjan_core") added at top level
  • core.resolve_label() now used for render_form()'s group label
    (with the new default_lang parameter) -- no more manual
    group.label.de or group.label.en fallback

Still open, not addressed by this migration:

  • out is still created once at module level (local out, set lazily
    in _check_sys()), not per function call or injectable via an
    opts parameter -- the original testability concern in this issue
    is unresolved. Our own tests work around this with the registry-
    reset technique (see test/test_berhtjan-cli.lua), which confirms
    the underlying limitation is still there.
  • '(keine Eintraege)' in render_table() is still a hardcoded German
    literal.

Turns out this is bigger than originally scoped: '(keine
Eintraege)' isn't the only hardcoded UI string in this repo --
dispatch/display.lua has 'Available commands:' and 'Subcommands for
...:' hardcoded in English, inconsistently (some German, some
English, no i18n layer for any of it). This is a systematic gap,
not a single string to fix, and ties into #6 and a broader question
about how translations enter the system at all (daw_error/v1's
message field is explicitly non-localized too). Left open pending
that discussion rather than patching one string in isolation.

Partially resolved as part of the 2.1 migration (v2.1.0). Done: - require("daw.berhtjan_core") added at top level - core.resolve_label() now used for render_form()'s group label (with the new default_lang parameter) -- no more manual group.label.de or group.label.en fallback Still open, not addressed by this migration: - out is still created once at module level (local out, set lazily in _check_sys()), not per function call or injectable via an opts parameter -- the original testability concern in this issue is unresolved. Our own tests work around this with the registry- reset technique (see test/test_berhtjan-cli.lua), which confirms the underlying limitation is still there. - '(keine Eintraege)' in render_table() is still a hardcoded German literal. Turns out this is bigger than originally scoped: '(keine Eintraege)' isn't the only hardcoded UI string in this repo -- dispatch/display.lua has 'Available commands:' and 'Subcommands for ...:' hardcoded in English, inconsistently (some German, some English, no i18n layer for any of it). This is a systematic gap, not a single string to fix, and ties into #6 and a broader question about how translations enter the system at all (daw_error/v1's message field is explicitly non-localized too). Left open pending that discussion rather than patching one string in isolation.
michael commented 2026-08-11 20:17:32 +02:00
Author
Owner
Copy link

Session 2026-08-11 — 2.1 migration closeout

The v2.1.0 migration resolved the label-resolution part of this issue, but the issue remains open for the work that was explicitly left unfinished.

Done in v2.1.0

  • render_form() uses core.resolve_label(label, lang, default_lang).
  • Direct .de / .en label access and the silent group-id fallback were removed.
  • Runtime errors now use daw_error/v1.

Still in scope of this existing issue

  • Make CLI output/input handles injectable per call instead of relying on the module-level lazy out instance. This must remove the need for registry/module reload tricks in tests solely to replace io.stdin / io.stdout.
  • Remove hardcoded natural-language CLI strings only through the language-resource solution tracked with #6; do not patch individual German/English literals in isolation.

Acceptance criteria remaining

  • Runtime I/O can be injected without reloading the module.
  • Tests cover injected input/output directly.
  • No hardcoded user-facing CLI strings remain once the language-resource mechanism from #6 is available.
  • Lua 5.1 and Lua 5.4 test suites remain green.
  • fragjan code . remains green.

Cross-reference: #6 owns the unresolved language-resource architecture used by the hardcoded-string part of this issue.

## Session 2026-08-11 — 2.1 migration closeout The v2.1.0 migration resolved the label-resolution part of this issue, but the issue remains open for the work that was explicitly left unfinished. ### Done in v2.1.0 - `render_form()` uses `core.resolve_label(label, lang, default_lang)`. - Direct `.de` / `.en` label access and the silent group-id fallback were removed. - Runtime errors now use `daw_error/v1`. ### Still in scope of this existing issue - Make CLI output/input handles injectable per call instead of relying on the module-level lazy `out` instance. This must remove the need for registry/module reload tricks in tests solely to replace `io.stdin` / `io.stdout`. - Remove hardcoded natural-language CLI strings only through the language-resource solution tracked with #6; do not patch individual German/English literals in isolation. ### Acceptance criteria remaining - [ ] Runtime I/O can be injected without reloading the module. - [ ] Tests cover injected input/output directly. - [ ] No hardcoded user-facing CLI strings remain once the language-resource mechanism from #6 is available. - [ ] Lua 5.1 and Lua 5.4 test suites remain green. - [ ] `fragjan code .` remains green. Cross-reference: #6 owns the unresolved language-resource architecture used by the hardcoded-string part of this issue.
Sign in to join this conversation.
No Branch/Tag specified
Branches Tags
main
v2.1.0
v1.1.5
v1.1.4
v1.1.3
v1.1.2
v1.1.1
v1.1.0
v1.0.4
v1.0.3
v1.0.2
v1.0.1
v1.0.0
v0.2.1
v0.2.0
v0.1.4
v0.1.3
v0.1.2
v0.1.1
v0.1.0
lua5.4
Labels
Clear labels   
coordination/cross-repo
Betrifft mehrere Repositories

  
coordination/needed
Benötigt Abstimmung zwischen Teams/Projekten

  
effort
large
 Großer Aufwand - mehr als 3 Sessions

  
effort
medium
 Mittlerer Aufwand - 1-3 Sessions

  
effort
small
 Kleiner Aufwand - weniger als 1 Session

  
meta/duplicate
Duplikat eines anderen Issues

  
meta/planning
Projekt-Management, Planung, Organisation

  
meta/wontfix
Wird bewusst nicht umgesetzt

  
priority
high
 Hohe Priorität - sofort bearbeiten

  
priority
low
 Niedrige Priorität - wenn Zeit vorhanden

  
priority
medium
 Mittlere Priorität - normale Bearbeitung

  
session
blocker
 Blockiert aktuelle Session - muss zuerst gelöst werden

  
session
handover
 Session-Übergabe - Dokumentation für nächste Session

  
session
next
 Für nächste Session geplant

  
status
blocked
 Blockiert durch andere Issues/Dependencies

  
status
done
 Abgeschlossen und getestet

  
status
in-progress
 Aktuell in Bearbeitung

  
status
review
 Fertig - wartet auf Review/Testing

  
status
to-go
 Bereit zum Start - keine Blocker

  
type
admin
 Administrative Aufgaben, Verwaltung

  
type
bug
 Fehler beheben

  
type
config
 Konfiguration ändern/anpassen

  
type
deployment
 Code/Services auf Server deployen

  
type
docs
 Dokumentation erstellen/aktualisieren

  
type
enhancement
 Bestehende Funktionalität verbessern

  
type
feature
 Neue Funktionalität entwickeln

  
type
handover
 Session-Übergabe-Dokumentation

  
type
infrastructure
 Server, Domains, Infrastruktur-Management

  
type
installation
 Software installieren und einrichten

  
type
maintenance
 Wartung, Cleanup, Refactoring

  
type
migration
 Daten/Services migrieren

  
type
research
 Recherche, Exploration, Konzept-Evaluation

  
type
security
 Sicherheitsbezogene Aufgaben

No labels
coordination/cross-repo
coordination/needed
effort
large
effort
medium
effort
small
meta/duplicate
meta/planning
meta/wontfix
priority
high
priority
low
priority
medium
session
blocker
session
handover
session
next
status
blocked
status
done
status
in-progress
status
review
status
to-go
type
admin
type
bug
type
config
type
deployment
type
docs
type
enhancement
type
feature
type
handover
type
infrastructure
type
installation
type
maintenance
type
migration
type
research
type
security
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
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-cli#5
No description provided.