(Very) key performance improvements:

Visual Studio IDE:
When adding translation languages to your project, MAT creates a XLF file and matching target resource files. Most projects would have seen a small delay after clicking ‘’OK’ on the ‘Add translation languages…’ dialog. However, the more source resource files your project has, the worse the impact would be.  WinForms / ASP.Net project use separate RESX file, creating a high potential to see an unusable impact from this issue.

However, unbeknownst to us, the ‘design time build’ was secretly (or not so secretly for some) creating a build for each added resource file. This caused the Visual Studio IDE to appear ‘frozen’ for several seconds to several minutes or more!! Working with the Visual Studio team, we were able to suspend the ‘design time build’ until after all the XLF and resource files were added.

MAT builds:
XLIFF files require validation - which is a very expensive operation. Sometimes it is unavoidable and will directly impact MAT’s performance. I have some good news to report in this area. We found a call to validation that was not providing any additional value. Removing that specific validation had a significant performance improvement in MAT’s build processing time. The improvement will depend on several factors, but our tests indicate most will see a significant improvement from the RTW build times.

Another side-effect was when key files are saved (XAML, Resource, etc.), the ‘design time build’ would start. Depending on the build performance, you would see a delay in the Visual Studio IDE. The combination of the improved build performance and MAT’s build caching logic should provide noticeable improvements in Visual Studio IDE responsiveness when using MAT.

UWP Shared projects:
The ‘Enable selection’ option for Shared Projects (from Windows -> Classic Desktop) was grayed out preventing MAT support for this project type. Support for the project type was added in this update.

C++ DirectX & XAML projects:
C++ DirectX & XAML app (Universal) projects enabled with MAT would not reload. The project modification required by MAT incorrectly placed the MATPrerequisite Target in the ImportGroup node, causing the reload failure.

Xamarin projects fixes:
Xamarin iOS project resource files below the root node were exclude from the file scan logic. This prevented key resources files from being added to the XLF file, resulting in exclusion of resources from the localization workflow.

Xamarin Android projects using value-<screen dp> to manage device screen sizes were reporting “Culture is not supported” during the build. The screen size values was consider a culture value by MAT.

Acknowledgements:
The key improvements in this release would not have been possible without key developers around the world that contacted me to report issues. I want to thank several teams that contact me, and especially for those that installed private drops and tested the proposed fixes in their environments. Without this level of community support, the team MAT would not be able to provide targeted fixed that solve your real-world issues.

I’m specifically thankful to the team from 1Password by AgileBits Inc. (Twitter) for running multiple private builds at all hours of the day and night to verify key performance fixes in their environment. (And for the suggestions I did not have time to implemented yet.)

Changes and bug fixes:
As always, the complete list of the changes in this as well as previous releases are available on MAT’s User Voice site: Here is a direct link: https://multilingualapptoolkit.uservoice.com/knowledgebase/articles/460620

Thank you,
The Multilingual App Toolkit team
multilingual@microsoft.com
User voice site: https://aka.ms/matvoice

This release represents a major product redesign that enables developers of various projects to have a common localization workflow.  Just power up Visual Studio, install MAT v4.0, create and enabled your project, add some resources, select your languages, apply your translations (or use the built-in translation services) and run your app.  This is true for Windows 10 UWP, Windows 8.1 Shared apps, Windows Phone, WinFoms, WPF, ASP.Net, or Xamarin iOS and Android apps.

Many hours of work when into redesigning MAT v4.0 to work with some many different projects, but we could not have done this without the support of our great developer community.  While we received many issue reports with the various pre-release builds, I was always encouraged by the number of “Hey! I hit this bug and need a fix.” followed by “MAT is great - keep up the great work!”.

I owe a big THANK YOU to everyone that jumped on, used and provided feedback for the preview releases.  (This weekend alone, several dedicated developers ran private builds to help confirm we fixed key bugs for this release.)

As always, the complete list of the changes in this as well as previous updates are available on MAT’s User Voice site: Here is a direct link: https://multilingualapptoolkit.uservoice.com/knowledgebase/articles/460620

Thank you,
The Multilingual App Toolkit team
multilingual@microsoft.com
User voice site: https://aka.ms/matvoice

Shared project support for Windows 8.1 apps
This final beta release contains the much anticipated shared project support for C# apps.  This allows you to place your resource file(s) in the shared project and applying the translation to the shared project as well.  Adding this support required significant rework in the IDE integration design.  JavaScript projects can also be enabled, but C++ project are not supported by MAT for shared project.

Reducing Enablement confusion
”Hey, I selected ‘Enable’ but nothing happened”.  Does this sound familiar?  Unfortunately it probably does.  There are two conditions that cause this to happen.  The first one is when the project does not have a default culture defined.  Desktop templates such as WPF and WinForms require an extra step to define the default cultures.  The second condition is when no resources are defined in the project.  This is more common with Store projects as you need to add a resource file with the culture in the path - such as ‘en-US\Resources.resw’.  To make things worse, the output panel is hidden by default so you don’t see the problem unless you go looking for it.  We have take two steps to reduce this problem. 

The first is when a project can't be enabled, MAT will display a blocking dialog.  As a rule we try to avoid block dialogs, but in this case it just makes sense. 

The second change deals with projects that don't have any localizable resources.  Instead of blocking the ‘Enable’ step, the project is now enabled and a warning in added to the output panel.  The Add translation language dialog will remain greyed out and a build warning is created starting that the project is enabled, but not localization resource were found.

Bugs fixes
And as with any update several bugs fixes are included.  Specifically one pesky blocking bug in the editor that reports ”This type of CollectionView does not support changes to its SourceCollection from a thread different from the Dispatcher thread.” have been fixed. 

For a complete list of the changes in this as well as previous updates, please see the change log on our User Voice site: Here is a direct link: https://multilingualapptoolkit.uservoice.com/knowledgebase/articles/460620

Thank you,
The Multilingual App Toolkit team
multilingual@microsoft.com
User voice site: https://aka.ms/matvoice
v4.0 Technical Preview: https://aka.ms/matpreview
Twitter: @CameronLerum

This release is a service based release and as such does not contain any new features.  For a complete list of the changes in this as well as previous updates, please see the change log on our User Voice site: Here is a direct link: https://multilingualapptoolkit.uservoice.com/knowledgebase/articles/460620

Moving forward:
Two big work items that the team has been focused on is v3.1 –> v4.0 project upgrade and Shared Project support.  We consider this critical work that must be completed before we can declare v4.0 RTW. (And have received lots of feedback supporting this belief!)

Project upgrade:
Automatically upgrade of v3.1 to v4.0 project has been a pretty significant undertaking.  Depending on the project type, the XLF and resource file structures needs to recreated and in all cases the XLF file contents need to be remapped to the new design – all this without losing your translations.  A lot of work and focus has been placed on ensuing the this goes smoothly as well as ensuing that if something expected happens, you can recovered from your source control or the backup folder.  Needless to same, we need to get this right.

Shared Project support
Shared project support is another area that been highly requested.  Since a shared project does not work the same as other projects, supporting them has required many late hours to incorporate then in the toolkit’s workflow.  Updating the design to support adding and managing resources on the shared project resulted in going back to the whiteboard more than once. 

Dropping support for Visual studio 2012
Share project support is not available for VS 2012.  As such, we need to move to the VS 2013 SDK to enable shared projects.  We expect the impact of this move to be minimal, but we do know that some will be effected.  However, this is unavoidable as we need to support Windows 8.1 Shared Project and Windows 10 projects correctly. 

Help us get to RTW
While MAT v4.0 is still in beta, the adoption rate is climbing rapidly and is often used in production environments.  As such, we are looking for developers willing to install private drops of that contain both the v3.1-> 4.0 project upgrade and share project support on your existing projects.  Given the scope and project types that MAT supports, this will provide us with critical feedback to ensure the RTW release is rock solid.

I will publish the private drop location via this blog (and twitter) in the near future.  However, if you want to receive direct communication from me, please send an email or twitter message with #MATDROPS and I’ll be sure to send you the direct link this week.

Thank you,
The Multilingual App Toolkit team
multilingual@microsoft.com
User voice site: https://aka.ms/matvoice
v4.0 Technical Preview: https://aka.ms/matpreview
Twitter: @CameronLerum

  
I am excited about the release of the core XLIFF 2.0 Object Model on GitHub as it enables the creation of additional tools and vendor support for the XLIFF 2.0 standard.  Please check out the project and provide any feedback on the OM via GitHub.  Here is the direct link: https://github.com/Microsoft/XLIFF2-Object-Model

Thank you,
The Multilingual App Toolkit team
multilingual@microsoft.com
User voice site: https://aka.ms/matvoice
v4.0 Technical Preview: https://aka.ms/matpreview
Twitter: @CameronLerum

Translation Status Reporting
One of the challenge to shipping any software is to understand what feature are ready for public use.  This can be hard enough with a single language.  By adding additional languages to better support your users in around the world, you also added another ship ready consideration.

MAT has always provided resource translation state to help you manage your language quality shipping bar.  Automation Translations are set to “Needs Review” by default so you or your localizer can “Review” the translations and adjust as needed.  Build 4.0.1413 added the translation state summary to the editor’s stat bar, but for apps like Image Resizing for the Windows Phone that support more than 20 language, it can be hard to know when your translation state is ‘ship ready’.  This is where the Translation Status Report feature can help by providing translation status at glance.

The report is display by selecting your solution, project or specific XLF files in a project.  Simply right-click and select Multilingual App Toolkit->Translation Status Report to display the report. Note: This is also available from the Project Menu in the menu bar

As you can tell from the report, it is extremely easy to see the translation state of all the language in my Finger Speller Windows Phone app.

Importing and recycling XLF files
Importing and recycling allows you to bring external translation work back into your project.  For example, if you send your project’s German XLF file to a friend or localization vendor for translation, you need a way to import those translation back into your project.  You could just copy the file, but that is risky and will sooner or later cause you headaches because the returned XLF file might be missing resource, or was otherwise made invalid.  Using Export to send the resources and later Import to get them into your project is the best approach.

An explanation of the different between importing and recycling is important.  The two are very similar, but have key differences that is critical to using them successfully. An oversimplified explanation is that Import updates your project from files that were exported from that same project.  Recycling allows you to update your project from resource other than your current project.

Both Import and Recycle validate by checking the source and target languages match.  They also check to ensure the source string is an exact match (“Hello World” is not equal to “hello world”).  Additional checks are performed to ensure the translation being imported are more current. This is done by checking the Translations state.  (It would be bad to import a “Needs review” overtop of translation in the project that is marked as “Final”!)

Import also required an exact match with the resource Id.  Checking the resource Id ensures that two strings that have the same source value can have unique translation applied.  This ensures that each same source string translation will have their content are correctly imported.

Recycling is a looser compare.  It is only apply to resources with a state of “New’ in the project file.  This is required to avoid overwriting an import resource with a resource matched by recycling. 

Additionally recycling does not check the resource Id.  This allows resources with same source strings from different project to be ‘import’.  However, it is important to remember this looser checking allows recycling to pick the translation based on matching source string and highest translation state, not on the context of the translation.  For most this is a good solution, but it is important to understand this key difference when apply translations.

This update provides several improvement in how the import and recycling feature works.  Two key fixes include focused on recycling effectiveness and importing resources with <mrk> tags.  The bug that causes recycling to only update the first match and not subsequent match has been resolve as well as added support to correct respect the Translatable = ‘No’ flag.

Importing and Recycling with <mrk> tags
Import (and recycling) would not import any resources that had string locks applied unless it resulted in an exact match.  Locks are represented by the <mrk> tag on the resource and are applied and visible in the editor.  For the most part this works for same project well, but does completely blocks any recycling use of locked strings.  It also makes it a lot harder to manually update from v3.1 projects that use locks as they will be omitted when recycling.

To resolve this issue, both import and recycling will ignore the <mrk> tags when validating the match criteria.  This enables recycling - and to a less extent import – to process strings from other projects as well as the published manual v3.1 update steps.  If <mrk> tags exist in the file being imported, the resulting project’s XLF file have the <mrk> tags applied.  Since the string was locked for a reason, this is the desired result.  However, please note that the reverse is true.  If the imported file does not have locks on the resource, but the project file does, the locks will be removed.  This is a design trade-off to enable recycling works.  It is not possible to correctly apply the <mrk> tags to the translation being imported without tags

Change Log
For a complete list of the changes in this as well as previous updates, please see the change log on our User Voice site: Here is a direct link: https://multilingualapptoolkit.uservoice.com/knowledgebase/articles/460620

Thank you,
The Multilingual App Toolkit team
multilingual@microsoft.com
User voice site: https://aka.ms/matvoice
v4.0 Technical Preview: https://aka.ms/matpreview
Twitter: @CameronLerum

Windows Store project issue
Customers were reporting issues with some, but not all Windows Store Projects.  Across the board most projects worked as expected so it was hard to track down this issue,  A repro was provided by the author of ‘Paint 4 Kids’ that allowed us to see the root cause.  The repro required the project’s name to end in a language culture code – in this case a MAT 4.0 test project ‘MatRU’ was causing issues with Russian as a target language. 

This issue is manifesting as two separate bugs.  One bug reports the error "A resource file referenced by 'filename.xlf' was not found in the project".  The second silently fails to add the target resource file when adding a new language, but would surface during the build operation as the first issue.  Both of these issues are fixed with this update.

Readiness of Target languages
MAT considers all resources are translated unless they have a state of ‘New’.  This works great for added translations into a project, but can make is hard for a developer to known if their language is ready to ship.  While we do track and display indicators and apply filters in the editor to let you see the different states, we felt that is data should be always available.

The Editor has been updated to so the counts of the different translation states are visible status bar.  This allows you to glance to see the translation state of your resources.  We also moved Translation State filters to the primary Ribbon as well as changed them to checkboxes, allowing filtering of multiple states at the same time.

Note: The status bar always indicated the state of the current view.  Be sure to reset all filters to see the status of the entire file.

Improved Language Portal results
I’m sure the most will agree that nothing beats direct human translation.  However this may not always be an option for every app or even every language in an app.

One of the challenges with providing automatic translation is to figure out which result is the best available option.  In a recent review with the Language Portal team, we decided to tune the request to tighten the result set just a little.  The result was an overall better match with translations from the Language Portal service. 

One such example was the translation of ‘Help’ into ‘German.’  Based on our previous settings as well as post processing, the best result was ‘HELP-TASTE’.  Even as a non-German speaker, this was not exactly what I would call the best available option.  With the change using case sensitive matches the result is now ‘Hilfe’, which is a much better option.  There are other similar examples, but overall this change improves the top result from the Language Portal Provider.

Thank you,
The Multilingual App Toolkit team
multilingual@microsoft.com
User voice site: https://aka.ms/matvoice
v4.0 Technical Preview: https://aka.ms/matpreview
Twitter: @CameronLerum

Palle Petersen covers all the details in his recent Microsoft Language Portal updated with Windows 10 translations blog.

While MAT is already picking up these new translations automatically, the default is to return results from all of Microsoft’s released product translations. 

The Getting the most out of MAT’s Language Portal provider blog covers all the specific details, but I wanted to call out the specific configuration related to Palle’s announcement – specifically how to limit the results to these recent translations.

For this blog, we are going to specifically limit results to Windows 10, Windows Mobile 10, Universal Store and Office for Mac 2016.  We will also enable the metadata feature to display the translation’s product and version.

Here are the abbreviated steps. Please review the previous post if you need specific step by step details.

1. Open the Language Portal configuration file as an Administrator.
2. Enable displaying of the metadata by changing <Suggestion><UniqueResults> setting from True to False.  (The default of True avoids getting the same translation across the different versions of the same product but blocks the metadata.  But since we are limiting the product scope, we do want to see the metadata when we get a suggestion.
3. Change the <Products /> node to list the different Products and versions. The change will looks like this:
   <Products>
     <Product Name=”Windows”>
       <Version Value=”10”/>
     </Product>
      <Product Name=”Windows Mobile”>
       <Version Value=”10”/>
     </Product>
     <Product Name=”Universal Store”/>
     <Product Name=”Office for Mac”>
       <Version Value=”2016”/>
     </Product>
   </Products>
4. Save the file

Create a MAT enabled project and add the string “Comments:”.  For this example I’ve add German-Germany (de-DE) as my target language.  When I open the German.XLF file in the editor and get a suggestion for “Comments:”, the first result is a German Translation used in the Windows Universal Store.  Other translations are from Office for Mac 2016 and Windows 10. 

Notes:
Hovering the mouse over the translation displays the metadata, which contains the product name and version. 

You probably noticed that I did not specify a version element for “Universal Store”.  Since there is only one version (2015), there was no need to limit it to a specific version.

I hope you enjoyed this view into the many feature of the Language Portal. 

Also - Don't forget to set the configuration back to the defaults, or the configuration that works best for you. 

Thank you,
The Multilingual App Toolkit team
multilingual@microsoft.com
User voice site: https://aka.ms/matvoice
v4.0 Beta: https://aka.ms/matpreview
Twitter: @CameronLerum

LocShare MAT Technical Preview is the result and it is pretty cool.

‘LocShare MAT’ provides developers (and localizers) with a translation database and MAT based translation provider to allow seamless retrieval of imported data from your private translation memory. Setup adds the LocShare provider into MAT’s provider list automatically. 

All you need to do is populate the TM with your XLF based translations and your good to go.

By default, the LocShare provider is the preferred provider so your imported resources are selected first.  Since the TM is local to your machine, it even works when you are offline!

The direct link to the Visual Studio Galley download page is: https://visualstudiogallery.msdn.microsoft.com/3500d116-cd21-4e89-bb1b-cd3d26770b58

Great job LocShare team!

Thank you,
The Multilingual App Toolkit team
multilingual@microsoft.com
User voice site: https://aka.ms/matvoice
v4.0 Beta: https://aka.ms/matpreview