Consume server-resolved translations for server-provided strings#1911
Open
marcelveldt wants to merge 2 commits into
Open
Consume server-resolved translations for server-provided strings#1911marcelveldt wants to merge 2 commits into
marcelveldt wants to merge 2 commits into
Conversation
The frontend kept its own copy of translatable strings for objects the server provides (config entries, media item names, genres, recommendations, browse folders) and resolved them locally. The server now resolves these for the connection locale and sends them already localized, so consume those values directly and stop resolving the keys client-side. - Render server-resolved label/description/option title/category_label/name instead of looking them up via vue-i18n. - Send translations/set_locale on connect and on UI language change, then refresh state so server-provided strings re-resolve (also covers the Ingress path where the auth command is skipped). - Pre-translate the frontend-only settings entries locally; those stay frontend-owned. - Remove the now-dead server-object keys from the locale files. - Update getGenreDisplayName tests for the server-resolved behaviour.
17 tasks
- Remove the now no-op getGenreDisplayName helper and inline genre names to item.name (names are resolved server-side), which collapses the genre special-casing in the listview, info header and editorial cards. - Inline the folderTitle passthrough to folder.name. - Drop the ConfigEntry translation_key/translation_params/category_translation_* fields from the interface: the server no longer sends them and nothing reads them (the media/option/task translation keys stay, still used client-side). - Reword the migration comments to describe current behaviour.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The frontend kept its own copy of translatable strings for objects the server provides — config-entry labels/descriptions/option titles, config categories, media item names, genres, recommendations and browse folders — and resolved them locally via vue-i18n. The server now resolves these server-side and sends them already localized, so the local copies are dead and the lookup logic is redundant.
This migrates the frontend to consume the server-resolved values, leaving only genuinely UI-owned strings in the locale files.
Changes
label/description/optiontitle/category_label/namedirectly instead of looking them up via vue-i18n.translations/set_localecommand on connect and whenever the UI language changes, then refresh state so server-provided strings re-resolve (works on the Ingress path too, where theauthcommand is skipped).recommendations.*,genre_names.*, and the migrated config-entry keys); only frontend UI strings remain.Note: genre descriptions and browse-folder titles stay client-side for now and are a follow-up.
Companion PRs: