The integration into visual studio works very good, at times it happens that for some reason the xlf files are not opened with the Multilanguage Editor but instead with the json editor. No clue why this happens some time, I am not even sure whos fault that is.
Aside from this the toolkit is easily able to handle thousands of translated strings within a acceptable time frame, the included editor works straight forward and the translator persons (who aren't developers) work with it without any issue.
The only thing that is a little problem right now is the awful German translation. You notice a mile off that it is machine generated and at times you actually have to translate the terms into English to understand what is going on. I rather prefer the application in English then with a very bad translation into my native language. This holds for the VS integration and for the editor.
The language issue is the reason why I am giving "only" 4 stars. Aside from this the tool kit works really good within Visual Studio 2015 developing .NET 4.5 with WPF and WinForms.
The XLF file losing its association with the Multilingual Editor and instead open with a VS editor has been a challenge to isolate and solve. (I see it too. The workaround reapply the default by selecting “Open With” on the XLF file, selecting the “Multilingual Editor” and then click "set as default".)
Regarding the translation quality – I agree that machine translations are not perfect and in some cases way off. It is recommend that automatic translations are used during product development.
However, due to variances in quality, it is strongly recommend involving a human reviewed before shipping. If you don't have connection that can help out by using the Multilingual Editor, most professional translation services support XLIFF v1.2 and easily interop with MAT’s workflow via the Export / Import feature. Additional resource and vendors can be found here: https://developer.microsoft.com/en-us/windows/internationalization
Awful! Is it kinda a joke? Hello, MS, wake up! You guys are going directly to the hell (for the copy&paste & hard-coders)...
This bugKit is suppose to be an official localization tool. OK, let's try. I added this bugKit to my VS2015, hoping to get fast and easy localization but... Ah-ouh, not too fast! Looks like it's a devil damn games - all menus of this bugKit are... DISABLED! Got a message (in output window): Project "xxxxxxx" does not have any localizable resources. At least one resource file will need to be added before translation languages can be added." (hmm, who's preventing you to add your freaking resource???)
OK, I added "Resources.resw" file. What do you think, sir, this damn bugkit start working? No freaking way!
Hey, guys, are you really working for "industry leader software development company" or you are just copy&bug&pasters damncoders?!! I've spent five hours in trying make your bugkit working. Shame on you!
The Multilingual App Toolkit menus on the project are often grayed out of two reasons. The first is that the project has not been enabled for the localization workflow. The second is because there are not localizable resources.
In the case of most projects, you will need to set the project default culture as well as add project specific resources.
As an example, Windows 10 Universal project sets default culture to en-US by default - so the setting of the default culture is done for you (assuming you are using ‘en-US’). So all that is left to do is to add a folder name ‘en-US’ and add a resources.resw file to that folder.
Once this is done, select the Tools -> Multilingual App Toolkit -> Enable selection menu to activate the workflow and menus. Now the Multilingual App Toolkit -> Add translation languages Menu will be enabled. This will added target language(s) based on XLF files, which will enable the remain menus such as Generate Machine Translations, etc.
Be sure to look at the Multilingual App Toolkit output panel as any issue hit along the way are written to that area.
I've used the MAT in my WP8 apps and just recently upgraded to this version for my use in UWP 10. It's really great to cover the time between when you add new features and are able to get your strings translated not to mention many other features of working with the strings both in the editor and XLIFF. The one thing I would point out is, when using XAML, to make sure you strictly follow the naming guidelines of putting your resw files in subfolders and making them all have the same name (e.g., Resources/de/AppResources.resx). I prefer having separately named files (e.g., Resources/AppResources.de.resw) to avoid issues when localizing but, in my experience, you really must follow their guideline on this for things to work correctly in UWP 10.
DONT USE IN RT!!!!!!!!!!!! Terribly bugged... A real mess of resw, resx, xliff.. Works in debug but not in release, works and does not work, cannot change language at runtime (maybe in debug, but not once deployed to the Store). A shit... Must use navigation tricks to refresh a page after a language switch.. Countless hours thrown into the WC !!! It's the LATEST time I will ever develop a "pure" WP app... Xamarin all my life!
Agreed - XLIFF 2.0 support was just added for Export, Import and Recycling. Note: We just announced that our .NET XLIFF 2.0 OM will be available via open source. Release date TBD. I'll be sure to update the blog when available.
Now that .net core is available, are there plans to make MAT support it?
I would like to convert my Resources project (which relies on MAT) to .net core, but can't directly as long as .net core projects and MAT don't cooperate.
Every language file I have is throwing an error when I try to run my debug test. These errors appear when I change the code base even if I don't change any of the language files.
All my language files are checked out and there are no changes in the xlf or resource files for any language.
How can I stop this from happening?
Resources.zh-CN.resx requires updating, but is currently a read-only file. Please check out this file and build again
I updated from 3.x to 4.0 today, and I have things mostly working, with the exception of the pseudo language resources. The xlf and resx file are in my solution, but, when built, there is no qps-ploc subdirectory in the bin folder.
The Spanish resource files are correctly placed in the es folder and things render properly when i force the language to es.
I used to have to copy the pseudo language files to the executable bin directory in a post build script, but, the files don't exist to copy any more.
Any help is most appreciated.
This seems to have done the trick. It now compiles the qpl-ploc resources and copies them to the correct areas of bin directories:
Enabling these registry settings seem to have put my machine in a permanent state of pseudo localization testing. removing the registry settings do not seem to remove the warnings. Be careful if this is your build machine as the warning states that there could be certificate failures when publishing your app.
Any suggestions on how to get rid of the testing state is most appreciated.
My assumption is that Pseudo was added and set as the default language. On the next logon, this can cause the UI to display Pseudo text.
Since there are not OS warning about Pseudo, I’m assuming the warning are from the Multilingual App toolkit. MAT does warn about failing Windows Store Certification test since Pseudo is not a valid shipping language.
Current the only way to remove the warning is to remove the Pseudo language form the apps list of MAT managed languages. This is done by deleting the qps-ploc XLF and RESX files. Since this is a desktop app, you can ignore the Pseudo warnings. If you are actively using Pseudo for testing, I would recommend placing the Pseudo XLF and RESX files in a single PropertyGroup with a DEBUG compile condition check. This would limit Pseudo to debug builds for testing while preventing Pseudo build for release.
Just wondering if anyone knows how to turn this warning off?
I have a large solution, with a number of resx files that do not contain any strings; when I build the project I get lots of warnings from the toolkit, as a general rule I prefer to have a clean build with no warnings; so at the moment, I am spending a fair chunk of time sifting through the "No localizable resources..." warnings looking for warnings that may indicate a real issue for the build.
Not actually a problem with MAT: At what point in the asp page life cycle do the meta:resourceKey attributes get processed? I have a Database resource provider - no resx files /satellite assemblies.
All the controls with meta:resourceKey attributes are localised when the site runs in Visual Studio, but not when its a compiled site.
In the compiled site (Publish from Visual Studio and import into IIS)
explicit localisation tags work - <%$ Resource: etc
and explicit calls to GetGlobalResourceObject work, but not the tags with meta:resourceKey.
I created a dummy site with some dummy pages in the same relative path, so the ResourceType was the same, and they DO get localised. The problem is somewhere in our site, but I cant find it.
Words Fail Me. (well obviously they don't)
For future reference, the problem lies in the web Publish settings. in the publish dialog File Publish Options, there is a checkbox labelled "Allow precompiled site to be updateable. Check that, publish, and now the meta:resourceKey attributes are observed. Not ideal as the published pages now have markup, and are slower to load.
I had a look at the precompiled assembly in ILDasm, compared it to the one you see in Visual Studio, and sure enough there is some IL to load the resource, where the was none before.
( By the way Cameron, would it be too much to hope that the MAT uses a provider model to determine whether to process resx / resw files? Would it be difficult to add an option for a Database resource provider?
We'd love to be able to use the Multi lingual editor, but we don't use resx files.
Well, what a surprise. Download the app, only to discover it doesn't DO ANYTHING! So I realize I did not read the fine print...and of course, M$ didn't spend the 5 minutes it would take to get this to work with VS2012. Doesn't matter if you bought 2012 Ultimate and spent 1000s of dollars. M$ has no problem abandoning customers who haven't paid them thousands of dollars in the last 4 years on VS. Spend money on other M$ products? DOesn't matter. M$ gotta M$.
Shame on you.
The reason for not supporting VS 2012 with MAT v4.0 is based on the demand for Shared projects support, which VS 2012 does not support. MAT does support VS 2013 and VS 2015, including community editions. If upgrading or using the free community edition is not a viable option, MAT v3.1 is still available and does work with VS 2012.
My UWP-Projects default-language is en-US, and I have only a single translation.
As long as my app is installed by VisualStudio, the translation works as expected, no matter if I start it out of the VisualStudio in Debug-Mode or directly from the Start-Menu. But if I install the App from an appx-boundle I created in VisualStudio, it does not change the language.
I created a test-project with only a single textblock and a simple mask for overwriting the Windows.Globalization.ApplicationLanguages.PrimaryLanguageOverride. In the testproject I overwrite at launch Windows.Globalization.ApplicationLanguages.PrimaryLanguageOverride, CultureInfo.CurrentUICulture and CultureInfo.CurrentCulture with a Culture derived from my region.
After overwriting the Culture, I check the changes I made via a Logoutput, which clearly says it has the desired Culture. Still nothing happens.
I'm using the newest available Version of MAT 4.0.
Is this issue somehow known?
Now I can specify the issue a little more. When starting the app in Release-Mode, it also lacks a translation. It seems this behaviour has something to do with native-code. Still this does not solve the problem I have.
This is not an issue related to the toolkit. I am able to repro the problem you are describing in a Windows 10 app without MAT enabled by manually adding a second RESW file with a single translation.
I do not know the source of the issue but I do have a workaround by creating an App Package with "Generate app bundle" set to "Never". Since this disables the bundling, all the translation to be placed in a single resource location. Then when you run the ".\Add-AppDevPackage.ps1 ..." command, it sees the overwritten language just like when it is deployed from within Visual Studio.
Note: Using bundles has advantages over non-bundled packages and it recommend to bundle when publishing to the store.
I need to correct my selfe. As long as I deploy the project as Debug-Project you are right. But when switching to Release, the translation does not work. Since it's neccesary to use Release for the Store, your workaround does not work.
In my Test-Project, when deactivating MAT before deploying but after I localized the App worked, only in our relevant Project this does not work.
But I slowly get the impression, this has nothing to do with MAT.
Done. Updated the following line:
"Integration with Visual Studio IDE allow you add and manage translation files through the use of XLIFF v1.2 industry standard localization files within a project solution while still using standard Visual Studio menus and dialogs."
I wanted to install the Multilingual App Toolkit with Visual Studio 2013 Professional and Visual Studio 2015 Community editions installed, it installs, but when it comes to the stage Registering Visual Studio 2013 extension... (Please Wait) it gets stuck there.
I opened Task Manager and found that the setup has launched Visual Studio's exe (devenv.exe) automatically. Then I thought to dig up a little further and opened Resource Manager where there were four threads of msiexec. Three threads were running normal and the fourth thread was dependent and waiting for another msiexec's thread. What should I do?
hallo, i installed the MAT v4.0 on Visual Studio Community 2015 Update 2 on and enabled selection on a UWP Project.
But the menu on the project to add an language never enables.. although i deinstalled and installed it and so on.
solved by my self:
It is necessary only a folder named strings and including a folder with the name of the standard language , such as en-US or de-DE create.
You must insert a file type Resource.resw