MAT 4.0.1466.0 beta update is live
The Multilingual App Toolkit team has posted another updated. MAT v4.0.1466.0 contains key customer reported fixes as well as a new report on the state of your project’s translations.
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