MICROSOFT_PRESS_EBOOK_PROGRAMMING_WINDOWS_8_APPS_WITH_HTML_CSS_AND_JAVASCRIPT_PDF

1. Create a strings folder in the root of your app project.
2. Within that folder, create a subfolder that matches the BCP-47 language tag specified as the
default language in the manifest (for example, en-US, fr-FR, ja-JP, or just the base language like
en or ru).
3. Move your resources.resjson file into that folder.
If you run your app again at this point, you should see that everything still works. If you go back to
the How to name resources using qualifiers topic we mentioned earlier, you’ll see that the resource
loader is perfectly happy when you use qualifiers like a BCP-47 name as a folder name. It basically parses
entire folder names looking for qualifiers, so you can create deep hierarchies to sort your resources
however you like. That is, you can sort by contrast or scale first, if desired, and include language suffixes
in the filename (where the format is lang-). What’s more, you can create secondary
.resjson files in these folders as well and play some other tricks. See “Sidebar: Secondary String Resource
Files” for details.
Anyway, what you’ve just done by moving your resources into a folder for your default language is
set your fallback language resources—this is what the resource loader will turn to if it cannot find a
more specific match for the user’s current language. Finding a match is actually a sophisticated process
wherein the resource loader measures a kind of “distance” between the user’s preferences and the
available resources and chooses whichever is closest. This makes it possible to select en-GB as a closer
match to en-AU than en-US, for example. Generally, though, it means that the resource loaded will
search for a specific match like de-DE (German) first, then the next closest language using the base
qualifier de, and then eventually fall back to your default language (if there are no resources for the
user’s other languages). The short of it is that you should always make sure the language identified in
your manifest is fully populated with your full set of resources! Then even if you don’t happen to localize
some of those resources (say, for exact cultural alignment with images), one will still be found. For the
complete story on this subject, refer to Language Matching in the documentation.
Sidebar: Secondary String Resource Files
Both WinRT and WinJS are able to work with secondary string resource (.resjson) files, allowing
you to organize your strings in multiple files, if desired. For example, it’s common to separate
error strings into a file called errors.resjson. When referencing a string identifier in one of these
secondary files, all that’s needed is that you use the syntax // instead of just
. This syntax works in HTML, JavaScript, and the app manifest. See Scenario 5 of the
Application resources and localization sample for an example.
Something else you can do with .resjson files is name them with other qualifiers for contrast,
scale, home region, and so forth and even organize those files under any old folder. This is
demonstrated in Scenario 13 of the same sample, where it has many different .resjson files
underneath strings/scenario13, each of which is named as scenario13..resjson. Because
814