Hi *, On Thu, May 21, 2020 at 12:36 PM Tor Lillqvist <tml@xxxxxx> wrote: > > A much easier solution would be for TDF to simply stop building and distributing language packs for macOS. > > Instead, my suggestion is that what should be distributed is: > > A build with a multitude of UI languages. Not all, but those with "good enough" coverage. We already only have the languages we consider good enough coverage in an all-lang build. It's a subset of the languages we have in weblate, and (for historical reasons) a subset of the languages we have in translations repository. Selecting "good" languages is a minefield, you will surely annoy lots of translators/native language speakers. Both complains of "why do I have to download language xy that I never use/never heard of" and "why is my language not included, but language xy is". So I'll pass on this suggestion. > 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. Solving the help-issue would also solve the langaugepack-in-app-folder issue, so I don't see one happening without the other. Other solutions that were mentioned: * Single build with all languages included → with the current drag'n'drop installation that would require 3GB of diskspace, not too happy about that. And contrary to what has been suggested in this thread: Installing langaugepacks into the .app folder is orthogonal to Gatekeeper not being happy with our notarization/commandline tools disagreeing. Sure - after installation of the langaugepack the signatures are no longer tidy, but langaugepack triggers launch of LO before that for this reason/even without any langaugepack at all Gatekeeper is not happy (and at that state commandline tools still are) easiest for me to do in terms of release builds, mirrors, etc. drawbacks are the bigger download size (that's least of the problems) and the mentioned huge bump in required disk space. And maybe causing even more issues with gatekeeper due to the huge amount of files/user thinking the process did time out or similar) * individual full-builds for every language → my second-least-favorite solution after the "subset-of-languages" ones from a having-to-do-the-builds point of view. Wastes diskspace on mirrors, doesn't suit users who are using different languages, doesn't quite solve the dictionaries issue (all dictionaries in all builds?) * switching installation method away from drag'n'drop to programmatic installer that allows selecting components → my favorite solution, although no method of creating such a thing in our buildsystem yet, so likely same fate as the other solutions tml already explored: * not using the .app dir for the langaugepacks → tml already tried and failed ciao Christian _______________________________________________ LibreOffice mailing list LibreOffice@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/libreoffice