Created attachment 36886 [details]
Proposed patch

Created attachment 37103 [details]
Newer version of sellang.cxx

The above new version fixes a bug: On en-US machines we	should also deselect all
the other UI languages. Additionally, don't deselect the language of the user's
locale.

I don't see this as a defect. We should stay with this behaviour. I don't see 
any benefit for this change. Normaly the user has the single language version 
which he preferred/needs.

Multilanguage installation sets are not really supported by us. Nevertheless
this is an interesting feature. We will investigate it. Setting target OOo 2.x.

Created attachment 37169 [details]
New windowscustomaction_ooo.scp snippet for SelectLanguage

The above attachment is a better way to make sure the custom action gets called
at the correct place. My previous attempt using the sequence tables failed
miserably, I couldn't figure out a way to get the custom action to run after the
"select installation type" dialog through the sequence tables. Associating the
custom action to the "Next" button on that dialog in the ControlEvent table
works as I want.

Accepted

Setting target 2.1

I think this is a new faeture/enhancement for the MSI and we are far behind
feature freeze. We should retarget this to OOo 2.2.
What are the results I should see in the installer? How should the installaer
behave?

> What are the results I should see in the installer? 
> How should the installaer behave?

Well, first you need to build a multilingual installer in the first place, not
just a bunch of single-language ones as now. In
instsetoo_native/util/makefile.mk, edit the dependency list of the relevant
ALLTAR target (it can be hard to figure out the ifdef jungle, but for me at
least it's the third one that's relevant). To test, make it something like:

ALLTAR : openoffice_en-US,de,fr,it

(assuming you have included de, fr and it in the languages configured and built
in the first place)

With the custom action in this issue included, if you then run the resulting
installer on a German Windows installation, you will notice (if you choose a
"Custom" installation so that you get to see the details) that the French and
Italian UI language components have been automatically deselected (and German
selected). Correspondingly, on a French Windows machine, the German and Italian
components would be deselected.

It should be possible to detect if languagepacks are installed on the operating
system. In this case the related languages should not be deselected.
I see that this feature could be integrated, but I don't see the benefit. I
can't see why this is a 'nice to have'. The testing efford might be huge: At
lease we must assure that this will work in any language combination on any MS
platform.

> It should be possible to detect if languagepacks are installed on
> the operating system.

Do you mean OO.o language packs or Windows UI languages? If you mean the former,
isn't the only supported way to install a new version of OO.o to completely
uninstall the older one and its language packs first, so how could the installer
know what OO.o language packs/components have been before on the machine?

(And even if one would run an OO.o installer while an older OO.o version is
still installed, as the UUID identifiers for Windows Installer components are
regenerated fresh in each installer, how could the installer even know what to
look for?)

If you mean a Windows installation with multiple UI languages, yes, it would be
useful to enumerate the UI languages on the machine (using EnumUILanguages(),
presumably) and make sure to install the corresponding OO.o UI languages. I will
add that feature.

(I think multilingual Windows machines are pretty rare? Or what do I know, it
might be that in some locales or at some sites they are very common.)

I'm talking about OS languagepacks. Maybe my question is boring but: What is the
benefit for this new feature.

Well, the benefit is not a HUGE one, I never claimed that. Just a nice-to-have
thingie.

Novell uses a multi-lingual OO.o installer and we include as many UI languages
as we can. (There are unfortunately explicit and implicit limits on the number
of languages that can be included in the mechanism that builds the installer.
The Perl code tries to work around some limits, but there are bugs in the
workarounds.)

The current set we build into one installer is
en-US,ar,cs,da,de,el,es,fi,fr,he,hu,it,nb,nl,pl,pt-BR,pt,ru,sv,tr I think.
Without automatically limiting the installed UI languages, customers might
wonder why UI languages they are never going to use have been installed and take
disk space. Some people might even be upset if they find languages that offend
their nationalistic sensibilities on their disk, sigh. (OK, probably nobody is
that silly...)

I thought that we are talking about MSI? I fear that the efford is much bigger
than the benefit.

Huh, we *are* talking about MSI. Or at least, I interpret the term "MSI" as a
synonym for "Windows Installer". We are talking about the OO.o installer that
uses Windows Installer technology, aren't we? What does "MSI" mean to you?

is -> tml: There seem to be two problems with your Patch. It is not prepared for
warning free code and it does not support Win 98. Do you agree? The
"GetSystemDefaultUILanguage" is not supported by Win 98. Can you please fix
this? OOo officially supports Win 98.

retarget to next version.

change target

Having this wait until OOo finally stops supporting Win9x is fine with me. (Why
should we support that longer than Microsoft does?) I will look into the other
issues mentioned and attach a new patch.

Created attachment 43375 [details]
Updated sellang.cxx

The above updated sellang.cxx uses EnumUILanguages() to list the Windows UI
languages installed on the system, and keeps also all those as selected UI
language features in the OOo installer.

is -> tml: you are still waiting to the end of Win98 support? 

setting later target, when Win 98 is no longer supported. 
Also removing PATCH flag, because it cannot be integrated in the near future.