Description: Apple changed their System Preferences to System Settings in 2022 with the release of macOS Ventura. https://discussions.apple.com/thread/254314315 This change is reflected in all Apple apps such as Music, Safari, Pages, Numbers, ... which all had their menu bar item adjusted from "App name > Preferences…" to "App name > Settings …". Almost all macOS third-party apps have followed that change. However not LibreOffice. Steps to Reproduce: 1. Open LibreOffice on macOS 2. click on LibreOffice menu bar and Look at second menu entry Actual Results: "Preferences…" Expected Results: "Settings…" Reproducible: Always User Profile Reset: No Additional Info: This change only should affect the macOS string as for win/linux Tools > Options is used.
Acceptance up to the macOS Apple users but seems reasonable to me. +1
Sounds reasonable. Wonder if we have to translate the term or if the OS provides it. Patrick, do you want to look into this topic? Found only the suppression in solenv/bin/macosx_menubar_modification.xsl
It does seem to be the case that the AppKit menu item has changed from 'Preferences...' to 'Settings...' in recent years. However, the LibreOffice documentation refers to the 'LibreOffice - Preferences' menu item so changing it would introduce an inconsistency with the current (shared) documentation. There are plenty of other subtle UI differences between LibreOffice and a purebred macOS app, e.g. the Window menu is missing a lot of options, so my inclination would be to retain consistency with the documentation and the many existing how-to's and tutorials.
With that argument, there would never be any string changes. I don't find that convincing. There are many things changing in LibreOffice. Just recently an entire settings section (Application Colors) was replaced. Yes, the change creates overhead in documentation, but it isn't something that can not be dealt with.
(In reply to steve from comment #4) > Yes, the change creates overhead in documentation, but it isn't something > that can not be dealt with. Actually, I believe all of this change would be done by the l10n (localization) volunteers. This isn't some a developer does and I don't have any time available for coordinating this. But I think you, the users, should reach out to the l10n volunteers and figure out how you propose a change to an existing translation. I believe the "key" that the localization volunteers use for this particular string is "Preferences..." (see vcl//inc/strings.hrc). Note the three periods at the end. They don't use an ellipsis as the macOS code replaces three periods with an ellipsis just before creating a native menu item.
Heiko Tietze committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/11ecd11abab2a5f9e4779b36ca14420c644f923b Resolves tdf#165517 - Rename Preferences to Settings on macOS It will be available in 25.8.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.
I created a revert for this change. As written on IRC, *IF* this is changed to begin with, it needs to be done in help as well, and that has translator impact/should be also brought to their attention first. Then it can be decided to just silently do the change for English and keep whatever existing translation for the strings, or whether we flag the strings as to be retranslated. Also that affects documentation/guides and wiki pages, etc. A string change like this should be communicated beforehand.
Code pointer for documentation/help missing.
Christian Lohmaier committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/6686aa128eb22fefee660ca6913dec01a94741ca Revert "Resolves tdf#165517 - Rename Preferences to Settings on macOS" It will be available in 25.8.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.
codepointer for help is our helpcontent repository https://git.libreoffice.org/help and for documentation and l10n: that's more about coordination. The revert is not to indicate that the change must not happen, it is to say that at the very minimum the helpcontent also needs to be changed at the same time, and importantly also in a coordinated way, in order for translator impact to be minimal – again unclear whether translators prefer to just keep their existing translation no matter what the English string is changed to, or whether they prefer to have the string treated as an actual string change with them having to approve/retranslate each instance. As for help, most occurrences probably follow the "%PRODUCTNAME - Preferences" pattern (sometimes with emdash, sometimes regula) , but more thorough would be to look for preference in at least all switchinline statement, would affect around 330 strings or so.
In the wiki I can do it via the ReplaceText extension, targeting {{bc|LibreOffice|Preferences and then doing a second, manual pass for just Preferences in case there is stuff left.
Good call to revert change until documentation can be updated before patch is implemented. I see that it is still called "Preferences.." in MS Office as well, however a large quantity of other applications now use the newer "Settings.." including MS Edge, so good for LO to implement this change before MS at least on the Office Suite.