Re: Suggestion: No more language packs for macOS as they are fundamentally broken

Hi *,

On Thu, May 21, 2020 at 12:36 PM Tor Lillqvist <tml@iki.fi> 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