<html><head><meta http-equiv="Content-Type" content="text/html; charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">Sounds like a good solution, as the current method is fundamentally broken wrt code-signing, and is an extra step for users<div class=""><br class=""></div><div class="">How big would the .app bundle be? That would be the only drawback</div><div class=""><br class=""></div><div class="">I see the LO Vanilla build is 2.2 GB vs 0.8 GB for a single language build</div><div class=""><br class=""></div><div class="">This is still less than MS Office that also bundles localizations:</div><div class="">Word: 2.1 GB</div><div class="">Excel: 1.7 GB</div><div class="">PowerPoint: 1.6 GB</div><div class=""><br class=""></div><div class="">So LO would still beat the 5.3 GB in total for the competition :)</div><div class=""><br class=""></div><div class="">A workaround would be to offer also an English-only build for users short on disk space - Apple was very stingy on SSD size for a while, with only 128 GB on the default models...<br class=""><div><br class=""><blockquote type="cite" class=""><div class="">On 21 May 2020, at 12:35, Tor Lillqvist <<a href="mailto:tml@iki.fi" class="">tml@iki.fi</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class="">It has long been known that the way language packs work, adding new files into an existing LibreOffice app bundle, is fundamentally wrong on macOS. In the current and previous macOS versions it is even more wrong, as installing a language pack often actively prevents LibreOffice from working.<div class=""><br class=""></div><div class="">I have attempted to change how language packs work for some weeks now (intermixed with other work) by trying a couple of approaches to make the code look for the things that language packs install in more places than where it currently does. But it is quite complicated.</div><div class=""><br class=""></div><div class="">A much easier solution would be for TDF to simply stop building and distributing language packs for macOS.</div><div class=""><br class=""></div><div class="">Instead, my suggestion is that what should be distributed is:</div><div class=""><ul class=""><li class="">A build with a multitude of UI languages. Not all, but those with "good enough" coverage. This build would also contain all dictionaries (even for languages for which the UI is not included)<br class=""></li><li class="">A number of other builds each with some geographic subset of the rest of the UI languages, plus English (and, perhaps French, Russian, and other languages that are commonly known as non-native languages in the geographic area in question). Also in these builds all dictionaries would be included.</li></ul></div><div class="">As the macOS build of LibreOffice currently seems to show help in the browser from the TDF website anyway, no help should be included in any build. When the problem that prevents help included in the app bundle from being shown in the browser has been fixed, that would need to be reconsidered.</div><div class=""><br class=""></div><div class="">If somebody needs LibreOffice with UI in languages that are in separate builds, they would need to install two copies of LibreOffice.</div><div class=""><br class=""></div><div class="">Please, if you don't use macOS and have nothing constructive to say, suppress any knee-jerk reaction.</div><div class=""><br class=""></div><div class="">--tml</div></div>
_______________________________________________<br class="">LibreOffice mailing list<br class=""><a href="mailto:LibreOffice@lists.freedesktop.org" class="">LibreOffice@lists.freedesktop.org</a><br class="">https://lists.freedesktop.org/mailman/listinfo/libreoffice<br class=""></div></blockquote></div><br class=""></div></body></html>