Sverre Moe <sverre.moe@gmail.com>:
Add --win-culture, or --win-localization option to jpackage
Provide the culture switch to light.exe as specified from the localization option.
The second option is probably the best name. I would not even know what culture was about before looking into WiX, but everyone knows what localization means. The option approach would also allow users to run multiple executions of jpackage in order to build multiple installers in different languages.
While testing with WiX Localization I found that these cannot be used unless the localization file provided by jpackage has the same language.
WiX has Norwegian localization, among many other languages, while jpackage does not.
This will fail light.exe with an error:
-cultures:nb-no -loc MsiInstallerStrings_en.wxl
This will work though
-cultures:nb-no -loc MsiInstallerStrings_nb_NO.wxl
This will also fail with Japanese and Chinese localization since they have English en-us cultures set in their files.
-cultures:ja -loc MsiInstallerStrings_ja.wxl
-cultures:zh-cn -loc MsiInstallerStrings_zh_CN.wxl
So currently the Japanese and Chinese localization are useless as they are both in English.
I found a way around this problem: The cultures switch support fallback allowing the jpackage parts to remain in English, while the rest is properly localized.
-cultures:nb-no;en-us -loc MsiInstallerStrings_en.wxl
That way we can support the extensive localization support in WiX, while the same time keep the localization support in jpackage to a minimum of English, Japanese and Chinese Simplified.
We could support custom localization files in resource directory. It could allow users to provide localization which WiX does not have built-in support for, or just with different text for the existing localization Strings.
Add --win-culture, or --win-localization option to jpackage
Provide the culture switch to light.exe as specified from the localization option.
The second option is probably the best name. I would not even know what culture was about before looking into WiX, but everyone knows what localization means. The option approach would also allow users to run multiple executions of jpackage in order to build multiple installers in different languages.
While testing with WiX Localization I found that these cannot be used unless the localization file provided by jpackage has the same language.
WiX has Norwegian localization, among many other languages, while jpackage does not.
This will fail light.exe with an error:
-cultures:nb-no -loc MsiInstallerStrings_en.wxl
This will work though
-cultures:nb-no -loc MsiInstallerStrings_nb_NO.wxl
This will also fail with Japanese and Chinese localization since they have English en-us cultures set in their files.
-cultures:ja -loc MsiInstallerStrings_ja.wxl
-cultures:zh-cn -loc MsiInstallerStrings_zh_CN.wxl
So currently the Japanese and Chinese localization are useless as they are both in English.
I found a way around this problem: The cultures switch support fallback allowing the jpackage parts to remain in English, while the rest is properly localized.
-cultures:nb-no;en-us -loc MsiInstallerStrings_en.wxl
That way we can support the extensive localization support in WiX, while the same time keep the localization support in jpackage to a minimum of English, Japanese and Chinese Simplified.
We could support custom localization files in resource directory. It could allow users to provide localization which WiX does not have built-in support for, or just with different text for the existing localization Strings.
- duplicates
-
JDK-8232136 Localization of Windows installers
- Closed
-
JDK-8091829 Native bundles: provide a way to hook in localized UI
- Closed
- relates to
-
JDK-8290471 jpackage: allow to specify codepage on Windows
- In Progress