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.
*** Bug 152779 has been marked as a duplicate of this bug. ***
Hi all, I created a patch that makes the names of color schemes translatable. https://gerrit.libreoffice.org/c/core/+/145732 Basically I mapped the name used in the UI.xcu file to a translated string in the strings.hrc file. This patch assumes that future schemes shipped by LO will have a TranslateId. In case of color schemes that are not translated (such as those created by users or added by extensions), the provided name is used.
@Rafael, read over https://gerrit.libreoffice.org/c/core/+/145732 and I think it is good, this makes me happy. But, we don't really have a project managed "Light" theme. Rather the default "LibreOffice" color theme is built with default "automatic" colors that follow colors read in from the os/DE -- they can be Light or Dark depending on what user's desktop passes. So it is not "LibreOffice Light" that you've defined RID_COLOR_SCHEME_LIBREOFFICE_LIGHT I'd actually suggest that project would benefit from establishing such--so there would be three -- LibreOffice (all automatic pulling from os/DE) LibreOffice Light (fixed mark up with UX oversight) would get the new RID LibreOffice Dark (fixed mark up with UX oversight) PS - was looking for your contact info in the contributors list [1] but couldn't find it. Do you have a license statement filed? =-ref-= [1] https://wiki.documentfoundation.org/Development/Developers#L
(In reply to V Stuart Foote from comment #8) > But, we don't really have a project managed "Light" theme. > > Rather the default "LibreOffice" color theme is built with default > "automatic" colors that follow colors read in from the os/DE -- they can be > Light or Dark depending on what user's desktop passes. So it is not > "LibreOffice Light" that you've defined RID_COLOR_SCHEME_LIBREOFFICE_LIGHT Thanks for the feedback. I named it "Light" because the definition of Automatic colors was done considering that the DOCCOLOR is COL_WHITE regardless of any OS configuration. The current "LibreOffice" color scheme is static. See aAutoColors in GetDefaultColor: https://opengrok.libreoffice.org/xref/core/svtools/source/config/colorcfg.cxx?r=0aa61812#363 However, it's no problem to switch it back to "LibreOffice" only. The new option you suggested "LibreOffice (all automatic pulling from os/DE)" would be really nice to have, but AFAIK it doesn't exist yet. > PS - was looking for your contact info in the contributors list [1] but > couldn't find it. Do you have a license statement filed? I did this back in 2020... My name appears in the credits, so I guess it's just a matter of updating the Wiki. https://www.libreoffice.org/about-us/credits/
To improve my response in Comment #9, we have a few colors that are theme-dependent: APPBACKGROUND, LINKS and LINKSVISITED depend on OS theme settings. DOCCOLOR and FONTCOLOR are OS dependent when the system is using High-contrast mode. So indeed, DOCCOLOR may not be white in some circumstances.
(In reply to V Stuart Foote from comment #8) > I'd actually suggest that project would benefit from establishing such--so > there would be three -- > > LibreOffice (all automatic pulling from os/DE) > LibreOffice Light (fixed mark up with UX oversight) would get the new RID > LibreOffice Dark (fixed mark up with UX oversight) Looks tempting but would be done just for sake of creating something to match Dark, unnecessarily. The "automatic" set is far from really taking colors from the OS (although it's a goal). Dark was introduced for this reason to comply with the shortcomings. If we now add something Light, it would be either the same as Automatic or Automatic becomes 90th-like grayish. And I doubt any "UX oversight" works on all platforms (current Dark theme uses Breeze Dark colors which are define on KDE). Ultimately I'd like to have these colors added to the "LibreOffice Theme" (replacement of current Mozilla Persona), initialized with system colors if not user-defined. We should give users the freedom to have LibreOffice in pink and green (easily installed per extension). The patch is now back to the original situation not talking about Light.
(In reply to Heiko Tietze from comment #11) > Looks tempting but would be done just for sake of creating something to > match Dark, unnecessarily. With this fix we now have more freedom to name color schemes or even add new default ones in the future, knowing that their names will be translatable. I'm not certain about this, but I'd wager that the current color scheme names "LibreOffice" and "LibreOffice Dark" were chosen because we know they could not be translated. If we add the ability to have localizable color scheme names, we could rename the existing ones, f.i.: "LibreOffice" -> "Automatic" "LibreOffice Dark" -> "Dark" Which in my opinion convey better what they actually do. > Ultimately I'd like to have these colors added to the "LibreOffice Theme" > (replacement of current Mozilla Persona), initialized with system colors if not > user-defined. This is outside of the scope of this request, but I was wondering if we could bring the colors defined in "LibreOffice Themes" to the "Application Colors", allowing users to change them all from the "Application Colors" dialog. IMO it might be simpler to implement.
Rafael Lima committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/546ad5d17d3e363b75337c336cfb2b2f8acc55e3 tdf#143660 Make color scheme names translatable It will be available in 7.6.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.