MAT v4.0 Technical Preview Update 1 with Xamarin support

The Multilingual App Toolkit v4.0 Technical Preview Update 1 is available as of this morning.  The release continues to support Xamarin (Initial Announcement), bringing MAT’s streamlined localization workflow and services to Windows, iOS and Android platforms.

This update contains fixes as well as suggestions sent by early adopter both via email to and MAT’s user voice site. We love hearing your feedback so THANK YOU and please keep it coming.

One visible change is in the ‘Add translation languages…’ dialog.  Previously Hindi (and other languages) were only selectable by the language and region code (hi-IN in this example).  As you can see in the image below, Hindi is now selectable at the root language level as well.  This enables easy selection for platforms that don’t support region, or if you are just targeting the root language in your app.


To support this change, the translation providers where enhanced to work with the root language as well.  In this example, if you select Hindi (‘HI’), the translation providers will ask the related service for hi-IN based translations.  This small change allows the continued use of the translation services when selecting a root language by mapping that root language to the specific language.  In most cases this mapping will provide the desired results.  This is configurable in case you want to change the mapping, but that’s the content for another blog.

The list of major fixes are listed via the v4.0 Technical Preview article on the MAT user voice site.  Please refer to for additional details and download links.  Of course, if you already have MAT v4.0 installed, Visual Studio will let you know to install the update.

User voice site:

Comments (4)

  1. Dev says:

    I really don't understand why are you wasting your time on some ?ucking Xamarin support as you don't have support for Universal apps still. At the same time you (Micorsoft) are requesting developers to port their apps to Universal apps. My Silverlight app has 15 translations split over multiple assemblies and maintained with MAT. Now I have ported the app to Universal excluding translations. Surprisingly the biggest pain seems to be to get the translations into the new project as you have ?ucked up things. If I remember correctly this Universal apps thing was released at least year ago, and only thing you have now (year later) is "TECHNICAL PREVIEW" with some ?ucking Xamarin support. And nothing for Universal apps. What the hell are you thinking?

  2. Universal Apps are supported with MAT v3.1.  Each project (Windows Store and Windows Phone) need to be enabled separately since the share ‘project’ is not directly buildable.  However, each project will consume the resources from the shared project so you are encouraged to place your resources in the language folder of the shared project.

    When converting your Windows Phone Silverlight app to a Universal App you should be able to import the existing translation using the import with recycling feature.  You will need to enable the recycling checkbox during the import since the Universal App resource IDs and Silverlight resource IDs differ.  The recycling option ignores the resource ID and matches using source string and defined cultures.  Note: The default Source and Target cultures tend to differ between the two models as well. Recycling will treat ‘en’ and ‘en-US’ as different cultures so you may need to adjust the culture ID before running import.

    However, if the source strings have changed during the conversion, it would not be possible import the translations since MAT would have no way to matching the changed resource ID or the changed source strings.

    The MAT v3.1 blog provides a quick look into the import and recycling functionality.…/announcing-multilingual-app-toolkit-v3-1.aspx

    Regarding MAT 4.0 TP – the focus on the TP was to introduce support for our partnership with Xamarin.  A bug in the TP build exists that currently blocks reliable Universal Apps support.  This is a known bug and will be resolve.  Technical Previews are not recommend for production projects.

  3. Dev says:

    I am using VS2013 Community Update5 + MAT3.1 and I still don't get it working. Actually my project is not fully "Universal" yet but a Windows Phone 8.1 project (Windows Runtime Project anyway), if that makes any difference. My English resources are in Strings/en-US/Resources.resw. When I enable MAT and add a new language e.g. de-de, a file gets generated. File's build action is "None". I guess it should be XliffResource, so is that a bug? I tried both, but when I build the project, nothing gets generated. I would expect to see a new file Stringsde-deResources.resw as a build output. So, what am I doing wrong? My other question is that can I have resources in a portable library (Universal/WP8.1) too?. My project composes of several assemblies and many of them have string resources.

  4. I have not tested VS2013 Community + Update 5 CTP + MAT 3.1.  The latest test was against update 4, but I don’t see any reason for it not to work. I’ll carve out some time to install update 5 CTP to verify functionality.

    Based on your description, it appears that your resources are processing correctly.  A key change is that the usage of the XLF files for Windows Phone SL apps and Universal apps is different.

    For Windows Phone SL, the XLF file is created in the same folder as the source culture's RESX file (usually AppResources.resx).  The related target language RESX files ( are created under the XLF file and are compiled as path of the MAT build step.    

    For Windows Store and Universal Apps, all of the XLF files are placed in the MultilingualResources folder.  The related native file (strings/de-de/Resources.resw) is not created.  Instead the project’s PRI file is updated directly as path of the MAT build step.    Portable libraries are supported as well.

    Note: Windows Store and Universal apps need to build at least once after MAT is enabled.  The resources are gathers at build time, so these is a one build delay when resources modified.

    Note: For v4.0 we have changed the model to create both the MultilingualResources/ file and the native target files (strings/de-de/RESW) to allow MAT to “get out of the compiler’s way”. We also pre-populate the XLF file, so no build is initially required.

    If you are still having issues, please feel free to email me at multilingual @ Microsoft . com

Skip to main content