This week I had to deal with very strange behavior when trying to localize a Windows 8.1 app in Czech and English. As always, I prepared a special localization class, added the *.resw files for en and cs and finally hooked it all up to XAML via binding. Everything seemed hunky-dory except for the tiny fact that only English (language neutral) variant of the app was functional. The situation got even stranger when I replicated the exact same set-up in a new project and it worked normally. After a longer search I found the hidden cause of the problem. The Package.appmanifest file, that stores different package-related settings of the resulting Windows 8.1 app package has numerous options, that are not available directly via the designer. In fact, the AppManifest file is just a XML file with a fancy extension, that can be edited directly. In Visual Studio 2013 click the right mouse button on this file and select the Open With... or View Code command. 
The source of my problems was one of the elements in manifest file – element Resources to be exact. This element influences the behavior of resource files in the project and more importantly its contents describe which languages the app supports. In my case it contained just one – the english variant:
<Resources>
<Resource Language="en-US"/>
</Resources>
To support other languages, I would have to repeat the Resource element with other ISO codes of languages I need. This would be too much of a burden and not very practical. A better solution is the form that is actually set as default in newly created Windows 8.1 projects:
<Resources>
<Resource Language="x-generate"/>
</Resources>
Special constant x-generate specifies, that while the package is constructed, the required localizations are automatically generated on the basis of what language *.resw are present in the project.