Bugs item #1665517, was opened at 2007-02-21 21:56 Message generated for change (Comment added) made by islobodin You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=642714&aid=1665517&group_id=105970
Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: light Group: v3.0 Status: Closed Resolution: Invalid Priority: 5 Private: No Submitted By: Ilya Slobodin (islobodin) Assigned to: Nobody/Anonymous (nobody) Summary: Light does not ignore wxl files of different culture Initial Comment: Current 3.0.2612.0 uses strings from the first wxl file disregarding which culture is set on the command line. It would be great if light.exe could ignore extra localization files with different culture if culture(s) is set on the command line. E.g. Light My.wixlib -cultures:ru-ru -loc en-us.wxl -loc ru-ru.wxl will use strings from en-us.wxl but Light My.wixlib -cultures:ru-ru -loc ru-ru.wxl -loc en-us.wxl will use trings from ru-ru.wxl ---------------------------------------------------------------------- >Comment By: Ilya Slobodin (islobodin) Date: 2007-04-04 14:22 Message: Logged In: YES user_id=1639777 Originator: YES The -cultures switch looks very promising, like a main switch to get localized msi. And it is the only locale-specific switch that exists in Votive project options. Now I use slightly more complicated approach with intermediate wxl-only wixlib that works as expected. ---------------------------------------------------------------------- Comment By: Bob Arnson (barnson) Date: 2007-03-12 03:55 Message: Logged In: YES user_id=26581 Originator: NO The -cultures switch exists solely to choose an embedded localization string set from a .wixlib. It has no effect if you're not using a .wixlib or if a .wixlib doesn't have embedded localization strings. I'm not sure why the -cultures switch should work as you describe. What are the advantages over just supplying the correct loc strings? Loc support already lets you specify culture-neutral strings and override once with culture-specific strings. ---------------------------------------------------------------------- Comment By: Ilya Slobodin (islobodin) Date: 2007-02-22 15:19 Message: Logged In: YES user_id=1639777 Originator: YES WxlBug.wxs: <?xml version="1.0" encoding="utf-8"?> <Wix xmlns="http://schemas.microsoft.com/wix/2006/wi";> <Product Id="CCD8A0A9-D8CE-4E69-AE94-8A3BB75561B4" Name="WxlBug" Language="!(loc.Language)" Version="1.0.0" UpgradeCode="60045DEA-9E50-469D-B761-D6BFC8890DE0" Manufacturer="WxlBug"> <Package InstallerVersion="200" Compressed="yes" /> <Media Id="1" Cabinet="SerNum.cab" EmbedCab="no" /> <Property Id="Bug" Value="!(loc.Bug)"/> </Product> </Wix> en-us.wxl: <?xml version="1.0" encoding="utf-8"?> <WixLocalization Culture="en-us" xmlns="http://schemas.microsoft.com/wix/2006/localization";> <String Id="Language" Overridable="yes">1033</String> <String Id="Bug" Overridable="yes">Bug</String> </WixLocalization> ru-ru.wxl: <?xml version="1.0" encoding="utf-8"?> <WixLocalization Codepage="1251" Culture="ru-ru" xmlns="http://schemas.microsoft.com/wix/2006/localization";> <String Id="Language" Overridable="yes">1049</String> <String Id="Bug" Overridable="yes">Жук</String> </WixLocalization> candle WxlBug.wxs 1. light -cultures:en-us WxlBug.wixobj -loc en-us.wxl -loc ru-ru.wxl gives Bug=Bug in the resulting msi 2. light -cultures:en-us WxlBug.wixobj -loc ru-ru.wxl -loc en-us.wxl gives Bug=Жук in the resulting msi I expect here that ru-ru.wxl with Culture="ru-ru" should be ignored as only en-us culture is specified. ---------------------------------------------------------------------- Comment By: Bob Arnson (barnson) Date: 2007-02-22 07:40 Message: Logged In: YES user_id=26581 Originator: NO Are you overriding loc strings from the .wixlib? If so, that's intentional behavior. The idea is that you can take a general set of loc strings from a .wixlib and override only the ones you want. Overridable loc strings can be overridden once, which is why the first file passed with -loc is overriding the embedded loc strings. Culture is ignored so you can use culture-neutral strings. If you have a different scenario, please add a comment with more details. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=642714&aid=1665517&group_id=105970 ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ WiX-devs mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/wix-devs
