/editeng/

y the old code explicilty added en-US to the gb_WITH_LANG list of languages for which to generate InfoPlist_*.zip and InfoPlist.strings files (when that would presumably be the non-localized strings stored in Info.plist itself). But as mentiond, those InfoPlist.strings files are all empty anyway (which may be due to another bug?), so it shouldn't matter much---at least for now---what Contents/Resources/*.lproj/InfoPlist.strings files exactly are present in an installation set. Change-Id: Iaadce2375ed319928891bace44f9866622ec3084 Reviewed-on: https://gerrit.libreoffice.org/71277 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com> 
Don't know how this got broken, presumably somewhere along the line from
01344a8ca57636ac87108c22f777a02fe6d963d5 "convert sysui to gbuild and add to
tail_build" through 4430ace32a8dfd534d5e1c64ec7855edad11e5c4 "tdf#90753:
AutoInstall more packages" to the current state, where a spurious bin directory
containing InfoPlist_*.zip files containing (empty) InfoPlist.strings files is
placed in instdir/ and in the root window of .dmg files.

As discussed in the <https://developer.apple.com/library/archive/documentation/
General/Reference/InfoPlistKeyReference/Articles/
AboutInformationPropertyListFiles.html> "Localizing Property List Values"
section, those InfoPlist.strings files shall apparently be placed into the
Contents/Resources/*.lproj/ directories.  (And the zip wrappers were presumably
needed in the past to transport their payload to the proper places in the
installation set, and are now obsolete.)

The list of Apple language IDs for the *.lproj directories was already
duplicated in Makefile.in (test-install target) and
solenv/bin/modules/installer/simplepackage.pm (sub create_package).  Ultimately
those lists should all be consolidated.  Also, mapping from our language IDs
(see solenv/inc/langlist.mk) to the Apple *.lproj ones needs some fixing (e.g.,
from zh-CN to zh_CN), and it is not clear to me why the old code explicilty
added en-US to the gb_WITH_LANG list of languages for which to generate
InfoPlist_*.zip and InfoPlist.strings files (when that would presumably be the
non-localized strings stored in Info.plist itself).  But as mentiond, those
InfoPlist.strings files are all empty anyway (which may be due to another bug?),
so it shouldn't matter much---at least for now---what
Contents/Resources/*.lproj/InfoPlist.strings files exactly are present in an
installation set.

Change-Id: Iaadce2375ed319928891bace44f9866622ec3084
Reviewed-on: https://gerrit.libreoffice.org/71277
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
Create a proper Info.plist for the OS X app bundle already in configure 2013-09-23T23:00:52+00:00 Tor Lillqvist tml@collabora.com 2013-09-23T22:49:59+00:00 bbbc51e931c3a7018f2f19f61fa823190ee6fbb1 After recent instdir changes the SCPZIP_REPLACE thing was not used any more for Info.plist, so all the ${FOO} things were left in Info.plist unexpanded with predictably wonky results, a non-working app. Instead just expand it from the configure script. While at it, use a correct CFBundleShortVersionString: only three integers should be in that. Also, hardcode FILEFORMATNAME as OpenOffice.org and FILEFORMATVERSION as 1.0, and drop the "variables", as that is what those "variables" *means*. They were used to refer to the OOo 1.0 formats. (It would have been utterly wrong to define them as something else, like another product name and a newer version number, in openoffice.lst, so pointless to have them there.) Drop the meaningless BUILDIDCWS. Change-Id: I4030aa060b78e8b3fb812a6362869996e8db7d3d 
After recent instdir changes the SCPZIP_REPLACE thing was not used any
more for Info.plist, so all the ${FOO} things were left in Info.plist
unexpanded with predictably wonky results, a non-working app.

Instead just expand it from the configure script.

While at it, use a correct CFBundleShortVersionString: only three
integers should be in that.

Also, hardcode FILEFORMATNAME as OpenOffice.org and FILEFORMATVERSION
as 1.0, and drop the "variables", as that is what those "variables"
*means*. They were used to refer to the OOo 1.0 formats. (It would
have been utterly wrong to define them as something else, like another
product name and a newer version number, in openoffice.lst, so
pointless to have them there.)

Drop the meaningless BUILDIDCWS.

Change-Id: I4030aa060b78e8b3fb812a6362869996e8db7d3d
gbuild: consolidate ULF copypaste in gb_CustomTarget_ulfex_rule 2013-07-16T14:54:59+00:00 Michael Stahl mstahl@redhat.com 2013-07-16T12:54:04+00:00 85c7e212a26b24883b9a001b6529efeb80955809 Change-Id: I0c5b68f6bc81c7c1c88be2cde42fc06949fff8e7 
Change-Id: I0c5b68f6bc81c7c1c88be2cde42fc06949fff8e7
convert sysui to gbuild and add to tail_build 2013-02-17T21:58:28+00:00 Peter Foley pefoley2@verizon.net 2013-02-10T23:22:07+00:00 01344a8ca57636ac87108c22f777a02fe6d963d5 Change-Id: Ia32e51f0d95e001bcf07766f6340398e0ab1bf6a Reviewed-on: https://gerrit.libreoffice.org/2192 Tested-by: LibreOffice gerrit bot <gerrit@libreoffice.org> Reviewed-by: David Ostrovsky <David.Ostrovsky@gmx.de> Tested-by: David Ostrovsky <David.Ostrovsky@gmx.de> 
Change-Id: Ia32e51f0d95e001bcf07766f6340398e0ab1bf6a
Reviewed-on: https://gerrit.libreoffice.org/2192
Tested-by: LibreOffice gerrit bot <gerrit@libreoffice.org>
Reviewed-by: David Ostrovsky <David.Ostrovsky@gmx.de>
Tested-by: David Ostrovsky <David.Ostrovsky@gmx.de>