should we drop DEFAULT_TO_ENGLISH_FOR_PACKING?

[Andras Timar]

Hi,

On Tue, May 7, 2013 at 5:35 PM, David Tardon <dtardon at redhat.com> wrote:
> Hi all,
>
> the installer uses a special variable DEFAULT_TO_ENGLISH_FOR_PACKING to
> substitute en-US files if there are no files for "native" language (this
> is used for the stuff from extras and help). The reasoning why it is
> needed is in https://issues.apache.org/ooo/show_bug.cgi?id=45118 (Rene
> had strong objections to it at the time). There are two problems with
> it:
>
> 1. It does not work with FILELIST install. method (in fact, it breaks
>    Windows build, because there are multiple references of the same file).
>    The ARCHIVE method hacked this around by unpacking into lang-specific
>    dirs.
>
> 2. It is effectively disabled anyway since commit
>    165387b4e714d87ee080add6e45bc47fcde8e556 "WITH_LANG: add en-US if it is
>    missing".
>
> The question is: Do we see any reason to create install. sets that do
> not contain en-US, as explained in i#45118 (in that case there are
> several things that need to be fixed)? If not, we can just drop
> DEFAULT_TO_ENGLISH_FOR_PACKING and the related code.
>

No, I don't think we want install sets without en-US. But we need to
make sure that we don't have runtime problems when a localized file is
missing. Now there is the en-US copy, but after your proposed patch
there will be nothing. Not many language dependent files remained, I
think AutoText files are the only example. I manually removed an
autotext folder and I got a message box: Inadmissible path.
C:\LibreOffice\4.0.3.3\program\..\share\autotext\hu does not exist.
Probably the folder is created by the installer anyway. Can we have a
list of the affected files (if there are more than autotext), so we
can test the runtime behaviour?

Thanks,
Andras