✨ (dmk) [DSDK-1074]: Add language package management

[pvautherin-ledger]

📝 New commands ✨

• List Language Package command : already exists -> added to the sample App ✅
• Delete : Created ✅
• Create/Load/Commit command : uses a bulk APDU fetched Backend-side -> to implement on a device-action ↩️

New Device Action 🎉

• InstallLanguagePackageDeviceAction

❓ Context

• JIRA: https://ledgerhq.atlassian.net/browse/DSDK-1074

• Language Package Management Study: Confluence

• Legacy LW Implementation: LucidChart

• DMK Device Action flow : LucidChart

✅ Checklist

Pull Requests must pass CI checks and undergo code review. Set the PR as Draft if it is not yet ready for review.

• Covered by unit tests
• Changeset is provided
• Documentation is up-to-date
• Impact of the changes:
  • list of the changes : see Language Package Management Study

---

🧐 Checklist for the PR Reviewers

• The code aligns with the requirements described in the linked JIRA or GitHub issue.
• The PR description clearly documents the changes made and explains any technical trade-offs or design decisions.
• There are no undocumented trade-offs, technical debt, or maintainability issues.
• The PR has been tested thoroughly, and any potential edge cases have been considered and handled.
• Any new dependencies have been justified and documented.

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
device-sdk-ts-sample	Ready	Preview, Comment	Apr 17, 2026 8:55am

1 Skipped Deployment

Project	Deployment	Actions	Updated (UTC)
doc-device-management-kit	Ignored		Apr 17, 2026 8:55am

[github-actions]

Danger Check Results

Messages

✅	Danger: All checks passed successfully! 🎉

Generated by 🚫 dangerJS against a909faa

[sonarqubecloud]

Quality Gate failed

Failed conditions
22.2% Duplication on New Code (required ≤ 3%)

See analysis details on SonarQube Cloud

[OlivierFreyssinet]

[SHOULD] If this throws, it should be wrapped in a InstallLanguagePackageTaskError, especially because the DeviceAction makes this type assertion, even though it's incorrect.

[OlivierFreyssinet]

[SHOULD] I think we should avoid subscriber.error because then errors are of type unknown. What we could do instead is always emit those errors in the observable directly (it becomes Observable<ProgressEvent|ErrorEvent>), and like this it does not force the DeviceAction to assert unknown as *DAError

[OlivierFreyssinet]

[COULD] Overall I feel like the task could be much easier to follow if it was rewritten as an RxJS pipeline (with operators like defer, from, switchMap, catchError etc. instead of new Observable(() => {...}) wrapping the async logic in an inner function, throwing inside it and catching in then etc.

I think it's worth exploring the alternative to see if it would be a bit cleaner, but it's not a required change if you already tackle the [SHOULD] comments.

[OlivierFreyssinet]

Nice 👍
Just some things to rework regarding error flow in the install task.