Recently, I started and quit writer twice within the space of about two hours. The first time, Writer started as expected, and correctly launched with English. The second time, I was informed that updates were installing. Once updates completed and Writer launched, it was in Filipino. Due to my lack of knowledge of Filipino, this is making it rather impossible to reset my language to English - especially as I cannot find any mechanism in the safe-mode restart to change language, nor are there robust picture references for changing the language, and any attempt to use a translation tool fails due to drop-downs closing on loss of focus. My current install is Windows 11 Pro, Version 10.0.22631 Build 22631. Writer has been functioning on this system since August without any issues. The system's default language is English(US).
Clear (either delete/rename [1]) the user profile, found at: C:\Users\<Your_username>\AppData\Roaming\LibreOffice Should clear with a new profile as built with defaults (i.e. detecting your en-US default locale). =-note-= [1] rename if you have anything of substance you need to dig out (e.g. dictionaries, color palettes, etc.), otherwise just delete and use a new profile
Deleting the app data does not seem to clear the issue for me. My guess, though I can't really check, is that it's possible a push to Filipino localization has caused an issue. But I have no sight into that, no clue what got updated, and no evidence in the published change log. The build reports as 48a6bac (the Nov 8th tag release) The locale reports as "en-US (en_US); UI: tl-PH" which suggests that it's recognizing my region settings, but setting the UI to standard Tagalog. Is it possible that an update to another component has impacted it? I'm not familiar with packaging for Windows, only for Linux, so I'm uncertain what would trigger it to update itself.
[Automated Action] NeedInfo-To-Unconfirmed
confirmed by see also bug 164264 both seem to follow a MAR incremental update.
Please zip and post content from your user profile "Updates" folder, found here: C:\Users\<username>\AppData\Roaming\LibreOffice\4\Updates We need the updating.log as well as the 0\update* sub folder.
Unfortunately, I needed Libreoffice for work, and had to do a clean install two days ago. If you can provide the MSI for the pre-"MAR inremental update" version, I would be willing to cleanly install from that point, and attempt to trigger the bug again. I don't know enough to build from source for a Windows target nor on a Windows system, so I can't generate appropriate install media myself.
I would note, my reinstall has not hit this issue again, and was performed with the 24.8.3 version from the main Libreoffice website two days ago. My language/localization are US English, and my installs were both default installs - that is, both this install of Libreoffice and the prior install which exhibited the bug were installed using the defaults, and not a custome install.
(In reply to Daniel Sutton from comment #6) > Unfortunately, I needed Libreoffice for work, and had to do a clean install > two days ago. > > If you can provide the MSI for the pre-"MAR inremental update" version, I > would be willing to cleanly install from that point, and attempt to trigger > the bug again. I don't know enough to build from source for a Windows target > nor on a Windows system, so I can't generate appropriate install media > myself. Thank your for offering to have another go. You can grab the release builds from the archive at: https://downloadarchive.documentfoundation.org/libreoffice/old/ You might start with a clean install of the 24.8.0.3 .msi (i.e. fully remove current install, clean the windows registry--regedit.exe and search for LibreOffice|TheDocumentFoundation--and delete your user profile). Then see if it replicates the error as the MAR incrementals are applied. We're looking for the MAR logs to see where/if the patching goes sideways. And it may not be repeatable as you update to 24.8.3.1 or 24.8.3.2--don't think the 24.8.4.1 incremental has posted.
Don't think this will be bibisect able, especially if issue is within the MAR incremental patching. Going to require log traces and some insight as to how the tl-PH locale is asserting on upgrade.
(In reply to Daniel Sutton from comment #6) > If you can provide the MSI for the pre-"MAR inremental update" version, I > would be willing to cleanly install from that point, and attempt to trigger > the bug again. I don't know enough to build from source for a Windows target > nor on a Windows system, so I can't generate appropriate install media > myself. For my report (bug 164264) I've been to consistently reproduce the problem using the installer for 24.8.2 available on the website: https://download.documentfoundation.org/libreoffice/stable/24.8.2/win/x86_64/LibreOffice_24.8.2_Win_x86-64.msi
(In reply to Andrea from comment #10) > (In reply to Daniel Sutton from comment #6) > > If you can provide the MSI for the pre-"MAR inremental update" version, I > > would be willing to cleanly install from that point, and attempt to trigger > > the bug again. I don't know enough to build from source for a Windows target > > nor on a Windows system, so I can't generate appropriate install media > > myself. > > For my report (bug 164264) I've been to consistently reproduce the problem > using the installer for 24.8.2 available on the website: > https://download.documentfoundation.org/libreoffice/stable/24.8.2/win/x86_64/ > LibreOffice_24.8.2_Win_x86-64.msi Thanks Andrea. So Steps to Reproduce are: 1. clean off old install and registry 2. install fresh with the LibreOffice_24.8.2_Win_x86-64.msi 3. start LibreOffice, and receive a MAR incremental update cycle 24.8.2.1 -> 24.8.3.1 -> 24.8.3.2 4. on restart locale is your it-IT but UI lang has shifted from en-US to tl-PH (see attachment 198032 [details]) as logged in zip updates folder attachment 198043 [details]
(In reply to V Stuart Foote from comment #11) > Thanks Andrea. So Steps to Reproduce are: Stuart, just to clarify: Were you able to reproduce the issue for yourself with Andrea's recipe? (I wasn't myself, at least not yet.)
(In reply to Stephan Bergmann from comment #12) > (In reply to V Stuart Foote from comment #11) > > Thanks Andrea. So Steps to Reproduce are: > > Stuart, just to clarify: Were you able to reproduce the issue for yourself > with Andrea's recipe? (I wasn't myself, at least not yet.) No likewise to you, unable to confirm those STR, if Andrea agrees they're correct (I am still hung up with issues of bug 164241). But given bug 164264, the UI flipping over to tl-PH just seems too specific to not be a MAR patching issue. Just doing a uninstall/deep registry clean up of my hung 24.8.2.1 and will install from 24.8.0.3 and allow MAR to update--and see where I end up at that point.
Created attachment 198089 [details] UI selector includes default en-US and a Tagalog entry OK, can confirm an issue. Performed a full removal, then installed the 24.8.0.3 release build. Ran as admin and MAR updates proceeded 24.8.1.1 --> 24.8.1.2 --> 24.8.2.1 --> 24.8.3.1 --> 24.8.3.2 On launch as normal user, set Tools -> Options -> User data, and then checked Tools -> Options -> Languages and Locales -> General where the 'User Interface' lb includes expected default 'English (USA)' but also 'Tagalog'! And my selection is Weird in that by preference--during the core install with .MSI, in config panels I remove all Dictionaries but English (US) and all User Interface languages but English (US), and also remove the Non-linear Problem solving bundled extension. I do see we backported Tagalog to 24.8 (24 Oct 2024) with https://gerrit.libreoffice.org/c/core/+/175488 Is that additional UI language somehow tripping up the MAR update, when a new UI enum entry after program configuration. And maybe compounded for locale where en-US is not default. Version: 24.8.3.2 (X86_64) / LibreOffice Community Build ID: 48a6bac9e7e268aeb4c3483fcf825c94556d9f92 CPU threads: 8; OS: Windows 10 X86_64 (10.0 build 19045); UI render: Skia/Vulkan; VCL: win Locale: en-US (en_US); UI: en-US Calc: CL threaded P.S. with this clean removal and reinstall issue of bug 164241 did resolve.
(In reply to V Stuart Foote from comment #14) > On launch as normal user, set Tools -> Options -> User data, and then > checked Tools -> Options -> Languages and Locales -> General where the 'User > Interface' lb includes expected default 'English (USA)' but also 'Tagalog'! > And my selection is > better finish that thought... And my selection is 'English (USA)' but the lb shows the install has a 'Default - English (USA)' while Andrea got a 'Default - Tagalog' (attachment 198034 [details]) after MAR update of her custom 'English (UK)' and it-IT locale setup.
*** Bug 164264 has been marked as a duplicate of this bug. ***
*** Bug 164291 has been marked as a duplicate of this bug. ***
@vsfoote do you need more specific steps/details/logs/things on my part?
(In reply to Andrea from comment #18) > @vsfoote do you need more specific steps/details/logs/things on my part? I think we're set. Issue looks to be the backport of the Tagalog UI into the 24.8 branch between 24.8.2 and 24.8.3 releases. Seems at odds with the core MSI installer, and the incremental patching provided via MAR. May take a bit to identify a fix--but the appropriate devs are aware, meanwhile it seems that the UI selector (Tools -> Options) [1] does work to allow you to restore your expected UI language. Folks landing here should check that. It is a cosmetic, but scary, UI annoyance. =-ref-= [1] main menu 'Mga tool' -> 'Mga Pagpiplian' to open dialog then -> 'Mga Wika at Lokal' -> 'Heneral' and the 'Wika Ng' "User interface" list box.
So clean administrators priv msiexec.exe install with the 24.8.3.1 package. The MS Installer panel shows the 'Tagalog' UI language available. On launch as admin, MAR update runs but fails with this in the 0\update.log 2024-12-12 11:56:07-0500: EXECUTE PATCH share/registry/res/registry_tl.xcd 2024-12-12 11:56:07-0500: LoadSourceFile: destination file size 707136 does not match expected size 707134 2024-12-12 11:56:07-0500: LoadSourceFile failed 2024-12-12 11:56:07-0500: ### execution failed And this install is stuck at 24.8.3.1 build, with MAR update failing subsequent attempts. Version: 24.8.3.1 (X86_64) / LibreOffice Community Build ID: 65412f067af443213e726c93f137ccc85c9a1e06 CPU threads: 8; OS: Windows 10 X86_64 (10.0 build 19045); UI render: Skia/Vulkan; VCL: win Locale: en-US (en_US); UI: en-US Calc: CL threaded Working with the 24.8.3.1 build, In the Tools -> Options -> Languages and Locales -> General panel the Language of 'User interface:' shows my expected "Default - English (USA)" but *still* includes a lb entry for "Tagalog" which I had explicitly left excluded during MSI install. Suggests the new Tagalog UI offering, and its backport may be incomplete?
(In reply to V Stuart Foote from comment #20) > The MS Installer panel shows the 'Tagalog' UI language available. > But I was sure to leave it unchecked when configuring the initial install. So for it to show up in the lb of UI languages after the install is an issue, and then ending as Default language for some users (non en-US locale) is worse.
I'm not confident I've been clearing registry entries - windows really is not my forte. Do you still need me to try and recreate this issue, or do you have sufficient information to identify next steps?
(In reply to Daniel Sutton from comment #22) > I'm not confident I've been clearing registry entries - windows really is > not my forte. Do you still need me to try and recreate this issue, or do you > have sufficient information to identify next steps? Think we're good. Believe you've now installed the 24.8.3.2 build .MSI--so you'll bypass this MAR issue, just keep an eye on it when the MAR updates to 24.8.4.1/.2 apply. Thanks for posting the issue!
Just did a removal and clean up and custom install from the 24.8.3.2 build .MSI package. For custom install *only* selected 'English (United States)' and verified the 'Tagalog' entry was unchecked. But, even here (i.e. no MAR patching) seeing same issue of the 'Tagalog' entry for UI language appearing in the Tools -> Options -> Languages and Locales -> General panel's Language "User interface" list box. So really suggests issues with addition of Tagalog (tl) UI language and Help pack and [1] its backport to 24.8 [2] To check, I did another removal and clean up of 24.8.3.2 and then installed the 25.2.0.1beta1 with a WRITE_REGISTRY=1 parameter. Doing this custom install correctly honored the non-selection of 'Tagalog' UI language made on the MS Installer custom panels. Version: 25.2.0.0.beta1 (X86_64) / LibreOffice Community Build ID: 5a5fc103cad77dc243b7e54511502054c12c121c CPU threads: 8; OS: Windows 10 X86_64 (10.0 build 19045); UI render: Skia/Vulkan; VCL: win Locale: en-US (en_US); UI: en-US Calc: CL threaded @Eike, could you have a look and compare notes with Christian as to why the back port to 24.8 seems to have gone wrong, and which may be poisoning the MAR update patches? =-ref-= [1] https://gerrit.libreoffice.org/c/core/+/175503 [2] https://gerrit.libreoffice.org/c/core/+/175488
FYI: I also fail to reproduce the langauge-switching. While I can confirm that Tagalog is available as additional language and that in itself might be unexpected or a feature (depending how you look at it), it didn't change the language from the default (German in my tests, auto-selected based on Windows language or English on another machine)… (That being said: Adding a new language during a release cycle is pretty rare, but the language was completed so quickly and .3 is still pretty early in the overall cycle we decided to add it as new language. So this specific issue is unlikely to occur again)
OK, I think I now understand what's going on, at least in the case of duplicate bug 164264 "LibreOffice suddenly changed its language to Tagalog on its own": 1 Andrea used MAR update to move from an original, msi-installed version that did not yet support the Tagalog UI language to a version that does. Due to how newly added optional components are handled by our MAR update (see <https://git.libreoffice.org/core/+/c00014019e6d33bfb4729c563062db1645c48e9d%5E!/> "tdf#161292: Fix create-partial-info for newly added files"), the relevant files for the Tagalog UI language were unconditionally installed then. 2 Originally, Andrea only had LO's "English (United Kingdom)" UI language installed, and runs LO from an Italian (it-IT) system locale. 3 The code that, when starting LO, determines the UI language to use, is split in two relevant parts. First, prepareLocale in desktop/source/app/langselect.cxx assembles a `css::uno::Sequence<OUString> inst` of all installed UI languages. (For Andrea, this originally only contained "English (United Kingdom)", but after the MAR update now additionally contains "Tagalog". The order of the items in the list is effectively random.) Then (under certain conditions), that code calls getInstalledLocaleForSystemUILanguage in svtools/source/misc/langhelp.cxx, passing it that `inst` sequence. That code effectively scans that sequence for an entry that matches the system locale (it-IT in Andrea's case, but for which the sequence contains no match). If no matching entry is found, it then tries with an en-US locale (which also finds no match in Andrea's case), and as a final resort uses the first item from the passed `inst` sequence. Originally, that would always have used the "English (United Kingdom)" entry (which originally was the only entry in the sequence), but now happens to use the "Tagalog" entry (as the order of the entries is effectively random). (What might help somewhat mitigate all this is if the "English (United States)" UI language were always installed, and would not be an optional item in msi-based installations. Then, the above would at least have fallen back to that "English (United States)" instead of the random "Tagalog".)