meetingPrivacySettings nests one level deeper under help.
The umbrella makes room for further help topics and allows
contextualizing which help a visible view offers. All
data-i18n references follow; no logic changes.
Name only the website-permissions icon when describing
where to change camera/mic decisions. The combined
lock-and-permissions phrasing was clunky in German and
duplicated what the icon already shows. Adjust all
translations accordingly.
Add the missing legalNotice parameter to the config table.
Describe how translations resolve keys, which markup the
renderer accepts, and how the OS-keyed help dialog works.
The privacy instructions no longer bloat the launcher card.
A "Help" button in the navbar opens them in a native dialog
(Esc, backdrop and button close it). The button only shows
for Windows users, reusing the existing OS detection.
Translations may contain <kbd>, <b> and <i> markup now. The
renderer builds nodes from a tag whitelist instead of using
innerHTML, so smuggled tags from i18n.json cannot execute.
All help texts live under meetingPrivacySettings.windows;
sibling keys for other operating systems can follow.
The launcher sentence around the room name was replaced
by a standalone instruction ("meetingText"); the room name
now sits on its own line below it.
Windows users additionally get camera/microphone
permission instructions in the launcher view. The block
reuses the existing i18n/OS detection and only appears
when translations loaded, so a failed i18n.json fetch
cannot render an empty box.
The legal notice link in the navbar was hardcoded to the
bnvb website. Deployments without that legal notice showed
a dead link to a foreign site.
Move the URL into assets/config.json (legalNotice), like
the Nextcloud and adhoc buttons. The link stays hidden
unless the entry is configured.
localStorage is scoped per origin, not per path. Multiple
jitsi-launch instances on one origin (e.g. meet.bnvb.eu/i
and /p) therefore shared one language and one theme
setting, and changing it in one instance changed it in
all others.
Prefix the language and theme keys with the app directory
derived from the page path. Each instance keeps its own
state; a root deployment gets the "/" prefix and behaves
as before. Previously saved choices reset once because
the key names change.
The favicons were hardcoded in launch.html, so
rebranding the page required editing the template.
The paths now come from the favicons block in
assets/config.json. Missing keys keep the defaults
from launch.html.
stefan.tollkuehn