Solution
Localizing .NET applications
Alchemy Catalyst is a Visual localization tool designed to parse compiled .NET Framework applications. The support is for WinForms, .resx, WPF and even Hybrid files.
All versions of .NET Frameworks are supported, from 1.1 to 4.6.
.NET uses a common language runtime enabling the use of Culture (language) specific resources deployed in the form of satellite assemblies. Satellite assemblies include only resource files, they do not contain executable code.
Applications consists of a Main assembly and satellite assemblies for the default or neutral culture (language). Then separate satellite assemblies are generated for each Culture to be included.
Using the user's language settings (set in Control panel > Region > format), the .NET Framework loads the satellite assemblies in the matching Culture directory to display the resources. If that Culture (for example fr-FR for a French user in France) is not found, the default assemblies are used as a fall back method.
General translation process with Catalyst
Project files are created within Catalyst which parses all the localizable resources found in the compiled assemblies (.exe and .dll files). This includes version, menus, dialogs, graphics and string tables.
With only the localizable elements exposed in Catalyst, a localization engineer can add metadata to the project (locks, memos, keywords, context links, max length) and use the Leverage Expert to automatically apply any existing translations from Translation Memories. The project can then be passed on to a translator.
Once translation is complete, Catalyst's Validation Expert is ran to catch all common translation mistakes and greatly reducing the amount of Localization bugs introduced.
The final step is for Catalyst to generate the satellite assemblies which are automatically placed into a folder labelled with Cultures language code. This folder name is based on the Catalyst project's target language.
Note: With WinForms satellite assemblies (and .resx files), Catalyst includes the option to "Extract only modified resources".
This options is found in FILE > Options > .NET Framework.
|
 |
Localizing .resx resource files or compiled .NET assemblies
Catalyst supports both .resx and compiled binaries (.exe & .dll), and in both cases no configuration of parsing rules is necessary. As we advise with Win32 files, localizing compiled binaries in Catalyst is a better option considering the following benefits:
- Full Visual View in Catalyst with all referenced assemblies loaded.
- Source code is undisclosed.
- Translated satellite assemblies are ready for localized application.
- Extracted from Catalyst, the satellite assembly can be tested immediately in a test build.
- No recompiling needed. Localization bug fixing is easier and faster.
- Work with one binary file instead of multiple .resx files.
Referenced assemblies
In order to generate a visual display of the Forms and BAML dialogs Catalyst uses the .NET Framework to emulate the UI. Consequently all referenced assemblies need to be available to successfully display dialogs in their intended layout.
Catalyst gives invaluable feedback when inserting assemblies into a project. This feedback is listed in the Results window. For example, here is a standalone WPF application inserted successfully. The Results window reports no missing referenced assembly:
If the assemblies inserted in a Catalyst project depend on referenced assemblies to render dialogs and forms, the later need to be present in the same directory. Catalyst loads all referenced assemblies along with the main assemblies. Although referenced assemblies are not visible in Catalyst's Navigator Window, they are loaded and available for the .NET Framework while emulating the assemblies' code.
Example, if you are inserting MyApp.dll which has 2 referenced assemblies (filea.dll and fileb.dll), those 2 referenced assembly files need to be in the same folder as MyApp.dll. With the files present, the Results window will not report errors. If missing, the Results window will warn on each missing referenced assembly.
 Although it is possible to insert and translate assemblies in Catalyst without the referenced assemblies available, it is not recommended as important information is missing.
Example of missing referenced assembly on inserting a main assembly in Catalyst. The Form displayed in Visual View is missing resources:
The same form in visual view with the Referenced assembly present on insertion:
Signed or Strong-named assemblies
Assembly signing (also called strong-name signing) gives an application or component a unique identity that other software can use to identify and refer explicitly to it. A strong name consists of its simple text name, version number, culture information (if provided), plus a public/private key pair. This information is stored in a key file.
Localizing a signed main assembly requires the localized assemblies signed also. The key file (.snk) can be configured in Catalyst's options under FILE > Options > .NET Framework.
Often the private key file is not available to the localization team, or even development team until the product release. The public key however is often available. In this case, you may opt to delay sign the satellite assemblies. Select "Auto detect public keys and delay sign satellites on creation" option as seen in screenshot above.
Microsoft reference on delay signing: https://msdn.microsoft.com/en-us/library/t07a3dye.aspx
Delayed signed assemblies
|
Delayed signing refers to a technique of partially signing dlls while they are in the development or localization phase. It is achieved by using a public key to encode parts of the assembly. The public key is embedded in the assembly and can be used by third-parties who want to reference the assembly.
There are many more benefits to signing an assembly, but the main purpose of delayed signing is to allow a company to protect and control the private key and only use it during the final packaging process. The public key can be issued to third parties such as localization service providers allowing them to delay sign the assembly. Delay signed assemblies can be used for test purposes, but should not be shipped as they are not fully protected.
The private key can be later applied to a delay signed assembly. Full signing, in this way, completes the security process and can only be done by the software company using the private key that they maintain under their own control.
As a security measure, Catalyst can only insert fully signed or unsigned dlls. Delay signed assemblies cannot be inserted.
If you are working with delayed signed assemblies, you can turn the verification of the signature off. Sn.exe which deals with .NET signing (a Microsoft executable, see https://msdn.microsoft.com/en-us/library/k5b5tt23.aspx) is included in the Catalyst install folder. Using this tool, you can prepare the assemblies by turning off its signature verification.
Run the –Vr option with the filename in question:
|
sn.exe –Vr myAssembly.dll
|
Once done, Catalyst will insert the assembly without complaining that it is delayed signed (you have to restart Catalyst if it is running when you do this).
Use either of the other options highlighted in the sn.exe help screenshot to revert the verification skipping.
|
 |
Obfuscated assemblies
In .NET, the inner workings of assemblies can be examined using tools such as .NET Reflector or ILSpy. This can reveal a lot about what a DLL does and how it works. This is useful from an openness and transparency point of view, but less so from the point of view of protecting intellectual property.
To hide code and algorithms and to protect their intellectual property, assemblies can be obfuscated. Obfuscation is a process that encrypts class and function names so they are no longer readable. The downside is that this process also encrypts the information Catalyst uses to load these assemblies either as referenced assemblies or for localization.
If you are localizing assemblies which are obfuscated, you will need to require unobfuscated copies of the assemblies. The localized satellite assemblies can then be obfuscated along with the main assemblies.
Related topics
Products or Versions Affected
Last edited with Catalyst 11 Sp1
|
