No new features were added to the translator's version in this release. Only support for Visual Studio 2022 was added to the developer's version. See Version 4.1 in the developer release notes. IMPORTANT: The format of the ".trn" file was slightly changed in this release to accommodate ongoing changes by Microsoft. The only impact is that attempts to use the "Create satellite assemblies" feature in version 3.8 or earlier will result in an error if the ".trn" file was created in version 4.1 or later (the error is "System.FormatException: Input string was not in a correct format."). If this occurs when using the "Create satellite assemblies" feature in version 3.8 or earlier then you must download the latest version (4.1 or later) to eliminate the error (a harmless requirement). Note that all users are encouraged to download this version regardless (it's backwards compatible with all previous ".trn" files).
This version number was skipped to prevent confusion with .NET 4.0. Users using 3.8 or earlier will therefore upgrade to the latest version instead (4.1 or later).
This version contains a rare bug fix in the developer's version only (see the Version 3.8 developer's release notes for details). The translator's version remains unaffected.
This version now supports Visual Studio 2019. In addition, as of April 30th, 2019, the "Translate from the web" feature will no longer work in previous versions of TranSolution (V3.6 and earlier). Microsoft discontinued (disabled) the API that those versions relied on and replaced it with a new API which TranSolution V3.7 now utilizes. Users who rely the "Translate from the web" feature must upgrade to this release.
This release contains mostly minor internal changes only. The only significant changes are:
This version number was skipped to prevent confusion with .NET 3.5. Users using 3.4 or earlier will therefore upgrade to the latest version instead (3.6 or later).
The translator's version in this release now supports a form of "translation memory" using the existing "File -> Import" feature. In previous versions, this feature would only allow you to import ".trn" files originating from the same solution. In this new release, you can now import any ".trn" file into any other and the translations for all matching strings will be imported accordingly. This allows you to import the translations for common strings from one solution into another. Moreover, in previous versions, if the client developers renamed a string's key in its ".resx" file, or moved a string to a different ".resx" file (though renaming the key is far more common), and then attempted to import an older ".trn" file into a newly created ".trn" file (with the renamed or moved string), then the string would no longer be found in the import file because its key and/or ".resx" file had changed (and hence the translations for this string in the old ".trn" file could not be imported into the new ".trn" file). This would typically occur if the translators were still working on the old ".trn" file but now had to import it into a new ".trn" file, as shipped to them by the client developers (again, where one or more strings were renamed or moved). Under this scenario, previous versions only supported importing of translations for strings whose name (key) and ".resx" file hadn't changed, though in practice such changes don't occur too often. Nevertheless, this limitation has now been removed (i.e., when importing, a string is first looked up in the import file based on its name (key) and ".resx" file, but if the string isn't located because its name (key) and/or ".resx" file has changed, then the program will now look the string up based on the value of the default language string itself - this will usually be found unless the value was also changed by the client developers and no such string with that value exists in the import file). Finally, please note that some import warning messages have been modified in this release and in some cases enhanced to include additional response buttons for certain warnings. The actual warning codes themselves have not changed however, though some new ones have been added.
This release now includes the ability to save your ".trn" file as a Microsoft Excel ("*.xlsx") file. You may choose this by launching the "File -> Save As" dialog and selecting "Microsoft Excel (*.xlsx)" from the "Save as type" dropdown. Click the "Help" button on this dialog for further details.
No new features were added to the translator's version in this release. Only support for Visual Studio 2013 was added to the developer's version.
This release contains no changes in the translator's version. Only the developer's version is affected. See the developer's version release notes for details.
This release contains the following new features:
Note that the developer's version also contains one or more new features. See the developer's release notes for details.
The translator's version in this release contains no new features. However, an important fix was introduced and all users are advised to upgrade at their earliest convenience. The hotkey "Ctrl+Alt+L" was changed to "Ctrl+U" in this release to eliminate issues when using "Ctrl+Alt" in any Windows program. "Ctrl+Alt+L" was assigned to the new "Copy default language to current cell" feature that was introduced in version 2.5. However, because "Ctrl+Alt" is effectively equivalent to the "AltGr" key, its use as a hotkey can prevent the use of "AltGr" when entering special accents, symbols, etc., depending on the keyboard and target language being translated. The use of "Ctrl+Alt" was therefore a mistake on our part, though please note that this issue would not have adversely affected your translations or ".trn" file in any way. The use of "Ctrl+Alt+L" would simply have activated the new "Copy default language to current cell" feature instead of entering the required special symbol or accent (which would have been immediately noticed). We apologize for the inconvenience.
This release contains several new features, improvements and changes as follows:
No new features were added to the translator's version in this release. However, in
previous versions, 3rd-party assemblies stored in the TranSolution "CodeBase" folder
(in support of the "Form View" feature) had to be strongly-named due to .NET security
restrictions. TranSolution is no longer hampered by these restrictions so 3rd-party
assemblies no longer need to be strong-named. See "3rd-Party Controls" in online help
for further details. (UPDATE - January 22nd, 2013: The MSFT bug described immediately
following this sentence has now been repaired by MSFT - see UPDATE further below).
Finally, please note that if .NET 4.5 is installed, you may experience an annoying
but otherwise harmless Microsoft bug, whereby the "File" menu may be activated when
ou attempt to launch any other menu (the "File" menu is merely highlighted however,
it doesn't actually drop down). This normally occurs just once, right after opening
a ".trn" file, or sometimes if you simply select any item on the "File" menu. It then
corrects itself until another file is opened (or the "File" menu is activated again),
after which it corrects itself again. However, we can't be sure if it occurs under
other circumstances as well. The problem is confined to machines running .NET 4.5 only,
and it's already been reported to Microsoft by Hexadigm Systems and others. At the time
of release, we're currently awaiting feedback on a resolution. Once we receive word,
these release notes will be updated. Note that a message will alert to you this situation
if .NET 4.5 is detected on your machine, which occurs just one time only (the message
appears the first time .NET 4.5 is detected and won't appear again). As described in
the message itself however, for ".trn" files originating from programs targeting versions
of .NET prior to V4.0 (V3.5 or earlier), the bug can be eliminated by commenting out the
following line in "TransView.exe.config" (in the program's installation folder):
<supportedruntime version="v4.0" sku=".NETFramework,Version=v4.0" />
While not recommended unless this issue adversely affects your user experience (the
problem becomes too annoying), administrator rights are normally required to update
the above file, and once updated, the line should appear as follows:
<!--<supportedRuntime version="v4.0" sku=".NETFramework,Version=v4.0"
/>-->
We apologize for any inconvenience this situation may cause, but will do our best to
resolve the situation if possible (assuming Microsoft doesn't release a fix in a
future .NET service pack)
UPDATE (January 22nd, 2013): Microsoft has now issued a fix for the .NET 4.5 bug
described above. The fix is downloaded automatically as part of the latest
Windows updates. If your machine is configured for automatic Windows updates,
you should receive the fix the next time your machine downloads and installs
these updates. It can also be downloaded and installed independently at
either of the following U.S. locations at this writing, depending on your
platform (the first for Windows 7 or earlier, the second for Windows 8):
http://www.microsoft.com/en-us/download/details.aspx?id=36359
http://www.microsoft.com/en-us/download/details.aspx?id =36377
For further details on the bug itself, see Microsoft Article ID 2750147 or
2750149. In both cases, the issue is briefly described in issue #1 under the
section entitled "Windows Forms".
This release contains a single (cosmetic) bug fix only. In previous versions, when the "Hide completed rows" option was on (as seen on the "View" menu), it was possible for the alternating colors seen in the left-most column to appear incorrectly. Specifically, the same alternating color used to identify one file may have incorrectly been used to identify the file that immediately preceded and/or followed it. This made two or more consecutive files appear as a single file only, since the same color was applied in each case. This only occurred however once the last row for a given file was hidden, and would correct itself if the "Hide completed rows" option was turned off and then back on again. This problem has been fixed in this release and is considered important but not urgent. Existing users are advised to upgrade at their own convenience.
This release contains one minor change only. The "File -> Import" feature will now work even after incoming translation has been run on the currently loaded file. Since the currently loaded file is always open in read-only mode after incoming translation, modifications to the file aren't normally allowed. In previous versions, this applied to any features that could change the file, including "File -> Import". This restriction has been relaxed in V2.2, and a file can now be imported even in read-only mode. A warning will notify the user first however, since incoming translation was already run. Note that this change was implemented to support the following scenario, and normally shouldn't be used for any other purpose. If a developer runs outgoing translation, creating, say, "Employee.trn", and then immediately runs "File -> Export" in TransView, creating, say, "Employee.es.trn" for shipping to a Spanish translator, and "Employee.de.trn" for shipping to a German translator, then both exported files will likely be returned to the developer at different times. If "Employee.es.trn" is returned first, then the developer may want to run incoming translation without having to wait for "Employee.de.trn" to be returned. The developer should normally do this by first running "File -> Import" on "Employee.es.trn", updating the main (master) ".trn" file accordingly, and then running incoming translation on the latter file. After doing this however, the main ".trn" file can only be opened in read-only mode since incoming translation was already conducted. In previous versions, "File -> Import" would therefore no longer work, so when the German file "Employee.de.trn" was returned, it could therefore not be imported into the main ".trn" file without first running outgoing translation again. This was inconvenient and unnatural, so "File -> Import" will now work as described. "Employee.de.trn" can therefore be imported into the main ".trn" file even after incoming translation has already run, and once it is imported, incoming translation can simply be run again. When doing so however, a harmless warning will notify the user that incoming translation was already run, but the warning can be safely ignored without issue.
This release contains two minor changes affecting the developer's version only. The translator's version remains unaffected. See the release notes for the developer's version for details.
This release contains major upgrades and various internal design changes primarily supporting two new features:
Other miscellaneous changes were also introducted in some areas unrelated to the above changes (e.g., ".trn" files can no longer be updated after incoming translation - they are now opened in "Read-only" mode). Existing users may therefore notice some minor behavioral changes, updates to messages, and possibly other small changes, but nothing that significantly impacts the overall design. Note that a confirmed Microsoft bug was also corrected in this release, whereby translations wouldn't be saved to file if the user scrolled the mouse wheel while "edit mode" was still active in "Grid View". Only the cell that was being edited at the time the mouse wheel was scrolled was affected however. Any changes to the cell wouldn't be saved to file when edit mode ended. An investigation eventually turned up a bug in Microsoft's native "DataGridView" control which was officially confirmed by Microsoft. They won't be correcting the problem however so a permanent workaround was introduced. The problem has now been eliminated and we apologize for this issue.
This release contains a single bug fix for a harmless but annoying problem. Existing customers are advised to upgrade from earlier versions but the fix is not considered urgent (though it is highly recommended).In previous versions, when editing any cell in "TransView" (in the "Grid View" window), it may not have been possible to position the cursor at an arbitrary location within the cell's text by using the mouse. Depending on how you navigated with the mouse, edit mode could also end before you were finished updating the text. This problem could be very annoying if frequent changes were occurring but was harmless otherwise. Due to the inconvenience this could cause a translator however, and the general reduction in productivity, a new release was warranted. Note that in addition to the other ways edit mode can be started (F2, etc.), it can also be started by first moving into the cell and then single-clicking it. The cell must be made the current cell first however. That is, if you click a cell while another cell is still the current cell, then the cell you click will become the current cell but edit mode won't start until you click it again. This is standard Microsoft behavior for the grid. Once the cell does become the current cell however, single-clicking it will highlight the cell's text and edit mode will start. Double-clicking it will also start edit mode but will immediately move the cursor to wherever you click the text. In either case, once edit mode starts, you can then single-click any character in the text to move the cursor to that location, or double-click it to highlight the word itself. Some or all of this behavior may not have worked in previous versions.
This release contains a work-around for the (rare) issue described below. Existing
customers are advised to upgrade from earlier versions but note that no new functionality
has been added. Earlier versions are considered stable however so customers may upgrade
at their own convenience (in particular, if you've encountered this issue):
In previous versions, it was possible to encounter an error message when trying to
open a ".trn" file, indicating that the file "... is not accessible for both reading
and writing ...". This message occurred by design since the application previously
required full security rights when opening ".trn" files for writing. This was not
an issue for most users however, since a file that allows "write" access to the
calling user usually allows full access. If full rights were not available however,
the above message would occur. The required rights when opening ".trn" files was
therefore reduced to eliminate this problem.
This release contains three new features:
Note that these new features are enhancements only, and don't affect the actual translation process. Existing customers are therefore advised to upgrade at their own convenience, but no urgency is required.
This release contains minor corrections and adjustments only. Existing customers are advised to upgrade from all previous versions but note that no additional functionality has been added. All previous versions are considered stable however so customers may upgrade at their own convenience.
This release contains minor corrections and adjustments only. Existing customers are advised to upgrade from version 1.0 but note that no additional functionality has been added. Version 1.0 is considered stable however so customers may upgrade at their own convenience.
Initial release