#1309 Need fallback language support for localization files.
I think the msierrXmlFileXXXX localisation variables are missing from WiXUtilExtension.
If you run light with ja-jp or es-es localisation you get the following errors:
C:\delivery\Dev\wix30_public\src\ext\UtilExtension\wixlib\UtilExtension.wxs(209,0): error LGHT0102: The localization variable !(loc.msierrXmlFileFailedRead) is unknown. Please ensure the variable is defined.
C:\delivery\Dev\wix30_public\src\ext\UtilExtension\wixlib\UtilExtension.wxs(210,0): error LGHT0102: The localization variable !(loc.msierrXmlFileFailedOpen) is unknown. Please ensure the variable is defined.
C:\delivery\Dev\wix30_public\src\ext\UtilExtension\wixlib\UtilExtension.wxs(211,0): error LGHT0102: The localization variable !(loc.msierrXmlFileFailedSelect) is unknown. Please ensure the variable is defined.
C:\delivery\Dev\wix30_public\src\ext\UtilExtension\wixlib\UtilExtension.wxs(212,0): error LGHT0102: The localization variable !(loc.msierrXmlFileFailedSave) is unknown. Please ensure the variable is defined.
Discussion
Logged In: YES
user_id=26581
Originator: NO
Only en-us strings are available for the custom actions; nobody's offered other translations for them. You can add "en-us" to the list of culture ids to let the linker choose the en-us strings if others aren't available.
Logged In: YES
user_id=1521752
Originator: YES
I have reopened this as a Votive bug because I think it may only be a Votive issue. If you set the cultures to blank or "en-US;ja-JP" in the properties they are built one at a time with the command line only containing one culture e.g. "-cultures:ja-jp" I think what you are staying is that it should always be built with en-US culture plus one other e.g. "-cultures:en-us;ja-jp" then "-cultures:en-us;es-es".
Logged In: YES
user_id=26581
Originator: NO
Put en-us at the end; that way, the "primary" culture takes precedence while en-us serves as fallback. Can you verify that with a command-line run of light.exe?
Logged In: YES
user_id=1521752
Originator: YES
I can confirm that running light with en-us as a fallback works e.g. "light -cultures:es-es;en-us". So it does look like a votive bug. The howto documentation doesn't mention this so I will update it and pass it to Neil Enns to check.
Logged In: YES
user_id=1521752
Originator: YES
I think there is another issue with the way Votive handles cultures. It only seems to pass in the localisation file for the language it is building e.g. light -cultures:ja-jp -loc ja-jp.wxl. This doesn't allow you to have a wxl file with imcomplete translations. From the command line I would build like this: light -cultures:ja-jp;en-us -loc ja-jp.wxl -loc en-us.wxl
Not a votive issue, but related to the msbuild targets used by Votive.
The msbuild changes have already been made. The UI (votive) changes remain so putting this back in the votive bucket.
I have changed this back to msbuild as it fails in the same way without using VS.
If you build with msbuild it builds each culture one at a time and there is now way to specify a fallback culture (tested with 3.0.5120.0). In the msbuild log I can see it running "Light.exe -cultures:ja-jp" but to work it needs to run "Light.exe -cultures:ja-jp;en-us".
I think the root problem here is that light needs a fallback culture option.
This should be fixed with the culture group implementation added. Check the docs on "Specifying cultures to build".
This Tracker item was closed automatically by the system. It was
previously set to a Pending status, and the original submitter
did not respond within 21 days (the time period specified by
the administrator of this Tracker).