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

> 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