Created attachment 174005 [details] Untranslatable application color name string Instead of displaying the KeyID along with the English string, the new application color theme name (tdf#141986) are not transtable Step to reproduce: 1. Set language to KeyID (Tools ▸ Options ▸ Language Settings ▸ Languages, select KeyID in User Interface). To enable KeyID, install <package_name>_langpack_qtz.tar.gz from Daily Build (https://dev-builds.libreoffice.org/daily) 2. View Application Color Theme name in Tools ▸ Options ▸ LibreOffice ▸ Application Colors Version: gR8uu‖%ABOUTBOXPRODUCTVERSION%ABOUTBOXPRODUCTVERSIONSUFFIX / LibreOffice Community Build ID: f107e6893491bdf9e9bd1a8620218640ea76095a CPU threads: 4; OS: Linux 5.8; UI render: default; VCL: kf5 (cairo+xcb) Locale: id-ID (id_ID.UTF-8); UI: qtz TinderBox: Linux-rpm_deb-x86_64@86-TDF, Branch:master, Time: 2021-07-30_09:21:51 Calc: threaded
confirm in Version: 7.3.0.0.alpha0+ (x64) / LibreOffice Community Build ID: cb2827f5f65324f309fa0e3c30d0b19ad237410e CPU threads: 8; OS: Windows 10.0 Build 19042; UI render: Skia/Raster; VCL: win Locale: ru-RU (ru_RU); UI: en-US Calc: CL There is no designation of a dark and light theme, it is not translated in any way when choosing any interface language.
The color scheme is stored in officecfg/registry/data/org/openoffice/Office/UI.xcu with no access to string variables. Adding l10n support would be some effort and a very special handling. Actually, the patch was rather a hack than a proper solution and I would prefer to revert in favor of an extension. It was possible in the past [1] but doesn't work out of the box. Will have to take a closer look. But ultimately we should consider a more general solution, see bug 125217 and bug 120406. What I imagine is a theme per extension including all colors with or without gradients and background images. [1] https://forum.openoffice.org/en/forum/viewtopic.php?f=16&t=38465
(In reply to Heiko Tietze from comment #2) > I would prefer to revert in favor of an extension. Such a big no. A dark variant nowadays is a must. Dark-light couple now become a new standard for many applications. While in other hand I am fully agree if LibO provide a support to make color support an extension. Please keep the dark color there.
(In reply to Rizal Muttaqin from comment #3) > (In reply to Heiko Tietze from comment #2) > > I would prefer to revert in favor of an extension. > > Such a big no. A dark variant nowadays is a must. Dark-light couple now > become a new standard for many applications. While in other hand I am fully > agree if LibO provide a support to make color support an extension. Please > keep the dark color there. Yes even if we were to move to extension--the framework for the GUI to fully respond to our own themes would still be needed. Meaning, still fully appropriate for LO to provide its own light/dark theme support internally with no linkage to os/DE theme. Another example, the Notepad++ project folks just implemented a very nice Dark mode at their 8.1.3 release. Joining GIMPs UI themes (Dark, Grey, Light, & System) and Inkscape with its 'Use dark theme' setting for UI modes out of the box. LibreOffice Dark is a great start--we need to finish off the framework to fully specify the Application Colors with or without os/DE themeing.
Removing UX keyword as the request received acceptance and is at least a step forward.