Hexadigm Systems
Home of TranSolution
Localize your Microsoft Visual Studio .NET solutions with ease
For both developers and free for translators

Product Overview

Thanks for taking the time to review TranSolution, a localization package that greatly simplifies the process of translating your Microsoft Visual Studio .NET solutions into foreign languages for international markets. TranSolution consists of two applications, a Visual Studio add-in that programmers use to bundle up all strings in their solution into a single file for shipping to a translator, and a simple yet powerful application that the translator will use to read this file and translate the strings. Translators may obtain a free, permanent copy of this on our free downloads page - no "strings" attached. After translation is complete, the same add-in is then used to import these strings back into the programmer's solution.

TranSolution is extremely intuitive and requires very little effort to learn. From the programmer's perspective, the translation process simply consists of loading their solution in Visual Studio and running "Tools -> Translate -> Outgoing". After filling in a couple of simple dialogs, the program will then extract all ".resx" based strings in the solution and bundle them up into a single file for translation. A sample of the main outgoing dialog can be seen below:

After clicking "Proceed" on the above dialog, the translation file is created and can then be sent to a translator who will translate the strings using the free translator's version of the application (or you can translate it yourself using our "Translate from the web" feature). Note that the translator's version is a standalone application that doesn't rely on Visual Studio whatsoever. It's very simple to use, contains many practical features and safeguards (read on), and unlike other translation products, isn't dependent on 3rd-party programs like Microsoft Excel or Notepad. Other products often expect translators to rely on these programs to translate your strings. This is not only error-prone, but it lacks the functionality of a dedicated translation program. For instance, what happens if your translator doesn't translate "File {0} not found" correctly because they accidentally mishandle the "{0}" composite formatting item. Errors like this might not be caught until your product crashes after release. TranSolution not only enforces the proper handling of this and other scenarios, but it also conducts extensive checks when the programmer imports the translated strings back into their solution (for instance, warning when strings are encountered that the programmer may have changed or deleted since outgoing translation). See Program Features for further details. A sample of the main translation window seen by the translator is shown below:

This window is basically WYSIWYG. Simply translate the "Default Language" into the given target language(s) and return the file to the client programmers for importing back into their solution (or translate it yourself using the "Translate from the web" feature). Note that the work can even be parceled out to multiple translators (see "Importing" and "Exporting" in online help). Also note that for strings which originate from any Windows forms and user controls, the translator can (optionally) translate these strings using a tailored version of the Visual Studio forms designer. This feature is provided without relying on Visual Studio whatsoever. The translator simply needs to press <Ctrl+R> on any form-based string (those with the symbol in left-hand column of the above grid) and this will launch a special dialog containing the form or user control that the string originates from. A sample of this can be seen below:

Using this dialog, the translator can see the programmer's form in context and translate it using the property grid on the right. To accommodate strings of varying length, they can even adjust the size and/or location of any control on the form, similar to the forms designer in Visual Studio (assuming the programmer grants these permissions when the translation file is created). Note that strings which haven't been translated yet even appear on the form in red as a visual cue for the translator. Once the translator clicks OK, he/she is then returned to the main grid above which will now include the updated strings.

When the translator is finished translating, the file will  then be returned to the programmer who can integrate the file back into their Visual Studio solution. To do so, the programmer simply needs to load their solution again but this time run "Translate -> Incoming" from the "Tools" menu. The following dialog then appears:

After inputting the name of the translation file and selecting the target resource (".resx") files and languages (all of them usually), TranSolution will then update the solution with all strings in the translation file, effectively translating the application (and recording all changes in the Visual Studio output window).

This system is not only extremely easy to use, requiring virtually no work on the part of the programmer, but it greatly reduces the tedious and error-prone process of translation that programmers have always had to deal with. Translators will also benefit tremendously from our highly intuitive (and free) translation program.

Why not use a "free" localization tool?

Why should you pay for a product when you can get one for free? If you can find a comparable product that's reliable based on its reputation, then you probably shouldn't. Other issues may also factor into your decision, but in the end, everyone wants a free tool, which is completely understandable. If there was one out there that was actually comparable to TranSolution however, then TranSolution never would have been developed. The fact is that we've tried most of the free tools out there, and while some may look polished on the surface, with favorable reviews and maybe even a popular following, all of them lack the critical safeguards necessary to do a reliable external translation. Don't believe it? Try changing a string in your solution and see if any of these "popular" programs detect it. When a programmer changes a string, it renders all of its translations obsolete of course, and in need of updating, but this is never flagged by any free tool we've ever tried. So do these tools really expect you to manually track these changes yourself, and then notify your translator somehow? This is not only laborious and very expensive, but highly error-prone. Morever, what happens if you simply change some of your strings while they're out being translated. This happens all the time in real life of course, but what happens when your translation tool's import feature is later run. Surprise! Your free ("polished" and "popular") tool just quietly overwrote the changes you made to your solution's strings, possibly even adding back (duplicating!) strings whose key you may have renamed in your solution (so you now have both the renamed string in your ".resx" file AND the one with the old key). In fact, though it's bewildering, all commercial products we've ever tested do the same thing as well (and you pay for that product!). These and other significant issues exist in all free products we've ever tested and some commercial ones as well. Sometimes there are also obscure and subtle issues to deal with that few competitors would be aware of unless they have a lot of experience, but we won't get into the details here. You just need to exercise caution when choosing a localization tool, free or otherwise, to make sure these issues don't exist (unless you can live with the expensive problems that inevitably result).

System Requirements

Microsoft Windows 10, 8/8.1, 7 or Vista (32 or 64 bit)
Developer's version: Microsoft Visual Studio 2005 to 2017 (Microsoft .NET 3.5 or later)
Translator's version: Microsoft .NET 3.5 or later

Program Features

  • Extremely easy to use with almost no learning curve. WYSIWYG
  • Developer's version integrates right into Microsoft Visual Studio 2005 to 2017. Appears as a new item ("Translate") on the existing "Tools" menu. Just choose "Outgoing" or "Incoming" and you're on your way.
  • In Visual Studio, use "Tools -> Translate -> Outgoing" which scans your Visual Studio .NET solution and bundles all strings into a single file for shipping to your translator (or you can translate it yourself using our "Translate from the web" feature). Your translator can then translate the file using the free translator's edition of TranSolution, a standalone application that doesn't require Visual Studio. When the file is returned, simply import it back into your solution using "Tools -> Translate -> Incoming". This completes the translation of your application.
  • During outgoing translation, TranSolution automatically detects strings that have changed since the last outgoing translation and prompts the user to either clear the existing translations for retranslation (they'll be reset to blank in the above grid), or highlight them for review instead (they'll be highlighted in red in the above grid). It's your choice. Other checks are also conducted, such as warning the user about strings that have leading and/or trailing whitespace, duplicate keys in ".resx" files, etc.
  • Unlike any other localization program we're currently aware of (and truly a must-have feature), you can continue to make changes to the strings in your solution even while they're out being translated. Any conflicting changes will simply be brought to your attention during incoming translation. Usually these will be strings that no longer match what was shipped for translation (because you changed them in your solution), but other issues will also be brought to your attention as required.
  • A complete record of all translation changes is written to the Visual Studio Output window during incoming translation (including any warning messages the user may need to respond to)
  • Programmers can include or exclude any ".resx" file(s) they wish from the translation. "Resgen.exe" compatible ".txt" files are also supported.
  • Programmers can exclude any individual string(s) from the translation. A callback feature allows developers to plug in their own callback method which is invoked for each outgoing string. Just return true to bypass the string or false to process it. When bypassing a string, you can therefore do so based on any criteria you require.
  • Programmers can select any target languages for the translation
  • You can rely on a professional translator to localize your strings or do it yourself using our "Translate from the web" feature (you can even highlight strings that were translated this way). Note that the "Translate from the web" feature can also be easily disabled during outgoing translation, assuming you don't want your professional translator to use it.
  • Translators are forced to respect "composite format" string arguments, e.g., if the string "File {0} not found" is being translated, the translator will be forced to include the "{0}" in all translated strings. Other consistency checks are also conducted between the string being translated and its translations, such as ensuring the same number of lines are present, the same leading/trailing whitespace is present, the same number of internal tabs are present, etc. All checks are conducted on a per-line basis as required (e.g., if line 3 in a multiline string has a "{0}", then a warning occurs if line 3 in the translated string doesn't have a "{0}"). Please note however that whitespace checks don't usually apply in ASP.NET projects (applicable to ".aspx", ".ascx" and ".master" files only), since whitespace is normally irrelevant here (i.e., when your program runs, all such space is condensed to a single space as per standard HTML rules).
  • In Windows form applications, translators are forced to respect access keys (AKA hot keys or accelerator keys), e.g., if a control string labeled "&Next" is being translated (which appears to the end user as "Next"), the translator will be forced to include an '&' in all translated strings (and is warned if another control on the form contains the same access key)
  • In Windows form applications, translators can (optionally) view any Windows forms in your application using the "Form View" feature and translate the strings in this environment, similar to design view in Visual Studio itself (but restricted to only those properties that translators need to change - "Text", "Size" and "Location" - read on)
  • In Windows form applications, programmers can optionally allow the translator to adjust the "Size" and/or "Location" of form-based controls in the "Form View" window (to accommodate small changes that may be required to fit strings of varying length). Programmers can also optionally restrict these changes to the default language form only if they wish (meaning that the translator can adjust the size and/or location of controls on the default language form only - translators won't be able to modify them for specific languages since they'll be inherited from the default language form).
  • In addition to the "Form View" feature above, translators can also create satellite assemblies for the client developer's actual program if it's installed, allowing them to see the results of their work in the developer's live application. Note that certain limitations may apply (see the "Create satellite assemblies" feature in online help for details).
  • Programmers can optionally prevent translators from modifying strings that have already been translated. These will be read-only for the translator.
  • Translations can be "flagged for review" before sending them to your translator. They'll then be highlighted in red and your translator must "approve" them to clear the highlighting. Note however that translations whose default language (source) string is changed are automatically flagged for review on request. Translations using our "Translate from the web" feature are also flagged for review automatically (since translations from the web are inherently error prone).
  • In Windows form applications, programmers need not explicitly turn on the "Localizable" property for every Windows form in their solution (which is required by Visual Studio to support Windows form localization). TranSolution will detect these and automate the process on request.
  • Translators can optionally copy duplicate strings to other rows automatically, e.g., if the string "Cancel" is translated on a given row, its translation will automatically be propagated to all other rows that also contain the string "Cancel" (ensuring consistent translations for duplicate strings)
  • Translators can export one or more languages to another file if they need to parcel the work out to other translators (which can be imported back into the main file later)
  • Translators can hide one or more language columns so they can focus on selected languages only (typically one language at a time)
  • Translators can hide rows that have been completely translated so they can focus on only those (incomplete) rows that remain
  • A cost calculator allows programmers and translators to display word counts and the cost of translating those words for either the entire translation itself, or for individual languages (if more than one)
  • Translators can conduct advanced string searches including regular expression searches. Searches may be confined to a single language column only or conducted column-by-column (down and across) or row-by-row (across and down). Searches can also be flagged to ignore access key ampersands (e.g., searching for "Next" will locate cells that also contain "N&ext").
  • For strings that are too long to fit their cell, translators can turn on wrapping via the "Optimize size of all cells" setting. They can then see each string in its entirety. When the setting is off (the default), an ellipsis terminates each string instead (but the entire string can still be displayed in a tooltip by hovering the mouse over the cell). Wrapping is turned on automatically however when the translator is editing a cell.
  • Tool tip in the main translation window displays the origin of each string in the programmer's solution (by pausing the mouse in the far left-hand column of any row)
  • Supports "translation memory" using the program's "File ->Import" feature. You can translate the strings in one solution by simply importing the ".trn" file for another (already translated) solution into it. Any common strings will be translated accordingly.
  • Supports integrated source control packages such as Team Foundation Server (TFS) and Visual SourceSafe (your files will be checked out as required during incoming translation)
  • Translators can use the "File ->Save As" feature to convert your ".trn" file to Microsoft Excel (".xlsx") or Comma Delimited Value (".csv") files (for use in 3rd-party programs). Please note that importing this data back into TranSolution is not currently supported for safety reasons (translation outside of TranSolution isn't advisable).
  • Comprehensive online help
  • Developed exclusively using Microsoft tools only. We believe this ensures greater stability by not relying on potentially unstable 3rd-party code.
Copyright © 2017 Hexadigm Systems. All Rights Reserved.     Legal Notice