I'm realizing a custom setup for my outlook addin. I want the installer in Dutch language, but VS 2010 doesn't support this language.
Is there a solution to my issue?
The default procedure to make a dutch language msi setup is to use orca.exe on the msi file and translate the TEXT column of some tables. (you can also do this by extracting the msi database and by importing it back in the msi when the translation has been done).
But there is the other way: Creating the language support directly in the Setup project creator.
I'm using VS.NET 2003 (yeps still the old version) and when you create a setup project you have no dutch language support in the project localisation. I figured out how that thing works but I'm stuck in the language change of the msiloadr.bin and the webloadr.bin files (both dll files included in the distribution) (step 3 in the comment below). The unusual procedure to include directly the language support in the VS.Net Setup project :
1) get the local identifier and the code page for your language (http://msdn.microsoft.com/library/default.asp?url=/library/en-us/intl/nls_238z.asp)
2) Go to the VS.NET/Common7/Tools/Deployment/VsdDialogs directory and copy 1033 (english) directory to 1043 directory (dutch). Translate all the files in that directory with orca.exe and update the 1033 language code to 1043
3) Go to the VS.NET/Common7/Tools/Deployment/MsiRedist directory and copy 1033 (english) directory to 1043 directory (dutch). Here we need to update the bin files (DLL) to set it up as a dutch language.
4) Update the registry (HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\VisualStudio\7.1\Deployment\DialogTemplates:)
Append ", Dutch" to the Languages key
Append ", 1043" to the Identifiers key
Append ", 1252" to the CodePages key
Once you have done that you'll be able to compile any Setup project in the dutch language and this can be done for all the missing languages. (If you solve the 3rd step)
Maybe you have some solution to solve for the unofficial sulution by tweaking VS.NET :-)
Copied from: http://social.technet.microsoft.com/Forums/windows/en-US/2d062f34-5615-47c8-aa7b-a69fbd68e983/how-to-make-a-installer-in-dutch-language
Please read this :-
Set up creation using selected language
Related
I am working on this localization project for an app.
All of our English strings are in LocalizationResources.resx. Now we are trying to support for Japanese. We now include the Japanese version of resx i:e LocalizationResources.ja-JP.resx to the same location/solution project where english resx resides.
According to Microsoft there is no code change needed because .NET is smart enough to pick the correct resx file based on the current system locale.
When we run the app from Visual studio in Japanese locale, the app launches in Japanese. Thats good...
When we run the app by running an exe (generated by building the solution) in Japanese locale, the app launches in Japanese. Thats good as well...
BUT when we build solution to generate an MSI, then install it in Japanese locale, then launch the App it shows up in English!!! Clearly the visual studio and the exe know to read from Japanese resx but why doesnt the app(installed by MSI) run in Japanese???
I tried several combinations of settings for the resx file, such as "Build Action" = "Embedded resources", and "Copy to output directory" = Copy always/copy if new/do not copy.
I know for the fact that our packing tools do not differentiate or exclude any file from being part of MSI. So how to resolve this?
In the document Support Statement for Visual Basic 6.0 on Windows... it states:
Localization Support Binaries
The following binaries are necessary for supporting Visual Basic 6.0
applications running on localized versions of the Windows operating
system. They are supported but are not shipped in Windows. These files
are required to be shipped with your application setup.
That seems pretty clear in itself.
For instance, mfc42jpn.dll is required for Japan, mfc42ita.dll for Italy, etc.
However, I cannot find any source of these files from Microsoft. Where can they be sourced?
Note - there are some random DLL download websites which turn up the correct filenames, but I'd far prefer an authoritative source.
You should apply SP6. According to this, it covers all English versions of these products, as well as all localized versions.
On the VB6 installation CD those files can be found in the \OS\SYSTEM folder.
For the OP's given example of MFC42.dll it includes:
MFC42.DLL
MFC42CHS.DLL
MFC42CHT.DLL
MFC42DEU.DLL
MFC42ENU.DLL
MFC42ESP.DLL
MFC42FRA.DLL
MFC42ITA.DLL
MFC42JPN.DLL
MFC42KOR.DLL
I have a Windows Installer XML (WiX 3.5) project and five localization files for my installer. Therefore WiX creates five .msi files, for every language one. How can i put all in one .msi and let the user select the language when executing the installer?
I heard something about a bootstrapper, but then i would have a Setup.exe and i need a msi file. Is it not possible to adabt the localization strings after compiling with WiX?
This can be done using transforms. Please take a look at this article:
http://www.installsite.org/pages/en/msi/articles/embeddedlang/
There are 2 parts to making this happen,
localisation of the Installer UI, and/or
choice of installed files.
The method I chose will automatically select the local (or near local) language, and can also be forced to a specific transform using command line options. This doesn't prompt the user to choose which language to install in - so maybe it doesn't actually meet your needs.
The second 'installed files' doesn't seem to be documented as well and I was recently asking about it in Why would MST not include files with different content.
As a response provided there is now an ANT build script using Windows7 SDK & antdotnet
I need the JRE to use translated versions of a JRE resource that is available only in English.
As per the ResourceBundle.java doc, it's easy: add localized resources with the right locale suffix. For example, the standard
XMLSchemaMessages.properties
would become a translated version:
XMLSchemaMessages_FR.properties
And so on.
EDIT: this particular file lives in :
com\sun\org\apache\xerces\internal\impl\msg\XMLSchemaMessages.properties
My question is: how do I make those extra resources visible to the JRE ?
Thanks in advance, for any help.
-- cheers
Assuming that Xerces uses ResourceBundle to get the messages, you should put a new file in
com\sun\org\apache\xerces\internal\impl\msg\XMLSchemaMessages<locale>.properties
where locale is a correct identifier for the locale you need.
Then pinpoint the exact location where the XMLSchemaMessages resource bundle is loaded, and set a breakpoint so you single step through the ResourceBundle loading procedure in the JRE (a JDK is recommended here, so you have source for the runtime) and you can see what is being searched for.
Note: You are dealing with a vendor specific XML Parser here meaning this will be Oracle specific and may even only work on some Java versions. Considered bringing in your own validating XML Parser and localize it instead?
The above answers took me a little while to work out.
Just to make it easier for others, here's my summary of how to get Locale specific error messages to appear if you try parsing an XML document using XML schema with Java's internal Xerces parser:
Find an appropriate properties file in the format
XMLSchemaMessages_<lower_case_language_code>.properties
For Italian I found XMLSchemaMessages_it.properties on the following site (which might be an old version, but it worked for me)
http://grepcode.com/file/repo1.maven.org/maven2/com.sun.xml.parsers/jaxp-ri/1.4.5/com/sun/org/apache/xerces/internal/impl/msg/XMLSchemaMessages_it.properties
I then created a directory structure in my temp directory to hold the new file
com\sun\org\apache\xerces\internal\impl\msg
Since jar files and zip files share the same format (and I'm lazy and today I was using Windows), I then zipped the above com directory, creating a file called com.zip. I then changed the name of the file
rename com.zip to XMLSchemaMessages_Locale.jar
and then moved the new jar file to
C:\Program Files\Java\jdk1.7.0_04\jre\lib\ext
Of course the above path depends on your platform and specific version of Java (I was using Windows 7).
Instead of zipping, if you have JDK you could easily build the jar file using the command-line jar command, from Unix, Linux or Windows.
I use Project Options / Version to manage the version info (N.N.N.N format).
Anyway inside my project I duplicate those info.
So if in project options I am working on release 2.4.3.178
inside my application I have 4 integer variables that hold the 4 numbers.
I manually set them
Major := 2;
Minor := 4;
Release := 3;
Build := 178;
The reason of this is simple: I have licensing based on version number. So if the user buys release "2.4" it is not allowed to upgrade to version "3.0".
But if I rely on project version info the user can (with Resource Hacker tools) change the version info and therefore "activate" the product.
The user cannot change the 4 variables in the same way (not as easily at least).
This works but forces me duplicate the info.
Could you suggest a better approach?
Otherwise said: is there a way to write the version info using the data I write in those 4 variables. Something like in Post Build Events, but how do I pass data to post build events?
You'd need a pre-build event rather than a post-build event since you'd want to get the .res file built before linking.
I do something very similar with a simple Perl script that reads an include file (.inc) containing constant declarations of the version numbers. I read them in using a regex and then create my .rc file which I pass to brcc32. It's all invoked as a pre-build action.
Since you're on Delphi-XE and have Final Builder, why don't you put it to good use and make your "final" build from it? It can give a very nice solution to the version number problem, and can do a lot more.
Here's how I'd do it.
Set up a small INI file that holds the relevant parts of the version information.
Optionally make a small Delphi forms application that reads the version number from the INI files and gives you a chance to change it. When changes are saved to the INI file, the delphi application should automatically generate a small Delphi PAS file that defines the constants!
Create a FinalBuilder project that does the following:
Calls your Delphi exe to set up version number. You'll be in charge of changing whatever needs changing, and this is probably appropriate since your licensing scheme depends on version information.
Set up a few project variables to hold the version information numbers
Add "Read INI file" actions to read the version information from the ini files into your project variables.
(optional) Build the unit test project, if you have one.
(optional) Call the unit test project.
Add a "build Delphi project" action, set it up to build your project using whatever options you need. Add a small "Before" script to set up the version information numbers to what you've got in the project variables you just read from the INI file.
(optional) create setup packages using whatever tool you use.
(optional) upload those setup packages to a website.
In other words, take the opportunity to start using Final Builder.
Moving your version numbers into code is also easy to get around.
One way to pass the information is to generate a version.rc file programmatically (you write a tiny build tool yourself using delphi or a scripting language of your choice), and link the resources to the program, instead of using the built in version-info feature.
Your question seems to be fundamentally a matter of preventing the user from modifying (easily) the version number once you have determined it.
So my suggestion is that you encrypt the version number and you use the encrypted version, instead of the version in the VersionInfo structure.
I have used DCPCRYPT for things like this. But if you hope to be hacker-proof let me just say this; Anything you can do, hackers can undo. If you want to be more secure, you will also need to tamper proof your whole application. There are commercial tamper proofing solutions but none work fabulously out of the box with Delphi.