[Libreoffice] Bug 38882 - [EasyHack] Make it easier to select/deselect UI languages in the Windows installer

[Tor Lillqvist]

> I work daily with creating and modifying installer packages (msi's) on
> the Windows platform for deployment, and that sounds like a really
> hard way to do it. 2.3k lines of code to create an MSI.

Oh, it is a lot more than 2.3 kloc... most of the Perl code is in the modules in solenv/bin/modules/installer.

Sure, if LO was Windows-only software, and had always been that, and if it had a much shorter history, then presumably the Windows Installer would be created in a very different, more "normal" way. But all of those conditions are false... The scp2 data from which the install set is determined is supposed to be cross-platform, it directs also what gets installed and where on other platforms (Mac OS X, Linux, other Unixes). LibreOffice has a long history (as OpenOffice.org), since the mid-90s at least, and I am sure the way the Windows installer gets built has grown organically and/or been heavily (over-)designed at some stage to cover all possibilities. Also, it might well be from pre-MSI times. Etc. It is not so simple.

> Of course. I use a tool called InstEd which allows me to change the
> property names of the "ISXXXXX" rows to their corresponding language

Ah. But we don't want to use some *interactive* tool to modify the installer, when we build the installer from *source* (well, not "source code" in the sense of programming language, but data) programmatically. If this is what we want, change the names of these properties, and presumably their default values, we should of course do that in the *source*, not by using a manual interactive tool on the end result.

(We don't change functionality in the software by patching the binary either. We do changes in the source code and recompile.)

If we change the default value of the IS* properties (perhaps renamed to cleartext language names as you suggest) from 1 to 0, if that is what you are suggesting, that obviously means we will have to invert what the SelLang custom action does: Instead of de-selecting what it guesstimates are unneeded UI languages, it will now then need to select needed ones instead.

> InstEd also allows me to apply the
> transform on an existing MSI so we won't have to do it every time we
> are doing an installation.

Yeah but there is no promise that the structure of our data in the MSI will stay the same all the time. Plus we will certainly acquire new UI languages.

--tml