English package(http://people.apache.org/~jsc/developer-snapshots/windows/r1309668/Apache_OpenOffice_incubating_3.4.0_Win_x86_install_en-US.exe) works on my XP SP3.

And I notice the r1309668 en_US package is 144M, but the zh_CN package is only 116M.

This problem also happen on SUSE Linux Enterprise 11Service Pack 1

confirm this problem with pt_BR on MacOS. It seems to be a relation between the partly wrong translation and the save problem. I think it is a serious problem and it is definitely a showstopper

ALG: I have checked out r1309668 and built pro versions of en-US (short: en) and zh-CN (short: zh). Installed both, could confirm the error in zh version. The save dialog re-opens after triggering save, no file is saved. The cycle can be interrupted by ending the dialog with (ESC), but the file is not saved.

A difference shows up in the files:
(a) svn_trunk_1309668_ti1pro_zh_CN\Basis\share\registry\res\fcfg_langpack_zh-CN.xcd (zh install) 
(b) svn_trunk_1309668_ti1pro_en_US\Basis\share\registry\res\fcfg_langpack_en-US.xcd (en install)

While (b) is 8688 bytes, (a) is only 180 bytes. File (a) only contains the XML header while (b) contains the filter list definitions.

Exchanging the contents of (a) with (b) makes the problem disappear, thus this is for sure the reason. To test, do replace the contents before the first start or delete the caches (in the installation). Exchanging after first start without deleting caches will not help.

Looking now where this bad file (a) is coming from...

ALG: Both files can be found in the build environment in svn_trunk_1309668\main\solver\340\wntmsci12.pro\xml. This is the solver output tree, the files are not part of the source but get generated.

Grepping for usage of "" shows usages in:

svn_trunk_1309668\main\filter\wntmsci12.pro\misc\FCFGPkg.dpz(17)
svn_trunk_1309668\main\scp2\wntmsci12.pro\bin\osl\setup_osl.inf(19110)
svn_trunk_1309668\main\scp2\wntmsci12.pro\bin\osl\setup_osljre.inf(19118)
svn_trunk_1309668\main\scp2\wntmsci12.pro\misc\osl\file_ooo.pre(1421)
svn_trunk_1309668\main\scp2\wntmsci12.pro\par\osl\file_ooo.par(2013)
svn_trunk_1309668\main\solver\340\wntmsci12.pro\bin\setup_osl.inf(19110)
svn_trunk_1309668\main\solver\340\wntmsci12.pro\inc\postprocess\deliver.log(28)
svn_trunk_1309668\main\solver\340\wntmsci12.pro\par\osl\file_ooo.par(2013)

All usages are in output trees, no hint where it gets constructed.

Interesting is svn_trunk_1309668\main\solver\340\wntmsci12.pro\inc\postprocess\deliver.log(28):

COPY main/postprocess/wntmsci12.pro/misc/lang/fcfg_langpack_zh-CN.xcd wntmsci12.pro/xml//fcfg_langpack_zh-CN.xcd

The file in main/postprocess/wntmsci12.pro/misc/lang is already too short. Checking who constructs the source file, seems to happen in main\postprocess\packregistry\makefile.mk from $(SOLARPCKDIR)/$$(@:b).zip.

This leads to svn_trunk_1309668\main\postprocess\wntmsci12.pro\misc\ where e.g. fcfg_langpack_*.unzip dirs exist.

The file svn_trunk_1309668\main\postprocess\wntmsci12.pro\misc\fcfg_langpack_zh-CN.unzip\org\openoffice\TypeDetection\Filter.xcu is empty, this seems to be an error compared to e.g. svn_trunk_1309668\main\postprocess\wntmsci12.pro\misc\fcfg_langpack_en-US.unzip\org\openoffice\TypeDetection\Filter.xcu which is 10938 bytes long.

Question now: Where does the zipped languagepack file come from and how is ist created...?

ALG: in svn_trunk_1309668\main\solver\340\wntmsci12.pro\pck are the fcfg_drivers_(zh-CN|*).zip files, these show the same picture. While the en-US is filled, the zh-CN is empty.

Who is creating it and how? Probably somewhere in extras/l10n...

ALG: Updated with jsc's changes to the localize.sdf files, rebuilt en-US and zh-CN, reinstalled and tested. All works as expected. Task is fixed from my POV. Thanks Juergen for identifying and fixing the reason!

r1325589 zh_CN full installation package on Redhat 6.1 works fine

Verified agaisnt r1325589 Windows build.

r1325589 -Chinese China (zh-CN) version  works fine