Translate installers for OS X and Windows

[fhemberger]

It would be nice if we could translate the installer packages as well. Can someone please give me a hand with altering the build process to allow translations for both platforms?

[jessy1092]

Maybe wait this PR for OS X installer. #776

[fhemberger]

@jessy1092 Thanks for the heads up. I already tested the translation process with this PR, which is really easy and comfortable: https://github.com/fhemberger/io.js/commit/65ba54ec0eb112ce040415ac2b3b321b8e38b5d1 (added German translation). As soon as this PR lands, we can use this commit as a basis for further internationalization.

[fhemberger]

Does anybody have experience with localizing MS Installers as well? According to this (older) blog post it's possible with transformations without creating additional installer files for each language. But as far as I understand, you end up with having several files (one "master" installer and a transformation file with the deltas for each language). So it's possible that the .msi installer for windows needs to be replaced with a .zip file containing the installation files. Can someone confirm this?

[mathiask88]

Localizing the MSI is quite easy. If you want to read in then take a look in chapter 12 of this book https://books.google.de/books?id=S5VFSs_iKywC&printsec=frontcover&hl=de#v=onepage&q&f=false

You can create a single msi for every language or a single multilanguage msi.

[piscisaureus]

is it really worth the work and the (huge!) maintenance overhead?
Localize the docs first would be my suggestion.
Even if English is complete jumbo jumbo to someone it should not be too hard to find the "next" button and click it 4 times.

[remixz]

@fhemberger Glad to hear localizing the Mac installer was easy to do. Let me know if I can make any of the instructions in the README clearer.

[fhemberger]

@piscisaureus You have to translate basically just the short welcome/success and error messages, not the whole installer. The rest will already be in your OS language. Took me just a couple of minutes and I think once I figure out how the Windows Installer script works, it will be the same.

Thought it was a nice addition. After downloading a file from a localized website, it should have the same localization during the installation process (especially when it comes to installation errors).

Of cause you're right that this will add some overhead, but that's why I'm looking into the actual amount of it.

(OT: I'm strictly against translating the entire API docs, those will become a nightmare to maintain. I've seen it already in various open source projects which had their once translated docs out of sync, so you had to fall back to English anyway – once you finally found out they weren't up-to-date.)

[bnoordhuis]

@fhemberger Does translating mean that you get a single installer with a language selection menu or do you end up with multiple installers? From your commit, I'm guessing (and hoping) it's the first one?

[fhemberger]

@bnoordhuis You get a single installer, the language selection is done by the OS automatically (with fallback to English).

[bnoordhuis]

Sounds alright to me then. I suspect that the maintenance overhead that @piscisaureus is afraid of, is orchestrating the i18n effort whenever changes are made to the installer (which is a legitimate concern.)

Strawman policy: we copy the English text and leave it to i18n contributors to make the necessary updates. Reviewing and landing the pull requests would still be quite a bit of work, though. :-(

[fhemberger]

Reviewing and landing the pull requests would still be quite a bit of work, though. :-(
But that's true for any part of the project, having currently 29 localization teams.

For the moment at least, the content which needs to be translated is very generic. As long as you don't heavily alter the current installation process, this shouldn't be a big issue, especially when not translated texts will be simply shown in English.

[fhemberger]

Can someone with a bit more Visual Studio/WiX experience please have a look at this:
https://github.com/fhemberger/io.js/commit/9e738063334f91ec3182e815516790c0ae106e93

I got the German translation working for the Windows installer, but the build breaks in VS2012 when both cultures are defined in nodemsi.wixproj at the same time: <Cultures>en-US;de-DE</Cultures> using just one of them works for me.

1>------ Build started: Project: nodemsi, Configuration: Release x86 ------
1>  C:\Program Files\WiX Toolset v3.9\bin\Heat.exe dir ..\..\..\deps\npm -cg NpmSourceFiles -dr NodeModulesFolder -var var.NpmSourceDir -gg -out ..\..\..\npm.wxs
1>  C:\Program Files\WiX Toolset v3.9\bin\candle.exe -dDebug -dProductVersion=0.0.0.0 -dNoETW= -dNoPerfCtr= -dNpmSourceDir=..\..\..\deps\npm\ -dProgramFilesFolderId=ProgramFilesFolder -d"DevEnvDir=C:\Program Files\Microsoft Visual Studio 12.0\Common7\IDE\\" -dSolutionDir=C:\Users\Testuser\io.js\tools\msvs\msi\ -dSolutionExt=.sln -dSolutionFileName=nodemsi.sln -dSolutionName=nodemsi -dSolutionPath=C:\Users\Testuser\io.js\tools\msvs\msi\nodemsi.sln -dConfiguration=Release -dOutDir=..\..\..\Release\ -dPlatform=x86 -dProjectDir=C:\Users\Testuser\io.js\tools\msvs\msi\ -dProjectExt=.wixproj -dProjectFileName=nodemsi.wixproj -dProjectName=nodemsi -dProjectPath=C:\Users\Testuser\io.js\tools\msvs\msi\nodemsi.wixproj -dTargetDir=C:\Users\Testuser\io.js\Release\ -dTargetExt=.msi -dTargetFileName=iojs-v-x86.msi -dTargetName=iojs-v-x86 -dTargetPath=C:\Users\Testuser\io.js\Release\iojs-v-x86.msi -dcustom_actions.Configuration=Debug -d"custom_actions.FullConfiguration=Debug|x64" -dcustom_actions.Platform=x64 -dcustom_actions.ProjectDir=C:\Users\Testuser\io.js\tools\msvs\msi\ -dcustom_actions.ProjectExt=.vcxproj -dcustom_actions.ProjectFileName=custom_actions.vcxproj -dcustom_actions.ProjectName=custom_actions -dcustom_actions.ProjectPath=C:\Users\Testuser\io.js\tools\msvs\msi\custom_actions.vcxproj -dcustom_actions.TargetDir=C:\Users\Testuser\io.js\tools\msvs\msi\x64\Debug\ -dcustom_actions.TargetExt=.dll -dcustom_actions.TargetFileName=custom_actions.dll -dcustom_actions.TargetName=custom_actions -dcustom_actions.TargetPath=C:\Users\Testuser\io.js\tools\msvs\msi\x64\Debug\custom_actions.dll -IC:\Users\Testuser\io.js\tools\msvs\msi\i18n\ -out obj\Release\ -arch x86 -ext "C:\Program Files\WiX Toolset v3.9\bin\\WixUIExtension.dll" -ext "C:\Program Files\WiX Toolset v3.9\bin\\WiXUtilExtension.dll" product.wxs obj\Release\Product.Generated.wxs
1>  C:\Program Files\WiX Toolset v3.9\bin\candle.exe -dDebug -dProductVersion=0.0.0.0 -dNoETW= -dNoPerfCtr= -dNpmSourceDir=..\..\..\deps\npm\ -dProgramFilesFolderId=ProgramFilesFolder -d"DevEnvDir=C:\Program Files\Microsoft Visual Studio 12.0\Common7\IDE\\" -dSolutionDir=C:\Users\Testuser\io.js\tools\msvs\msi\ -dSolutionExt=.sln -dSolutionFileName=nodemsi.sln -dSolutionName=nodemsi -dSolutionPath=C:\Users\Testuser\io.js\tools\msvs\msi\nodemsi.sln -dConfiguration=Release -dOutDir=..\..\..\Release\ -dPlatform=x86 -dProjectDir=C:\Users\Testuser\io.js\tools\msvs\msi\ -dProjectExt=.wixproj -dProjectFileName=nodemsi.wixproj -dProjectName=nodemsi -dProjectPath=C:\Users\Testuser\io.js\tools\msvs\msi\nodemsi.wixproj -dTargetDir=C:\Users\Testuser\io.js\Release\ -dTargetExt=.msi -dTargetFileName=iojs-v-x86.msi -dTargetName=iojs-v-x86 -dTargetPath=C:\Users\Testuser\io.js\Release\iojs-v-x86.msi -dcustom_actions.Configuration=Debug -d"custom_actions.FullConfiguration=Debug|x64" -dcustom_actions.Platform=x64 -dcustom_actions.ProjectDir=C:\Users\Testuser\io.js\tools\msvs\msi\ -dcustom_actions.ProjectExt=.vcxproj -dcustom_actions.ProjectFileName=custom_actions.vcxproj -dcustom_actions.ProjectName=custom_actions -dcustom_actions.ProjectPath=C:\Users\Testuser\io.js\tools\msvs\msi\custom_actions.vcxproj -dcustom_actions.TargetDir=C:\Users\Testuser\io.js\tools\msvs\msi\x64\Debug\ -dcustom_actions.TargetExt=.dll -dcustom_actions.TargetFileName=custom_actions.dll -dcustom_actions.TargetName=custom_actions -dcustom_actions.TargetPath=C:\Users\Testuser\io.js\tools\msvs\msi\x64\Debug\custom_actions.dll -IC:\Users\Testuser\io.js\tools\msvs\msi\i18n\ -out obj\Release\pth2CD02A3A56FE4907938D070A84025120\ -arch x86 -ext "C:\Program Files\WiX Toolset v3.9\bin\\WixUIExtension.dll" -ext "C:\Program Files\WiX Toolset v3.9\bin\\WiXUtilExtension.dll" ..\..\..\npm.wxs
1>  C:\Program Files\WiX Toolset v3.9\bin\Light.exe -out C:\Users\Testuser\io.js\Release\en-US\iojs-v-x86.msi -pdbout C:\Users\Testuser\io.js\Release\en-US\iojs-v-x86.wixpdb -cultures:en-US -ext "C:\Program Files\WiX Toolset v3.9\bin\\WixUIExtension.dll" -ext "C:\Program Files\WiX Toolset v3.9\bin\\WiXUtilExtension.dll" -loc i18n\de-de.wxl -loc i18n\en-us.wxl -spdb -contentsfile obj\Release\nodemsi.wixproj.BindContentsFileListen-US.txt -outputsfile obj\Release\nodemsi.wixproj.BindOutputsFileListen-US.txt -builtoutputsfile obj\Release\nodemsi.wixproj.BindBuiltOutputsFileListen-US.txt -wixprojectfile C:\Users\Testuser\io.js\tools\msvs\msi\nodemsi.wixproj obj\Release\product.wixobj obj\Release\pth2CD02A3A56FE4907938D070A84025120\npm.wixobj obj\Release\Product.Generated.wixobj
1>C:\Users\Testuser\io.js\tools\msvs\msi\product.wxs(25,0): warning LGHT1076: ICE61: This product should remove only older versions of itself. The Maximum version is not less than the current product. (0.0.0.0 0.0.0.0)
1>  C:\Program Files\WiX Toolset v3.9\bin\Light.exe -out C:\Users\Testuser\io.js\Release\de-DE\iojs-v-x86.msi -pdbout C:\Users\Testuser\io.js\Release\de-DE\iojs-v-x86.wixpdb -cultures:de-DE -ext "C:\Program Files\WiX Toolset v3.9\bin\\WixUIExtension.dll" -ext "C:\Program Files\WiX Toolset v3.9\bin\\WiXUtilExtension.dll" -loc i18n\de-de.wxl -loc i18n\en-us.wxl -spdb -contentsfile obj\Release\nodemsi.wixproj.BindContentsFileListde-DE.txt -outputsfile obj\Release\nodemsi.wixproj.BindOutputsFileListde-DE.txt -builtoutputsfile obj\Release\nodemsi.wixproj.BindBuiltOutputsFileListde-DE.txt -wixprojectfile C:\Users\Testuser\io.js\tools\msvs\msi\nodemsi.wixproj obj\Release\product.wixobj obj\Release\pth2CD02A3A56FE4907938D070A84025120\npm.wixobj obj\Release\Product.Generated.wixobj
1>C:\Users\Testuser\io.js\tools\msvs\msi\product.wxs(25,0): warning LGHT1076: ICE61: This product should remove only older versions of itself. The Maximum version is not less than the current product. (0.0.0.0 0.0.0.0)
1>  move "C:\Users\Testuser\io.js\Release\en-US\iojs-v-x86.msi;C:\Users\Testuser\io.js\Release\de-DE\iojs-v-x86.msi" "C:\Users\Testuser\io.js\Release\\iojs-v-x86.msi"
1>move "C:\Users\Testuser\io.js\Release\en-US\iojs-v-x86.wixpdb;C:\Users\Testuser\io.js\Release\de-DE\iojs-v-x86.wixpdb" "C:\Users\Testuser\io.js\Release\\iojs-v-x86.wixpdb"
1>  The filename, directory name, or volume label syntax is incorrect.
1>  The filename, directory name, or volume label syntax is incorrect.
1>C:\Program Files\MSBuild\Microsoft\WiX\v3.x\wix2010.targets(2866,5): error MSB3073: The command "move "C:\Users\Testuser\io.js\Release\en-US\iojs-v-x86.msi;C:\Users\Testuser\io.js\Release\de-DE\iojs-v-x86.msi" "C:\Users\Testuser\io.js\Release\\iojs-v-x86.msi"
1>move "C:\Users\Testuser\io.js\Release\en-US\iojs-v-x86.wixpdb;C:\Users\Testuser\io.js\Release\de-DE\iojs-v-x86.wixpdb" "C:\Users\Testuser\io.js\Release\\iojs-v-x86.wixpdb"" exited with code 1.
1>Done building project "nodemsi.wixproj" -- FAILED.
1>
========== Build: 0 succeeded, 1 failed, 1 up-to-date, 0 skipped ==========

[mathiask88]

I think the directories de-DE and en-US are missing in Release.

[fhemberger]

No, they will be created automatically.

[mathiask88]

Ok it comes from the Post-build Event Command Line in the solution options->Build Events.

move "!(TargetPath)" "$(TargetDir)$(TargetFileName)"
move "!(TargetPdbPath)" "$(TargetDir)$(TargetPdbName)"

These two lines generate the move commands that fail.

move "C:\Users\Testuser\io.js\Release\en-US\iojs-v-x86.msi;C:\Users\Testuser\io.js\Release\de-DE\iojs-v-x86.msi" "C:\Users\Testuser\io.js\Release\\iojs-v-x86.msi"

There are two files in the move command and in the dest-folder a double backslash. For me everything works fine if I delete these lines.

BTW if you leave the culture field empty WiX will build every culture.

[fhemberger]

Thanks, will look into it again tomorrow.

[fhemberger]

Ok, here is the update: https://github.com/fhemberger/io.js/tree/refactor-win-installer-de

The build error is gone, separate installers for each language are created. After the build process the German test translation should be transformed and combined into the en-US installer (at least I followed the documentation for the process described in the book @mathiask88 linked). Unfortunately, I currently don't have a German Windows version at hand to test it.

Looking for willing testing victims on Monday. ;)

[mathiask88]

@fhemberger installer works nice. I tested german, english and dutch(for fallback) windows languages.

But at the end of building I get a message box that is a bit annoying for running a command line.

• this and this lines are not yet translated.
• Here is the wrong locale variable

[fhemberger]

This is coming from the original MS script used, I'll comment out that line. Regarding the two missing translations: I couldn't come up with a fitting German translation for those yet, so I skipped them for the moment. I'll fix the wrong variable, thanks for pointing this out!

[rvagg]

Going to add tc-agenda to this due to the maintenance concerns @piscisaureus mentioned, I have similar concerns even if it is a relatively simple translation.

I wonder if there's some way we could build in a check somewhere to check whether the english data is newer than other languages so we can catch a potential sync problem before it gets out in to the wild. Maybe something triggered by make pkg on OSX and vcbuild.bat msi on Windows that does a git triangulation. Or, in lieu of something workable perhaps some strongly worded messaging in comments in the installer files that if you change this text you have to file an issue on the repo to get the other languages updated. The risk is that someone like me will go ahead and make a change without considering i18n because it's not in my normal scope of work and it'll slip through into a release and we'd be out of sync.

[tellnes]

@rvagg Good points.

Maybe we could make the build process only use the translated version if it is newer than the english version and fallback to english if it is older.

That will make sure that a release is never out of sync. The only problem with this is if the english version change and the translated version does not need to be changed. Then we need some way to mark those translations as up to date.

In addition to that there should be some external tooling for the i18n groups which says if some translation needs to be checked.

[fhemberger]

Status as of io.js TC Meeting 2015-02-18:

Resolution: allow this to land unless there are going to be technical blockers to future installer changes needing to wait for translations to be updated

[rvagg]

I consider there to be technical blockers while this remains difficult to set up to make it work, setting up windows build machines is tedious enough as it is (no automation) without adding the additional things here

happy to shave yaks here when I have time, but that's a limited resource for me at the moment

[fhemberger]

@rvagg I added this comment just to document the overall consensus on this topic.

For technical issues with the Windows version, we should continue discussion on #888. The Mac version is far less intrusive and is good to go, as soon as #776 lands.

[Trott]

#776 has been closed in favor of #2571 so I guess this is now pending that PR...

[fhemberger]

@Trott Well, there is also #5656 (@rvagg's take on #2571) now. ;)

[Trott]

This issue has been inactive for 16 months. Are we still optimistic this is going to get across the finish line?

[refack]

Ref: #4603 (comment)

[targos]

I think this was resolved for Windows in #2247
What about macOS?

[fhemberger]

Closing this.

There has never been a vocal demand for localized installers from the community, though it would have been nice to have along with our localized website and docs.