On 10/18/2019 4:41 AM, Sverre Moe wrote:
fre. 18. okt. 2019 kl. 01:17 skrev Alexey Semenyuk
<alexey.semen...@oracle.com <mailto:alexey.semen...@oracle.com>>:
On 10/17/2019 6:10 PM, Sverre Moe wrote:
I wonder if there is something I can contribute with to improve
the localization. Perhaps work further with the existing
Localization that exists for WiX in jpackage.
I made some changes to the jpackage localization, that I can
contribute (mentioned in Change 1). The 2 other changes mentioned
below require a little discussion before beginning to implement.
*Change 1:* Add some missing localization for Strings on the
installer information dialog for when folder already exists.
installer.folder.exists.dialog.title = Setup
installer.folder.exists.dialog.button.yes = Yes
installer.folder.exists.dialog.button.no
<http://installer.folder.exists.dialog.button.no> = No
These are the Dialog Strings defined strictly in jpackage
template.wxs for the JpInvalidInstallDir dialog.
I'm confused. Do you mean main.wxs? There is no template.wxs file
in the sandbox, but there is main.wxs with JpInvalidInstallDir dialog.
Yes, I meant the main.wxs. It defines a dialog for the invalid install
dir which has 4 Strings. Currently only one of these Strings has
localization in MsiInstallerStrings with jpackage, the three others
are missing.
The Change 1 I proposed was to add the localization for these three
missing Strings to the existing
MsiInstallerString_en.wxl, MsiInstallerString_ja.wxl and
MsiInstallerString_zh_CN.wxl
Sounds good.
You can create a ticket in Jira (You can use
https://bugs.openjdk.java.net/browse/JDK-8230668 as a template for your
ticket), send review request to this mail alias and your path will be
integrated after review.
Details on submitting code reviews -
https://openjdk.java.net/guide/codeReview.html
The jpackage WiX template file is using the built-in
WixUI_InstallDir dialog, and it has its own localization.
https://wixtoolset.org//documentation/manual/v3/wixui/dialog_reference/wixui_installdir.html
WiX has some support for localization. Perhaps extensive enough
for most:
en-us, hr-HR, lv-LV, ro-RO, uk-UA, ar-SA, es-es, hu-HU, ru-ru,
zh-CN, bg-BG, et-EE, sk-SK, zh-HK, ca-ES, it-it, nb-NO, sl-SI,
zh-TW, cs-CZ, fi-FI, ja-jp, nl-NL, sr-Latn-CS, da-DK, fr-fr,
kk-KZ, pl-pl, sv-SE, de-de, he-IL, ko-KR, pt-BR, th-TH
The culture switch must be provided to light.exe in order to use
anything other than English.
Use "-culture:nb-no" for the nb_NO localization.
The cultures switch is not provided to light.exe by jpackage, and
it is recommended by WiX.
> The -loc flag is used to specify the language file to use. It
is important to include the -cultures flag on the command line to
ensure the correct localized strings are included for extensions
such as WiXUIExtension.
I have tested this by manually running light.exe and it works
fine. I got the Norwegian localization for the installer when I
specified "-culture:nb_NO".
What type of localization you are looking for? MSI installers can
be built with multilingual support. I.e. you can build an MSI
package that would include English, Norwegian, German, etc.
localizations and pick the one at installation time. But this is
quite a complicated thing -
https://www.firegiant.com/wix/tutorial/transforms/morphing-installers/.
If you need only one language in your installer, then simple
"-culture:nb_NO" would be sufficient, of course.
I had a single language installer in mind yes. I think the
morphing-installers would be much more difficult to implement support for.
I think using the cultures switch with light.exe would suffice for
jpackage to support localization.
Agreed.
*Change 2:* 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.
Adding --win-localization command line option looks reasonable. In
case of missing .wxl file for requested localization in OpenJDK
you would drop one in resource directory. Of course we need to fix
jpackage to hook up .wxl files from resource directory. This
functionality is missing at the moment.
One caveat though: We need to support the same number of
localizations in jpackage as WiX does. Otherwise if jpackage does
not have its own localization for the specified culture switch,
then building the installer will fail. It will fail for uknown
localization variables on jpackage's own Strings.
light.exe -culture:nb_NO MsiInstallerStrings_en.wxl
error The localization variable !(loc.message.install.dir.exist)
is unknown.
There are many localization files in WiX, but luckily jpackage
has only 4 Strings of its own. It should not be that much work to
make an MsiInstallerStrings file for each of the WiX localizations.
I don't think we would support any localization beyond English,
Japanese and Chinese Simplified in OpenJDK. Who would provide
translations in multiple languages on regular basis?
All these three localizations are in English, so what is the point
then with Japanese and Chinese?
jpackage is not a part of OpenJDK yet, once this will be the case, we
will have proper localization of that stub files.
Perhaps jpackage should just support English localization as default.
and the user would have to customize to get another localization.
jpackage should support all localizations that OpenJDK supports.
There is pre-existing localization in WiX for most of the installer UI
created with jpackage, but the cultures switch must be provided to use
them.
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
Ok, so in jpackage we are missing:
1. Logic to pick up .wxl files from resource dir and use them with
light.exe.
2. Option to specify value of -cultures light.exe option.
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.
Oh, en-us cultures set in MsiInstallerStrings_ja.wxl and in
MsiInstallerStrings_zh_CN.wxl is a bug. Thank you for the catch!
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.
Good to know, thank you!
I've created https://bugs.openjdk.java.net/browse/JDK-8232621 to capture
all l10n related issues of msi installers.
- Alexey
*Change 3:*
All the WiX localization Strings can be overridden in the
provided -loc MsiInstallerStrings.en.wxl file.
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.
> Using MsiInstallerStrings_en.wxl localization (specify
application-name.wxl in resource-dir to customize)
This is good idea.
- Alexey
