I got a few questions and comments about how to actually include SQLite in a C# Metro style app.  Since perhaps it wasn’t clear in describing in my post, I thought a quick video might help demonstrate the steps to build and use SQLite in a C# Metro style app.

The video walks through actually building SQLite from the source (Visual Studio 2012 required…express is fine) and adding it to a C# Metro style app, create a database, populate with some data based on a class and databind the query to a ListView.  The video references my OneNote notebook on the tools you need to download and build the SQLite source.  It also demonstrates using the sqlite-net library from NuGet on interacting with SQLite in a C# application.

This is a quick video to demonstrate the concept on how to get started and is not a full end-to-end sample.

NOTE: This video only demonstrates how to build SQLite until the team itself merges the WinRT changes and produces the supported build.  Until then this is a step you’d have to do on your own and these private branches are not fully supported by them until merged to their main release branch.

I hope this helps clarify things!

With the announcement of the Windows 8 Release Preview and matching Visual Studio 2012 RC I’m pleased to share some work that has been a result of my own personal app building, collaborating with some friends during their app building as well as porting some helpful projects that I’ve found helpful in my development.

Disclosure: At the time of this writing I do work for Microsoft, but this has been a personal effort from my own app development and during my own time (late nights and weekends).  I am not able to upload apps to the store at this time to share apps that I’ve written and receive no preferential treatment as a Microsoft employee.

Introducing Callisto, a toolkit of sorts for XAML Metro style apps.  When starting my own app building for the Consumer Preview, I realized there were some experiences and common things that I wanted to implement that weren’t existing controls in a way that I could easily re-use my efforts across app to app that I was building.  The foundation building blocks in the platform were there of course, as was a few existing Open Source projects that I could leverage (yay Open Source!).  I refactored the combination of these things into a single toolkit that I’ve been using for my apps.

Kitchen Sink?

My approach has been mostly pragmatic for me.  This was extracted out of app needs versus being designed as a toolkit from the beginning.  As such, it might feel like a ‘kitchen sink’ approach as there are things that you may never use.  For me, I wanted one thing I could add to my project and get all the goodness that I desired.  This is what led to a single project/toolkit rather than any modular approach.  For example, I originally had included the sqlite-net project in mine because I didn’t want to keep adding it to each project I was using the SQLite database engine.  This is one that I’ve removed since the changes I needed were contributed back to the project and I’ve wrapped them up in a nice easy NuGet package for that portion.

What is it?

Well, it is a toolkit!  It is a combination of some helper libraries as well as some controls.  Some original, some contributed, some ports from existing toolkits.  If you look at the project page you’ll see that it currently has:

• Helpers: some attached property helpers for web content bindings, converters (i.e., for time relativeness)
• Extensions: Tilt effect and some helpers for doing some things like OAuth 1.0 (adapted from RestSharp)
• Controls: Flyout, SettingsFlyout, Menu, LiveTile

sample menu flyout from an AppBar

And more to come as I have time.  I’ve had the help of some folks in the community as well as being able to draw off things like the Silverlight Toolkit for some inspiration and some code as well! 

sample settings flyout

The source project comes with a little crappy sample app that I’ve been using as my UI test harness. 

I fully plan to clean this up to a better sample app, but it serves a simple purpose for now.  You can see specific uses in that sample app for some of the controls.  Otherwise feel free to email me directly for some help and I’ll try to point you in the right direction.

How do I get it?

In addition to the source for those who would want that, you can get it in 2 ways: via NuGet or via the Visual Studio Gallery.  Incidentally you can install it both of these ways from within Visual Studio 2012 Express itself!  If using the gallery VSIX installer, then the toolkit will be available for you to use across multiple projects.  The NuGet approach is per-project (as it is with any NuGet package).  After installing the VSIX – if you use that approach – simply choose Add Reference in your project and navigate to the Windows…Extensions section and you’ll see it there.  It is implemented as an Extension SDK for Visual Studio.

sample live tile (as best you can show in a static screenshot – imagine animation :-))

I plan on submitting regular updates as I refine things, fix bugs and add new controls.  Using the NuGet or VSIX approach for installing will help you keep updated as you’ll receive notifications of updates as long as you are using Visual Studio.

I found an issue/have an idea

Great, I’m sure there are some.  Again, it has been a few folks on our spare time working on this.  Please feel free to log a bug so that we can track the request.  The only place to log a bug is the Issues link on the project page.  No other mechanism will be a good feedback mechanism.

Alternatively, it is Open Source, so feel free to fork and fix.  Ideally you’d contribute your fix back to the project…we’d appreciate it.

Summary

At present the toolkit is for managed code Metro style apps only.  This isn’t because I don’t like C++ developers, but rather that this has been an extraction from my own app building and not designed from the start as any WinRT toolkit.

NOTE: There are a lot of things out there calling themselves WinRT toolkits for XAML.  So far I’ve actually seen none of them that are WinRT, but all are just regular .NET class libraries…just like Callisto.  These are all going to be restricted to use within a managed code XAML app.  If I can get assistance translating this all to WinRT native code, then I could easily see this being more valuable to others.

There are a lot of great APIs in WinRT available to developers.  The SDK samples also provide some helpful code for app developers as well you should ensure you look at (if you are doing ANYTHING with tiles, you should look at the Tiles SDK sample and pay attention to NotificationExtensions).  I hope that Callisto helps you as well in some small areas.

Hope this helps!

At the “Developing Windows 8 Metro style apps with C++” event that happened on 18-May-2012, we saw and heard some very interesting things.  If you were watching live then hopefully you didn’t see how I tried to work through my presentation while my disk was suspiciously guzzling every last byte until it eventually ran out of space!  But I digress…

During the keynote presentation by Herb Sutter, we brought up several customers that are well-known in the native code world to talk about their experiences with Metro style apps and C++/Cx.  In particular hopefully this one caught your eye:

That’s right, the team for SQLite was there to discuss how they were able to take their existing Win32 codebase and ensure that it worked well on Windows 8 as well as for Metro style apps.

SQLite is a in-process library that implements a self-contained, serverless, zero-configuration, transactional SQL database engine. The code for SQLite is in the public domain and is thus free for use for any purpose, commercial or private. SQLite is currently found in more applications than we can count, including several high-profile projects.

SQLite is an embedded SQL database engine. Unlike most other SQL databases, SQLite does not have a separate server process. SQLite reads and writes directly to ordinary disk files. A complete SQL database with multiple tables, indices, triggers, and views, is contained in a single disk file. The database file format is cross-platform - you can freely copy a database between 32-bit and 64-bit systems or between big-endian and little-endian architectures. These features make SQLite a popular choice as an Application File Format. Think of SQLite not as a replacement for Oracle but as a replacement for fopen().– Source: http://www.sqlite.org/about.html

Dr. Richard Hipp, the founder of SQLite, was on hand to announce the availability of the experimental branch they’ve been working on as well as that when the Release Preview of Windows 8 is made public that he will merge this code to the main trunk for SQLite, making it supported by them.  This is a really great thing for developers as SQLite has been a proven embedded database for numerous platforms and many, many customers.  The team prides themselves on testing and has millions of test cases that are validated each release.

As a Windows (and perhaps more specifically .NET) developer, you may not have had to build any lib from Open Source before of this type (i.e., native code) and since a binary is not being provided yet until Release Preview for Windows 8, I thought I’d share my tips on building the experimental bits, adding them to your projects and then using them with a client library.

UPDATE: I created a HOWTO video demonstrating the following steps of building and using from a C# Metro style app.

Building SQLite from source

If you are looking for the sqlite3.dll with this WinRT support anywhere on the sqlite.org site, you won’t find it.  You will have to build the source yourself. UPDATE:Since the origination of this post the SQLite team has released a version already compiled for 32/64-bit.  I highly recommend you get the code from the source rather than from any third party site.  Microsoft has worked with the team at SQLite to ensure compatibility and store certification.  For most .NET developers who have never grabbed native code source from an Open Source project and had to build it before, the maze of knowing what you should do can be confusing.  I’ve put together a cheat sheet on building SQLite from source for a Windows (and .NET developer) and put it on my SkyDrive: Building SQLite from source.  The OneNote I have has the details you need for the tools that will be required. 

In a nutshell you’ll need:

• Visual Studio (easiest way to get the C++ compiler)
• ActiveTcl
• Update for gawk.exe
• Fossil (the source control system used by SQLite)

Once you have these, you are ready to build SQLite.  Again, I’ll defer to my instructions on the details of setup.  Once your setup is complete, from a developer command prompt you’d run:

   1: nmake -f Makefile.msc sqlite3.dll FOR_WINRT=1

The result of this will give you basically 4 files that are of likely most importance to you: sqlite3.c, sqlite3.h, sqlite3.dll, sqlite3.pdb.

NOTE: The resulting pdb/dll that is built will be architecture specific.  If you used an x86 command prompt then that is what you have.  Be aware of this (as noted later in this post).

At a minimum you’ll want sqlite3.dll if you are a .NET developer, but as a native code developer you will likely be more interested in the others as well.  After this step, you now have a Windows Store compliant version of SQLite to include in your applications.

Runtime versus client access

Now at this point is where I’ve seen some confusion.  Folks are asking How do I include this, don’t I need a WinMD file to reference?  Let me diverge a bit and explain a few things.

The result of compiling the binary above produces primarily one thing…which I will call the “Engine” in this post.  This is the SQLite runtime and logic required to create/interact with SQLite database files.  This is NOT, however, an access library, which I will call the “Client” in this post.  If you are a managed code or JavaScript developer, at this point, all you have is the Engine, the database runtime.  You have no Client to access it.

Now, if you are a C++ developer you are probably okay at this point and don’t care much about what I have to say.  You have the header and are likely saying I’ve got the header, get out of my way.  And that is okay.  For C++ developers I think you’ll likely be accessing the database more directly through the SQLite APIs provided in the header.

I call out this distinction because this step provides you with the database engine you need to create a database and have it be store-compliant.  So if you are a JavaScript or .NET developer, what are you to do?  Stay tuned…let’s first get the Engine included in our app package.

Including SQLite in your app package

As I noted above, as a native code developer, having the header, lib and c file you may be okay and don’t care to read this.  I  personally think, however that I’d always just want the binary from my vendor rather than always include source in my files.  That said, the SQLite build process does product the amalgamation (sqlite3.c) you can just include in your native code app.

If you choose to go the binary file route (sqlite3.dll) then you need to simply follow a few principles to ensure that it is included in your package when you build your app/package.  These principles are simple:

• include the architecture-specific binary
• ensure the sqlite3.dll is marked as Content in your project
• ensure you note that you now have a native code dependency (not needed if you are already a C++ Metro style app)

These two items will ensure that when you build (even for debug via F5) or when you package for the store, that the Engine is included in your package.  Marking as content is simply ensuring that after you add the file to your project, ensure the file properties note that it is content.  In .NET apps this is making the Build Action property Content.  In JavaScript applications ensure the Package Action is marked Content.

Declaring the native code dependency means you simply add a reference to the Microsoft C++ Runtime Library via the Add Reference mechanisms in .NET and JavaScript applications.  By doing this (and again, this is a requirement of including SQLite in your app) you now cannot be architecture-neutral. This means no more AnyCPU for .NET.  When producing a package you’ll have to produce architecture-specific packages before uploading to the store.  Not to worry though as Visual Studio makes this incredibly easy.  The one thing you’ll have to remember though is that you’ll have to change the sqlite3.dll before building the packages as the DLL is architecture-specific itself.

Now this all should be easier right?  Wouldn’t it be nice if you could just Add Reference to the Engine?  I personally think so.  I’ll be working with the SQLite team to see if they will adopt this method to make it as easy as this:

In doing so, you as a developer would just add a reference to the Engine and then during build time Visual Studio (well MSBuild actually) will do all the right things in picking up the architecture-specific binary for your app.  No fiddling on your part.  This method also makes it easier for C++ developers as well as a props file would automatically be merged to include the .lib for linking and the header file for development.  This method uses the Visual Studio Extension SDK mechanism that was introduced in Visual Studio 11.

NOTE: Again note that as a managed (.NET) app I’d also have to ensure that my package includes the Microsoft C++ Runtime package in order for this to work and pass store certification.

Native code developers may scoff at this approach, but I could get started in 2 steps: Add Reference, #include.  No tweaking of my project files at all because the Extension SDK mechanism in VS does all this for me behind the scenes.

So why don’t I just give you the VSIX to install and accomplish the above?  Well simply, because SQLite is not my product and we’ve had a good relationship with their team and I want to make sure they understand the benefits of this method before jumping right in.  I hope that they will like it as I think it makes it *really* simple for developers.

Accessing the Engine from your app

Great, you’ve compiled the bits, you’ve understood how to ensure sqlite3.dll gets packaged in your application…now how do you use it!!!  Here’s the assessment of where we are at for Metro style apps as of the writing of this post.

C++ app developers: I think most C++ developers will get the header file (sqlite3.h) and be okay on their own with SQLite.  At this stage for them there doesn’t appear to be a real huge benefit of a WinRT wrapper to use the Engine.

.NET developers: I’ve messed around with a few libraries and believe the sqlite-net project to be the most favorable for what I believe most use cases will be for SQLite and Metro style apps.  This is a .NET-only library (not WinRT) but is basically a “LINQ to SQLite” approach.  The Mono team uses this one as well.  The necessary .NET 4.5 Core changes are already included in the project on github.  So you just need to get the SQLite.cs file and include it in your project.  Using this library allows you to write code like this:

   1: public sealed partial class BlankPage : Page

   2: {

   3:     public BlankPage()

   4:     {

   5:         this.InitializeComponent();

   6:  

   7:         string dbRootPath = Windows.Storage.ApplicationData.Current.LocalFolder.Path;

   8:         using (SQLiteConnection db = new SQLiteConnection(Path.Combine(dbRootPath, "mypeople.sqlite")))

   9:         {

  10:             db.CreateTable<Person>();

  11:  

  12:             db.RunInTransaction(() =>

  13:                 {

  14:                     for (int i = 0; i < 10; i++)

  15:                     {

  16:                         db.Insert(new Person() { FullName = "Person " + i.ToString() });

  17:                     }

  18:                 });

  19:         }

  20:     }

  21: }

  22:  

  23: public class Person

  24: {

  25:     [AutoIncrement, PrimaryKey]

  26:     public int ID { get; set; }

  27:     public string FullName { get; set; }

  28:     public string EmailAddress { get; set; }

  29:     public double Salary { get; set; }

  30: }

This is clearly just a sample, but demonstrates the simplicity of the library. 

NOTE: In the snippet above you do want to make sure you are creating your database in a path that is accessible from the AppContainer.  The best place is in the app’s ApplicationData location.  When specifying a path to SQLite in Open() for creation, give an explicit path always to ensure you aren’t relying on a temp file creation.

Some may ask about System.Data.Sqlite and this cannot be used because of the dependency of ADO.NET which is not a part of the .NET Framework Core profile.

Now this leads us to JavaScript developers.  Currently, there is not easy way for you to access this.  The Developer and Platform Evangelism team are working on some samples that are not quite complete yet.  JavaScript developers will need a WinRT library in order to access/create/query the Engine.  There are some out there (I haven’t played around with any of these) that would be good to see if they meet your needs.  Here are some pointers:

• sqlite-winrt
• SQLite3-WinRT

At the C++ event we talked with the SQLite team about a WinRT client library and will continue to talk with them to see if this is something of interest.  SQLite has a great history of working with the community and have a desire to continue this.  In the meantime, there are options for you to get started.  Also note, that since these are WinRT libraries they could also be used from C++ and .NET in Metro style apps.  At this point though it is my personal opinion that existing .NET libraries for .NET offer more value (i.e. LINQ) than how these WinRT ones exist.

Summary

This was a great announcement that the SQLite team made for Metro style app developers.  WinRT provides some existing local storage mechanisms which you should explore as well, however none that have structured storage with a query processor on top of it.  I’m really glad that the SQLite team was able to make a few diff’s to their code to accommodate a few store compliance areas and continue to offer their great product to this new class of applications.  It is very simple to get started by ensuring you have the Engine and picking your Client of your choice and write your app using SQLite for some local/structured storage!

Hope this helps and stay tuned for the release preview of Windows 8!

Being more involved in the engineering process of a product I had the chance to participate in the design of various features instead of just the ones that I’m responsible for delivering.  One of those areas was the way we would enable developers to produce localized applications.  Before this process I have to be honest and as an app developer never really paid much attention to providing localized versions of any app that I wrote.  I had absolutely no good reason for coming to that decision, just never bothered.  In helping to design and understand localization a bit more I can say that it is easy to do this in your app and there shouldn’t be any excuse for any app developer to create their application in a way to make it localized at any given moment.  Note I didn’t say localized immediately, but rather I mean to create your app in a way that would make it easy to provide a localized version in a fairly quick turnaround.

As I do some app development for Windows 8 I wanted to share my thoughts around localization and what it really means to me to provide a ‘world-ready’ application.  The three areas of focus are 1) how the platforms support a localized app, 2) what technical tools you have to automate localization 3) getting culture-correct localization and 4) testing your localized app.

Platform support for localization

The first thing you have to understand is how the platform you are targeting enables support for your app to easily be localized.  This may be in how you organize your content, how you name certain things, and how you write code.  For most platforms there is a pretty predictable method of doing this.  I would argue not all platforms make this extremely intuitive, but also state that inferring how (and what) you want to localize your app isn’t something a platform can predict well for every app.  It is important for the app developer to plan for a global market and fully understand the models before writing a line of code to understand how to make the app localized more easily later in the process.

For Windows 8, a new resource model is introduced for WinRT that is common across the entire platform regardless of the UI framework choice.  The areas you should understand are Windows.ApplicationModel.Resources and Windows.ApplicationModel.Resources.Core.  These two areas are where most Windows 8 developers will spend most of their time with regard to localization of UI strings (and other content).  For most, the GetString() method is probably where you’ll spend your time when using code.  String values are indexed during the build process of your application.  Your strings will either reside in a RESJSON (for HTML/JS) or RESW (for XAML) file.  Both of these are essentially name/value collections for your strings.  An example of the process of naming and managing your string resources can be found here: How to manage string resources.

NOTE: Yes the Consumer Preview version of that documentation shows only Javascript right now, but will be updated.  The naming conventions are the same.

In XAML we created a new way to do XAML UI localization in your markup, by moving some functionality into the platform for you.  Previously in platforms like Silverlight people used techniques like data binding to accomplish the mapping from the RESX-generated class to the UI.  Because the indexing of the string resources changed a bit (i.e., currently no strongly-typed resource class representation), we wanted to have the platform do some more heavy lifting for you.  We already load the index file (resources.pri) automatically during load of the app, so we’re aware of the resources and all the context the app may have (i.e., what locale, screen resolution, etc.).  Because of this we enabled a markup mechanism in XAML for you to provide easy string localization.  Let’s use a simple example of a TextBlock that you might have a static string:

   1: <TextBlock x:Uid="MyTextBlock" FontSize="24.667" Text="Design Placeholder" />

Notice the x:Uid value here.  This now maps back to the key in your RESW file.  Anything with that starting key will have properties merged into it.  So we can have a key in our RESW for “Text” using the key name MyTextBlock.Text with a value of “Hello World” and the runtime will do the replacement for you.  This applies to properties other than text (i.e. width) as well as attached properties.  While we think this is a great new method, it may not work for everyone’s situations and you still have control over retrieving strings using the Windows.ApplicationModel.Resources WinRT APIs.  You can read more about this method with some examples here: QuickStart: Make your Metro style app world ready and an SDK Sample here: Application Resources.

Tools to help with localizing content

Once you have understood what your platform provides and you have taken the effort to prepare your app for easy localization, the next step is to actually use tools/process to perform the localization.  I’ve come across a few tools that I think are helpful for XAML developers who are ‘small shops’ and don’t have an existing process for app localization.

The easiest thing for a developer to do is to use machine translation using automated services.  There are a few tools out there that I think can be helpful for this method.  It is important to note we are talking about machine translation here…I will get to that point later on in the post.

RESX Translator with Bing

Since the RESW format is identical with RESW (restriction is that RESW only supports string values currently), you can use a lot of existing RESX tools.  There is a RESX Translator with Bing project on CodePlex that was done by Microsoft UK Consulting Services.  This allows you to select a file and source language and translate to any language that Microsoft Translator supports. 

Since the current project supports (and only loads) .resx files, I had submitted some patch files to quickly make it support the .resw file extension.  The contributor hasn’t accepted these patches, but you can find them on the patches section for the project.

Multilingual App Toolkit

Released with the Visual Studio 11 Beta, the Multilingual App Toolkit from Microsoft provides an integrated method for generating resources for your app.  One of the benefits of this app is that it produces some standards-based files that are used to send to localizers and can be used in other tools.  This includes the TPX and XLIFF file formats.  Once installed the tool is integrated within visual studio and your flow would be something like the following.

First you’d have your app and an initial RESW file containing your default language (in my case en-US) resources.  Once I have that I can right-click on the project and choose Add translation languages and when doing so, launches:

which I can select the languages I would prefer.  Notice the translator icon next to some of them indicating that these could be machine-translated.  Once you select the languages you want, you’ll see a folder within your app that contains the configuration information:

Now if you open the XLF files you’ll basically see some XML that contains configuration information but initially won’t see any of your string values.  You need to do a build to populate those files.  After building you’ll see the XLF files regenerated with the keys to be localized:

   1: <?xml version="1.0" encoding="utf-8"?>

   2: <xliff version="1.2" xmlns="urn:oasis:names:tc:xliff:document:1.2" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="urn:oasis:names:tc:xliff:document:1.2 xliff-core-1.2-transitional.xsd">

   3:   <file datatype="xml" source-language="en-US" target-language="de-DE" original="LocTesting_Multilingual.prilog.xml" tool-id="MAT" product-name="LocTesting" product-version="Version 1" build-num="1.0.0.0">

   4:     <header>

   5:       <tool tool-id="MAT" tool-name="Multilingual App Toolkit" tool-version="1.0" tool-company="Microsoft" />

   6:     </header>

   7:     <body>

   8:       <group id="Resources">

   9:         <trans-unit id="Resources\SomeTextBlock\Text" translate="yes" xml:space="preserve">

  10:           <source>Good morning!  Have a nice day!</source>

  11:           <target state="new">Good morning!  Have a nice day!</target>

  12:         </trans-unit>

  13:         <trans-unit id="Resources\SomeButton\Content" translate="yes" xml:space="preserve">

  14:           <source>Click to Save</source>

  15:           <target state="new">Click to Save</target>

  16:         </trans-unit>

  17:       </group>

  18:     </body>

  19:   </file>

  20: </xliff>

Now you send those off for translation by right-clicking on the XLF file and choosing Send for translation which will give you a dialog to choose if you want to mail them or save to a folder and which format (TPX/XLIFF).  At this point your translation process can begin.  If you don’t have a translation process where you would normally send the XLIFF files, you can use the MAT Localization Editor that is installed with the toolkit.  Launching this tool and opening your XLIFF file will allow you (or the person doing translations) to edit the files with the correct value.  The MAT editor also has the Microsoft Translator capability as well.  Here’s an example of the above German file in the editor with one value translated by the Microsoft Translator:

Once you have the edited XLIFF file you import that back into your project.  Notice there are some other workflow-related properties in the XLIFF (i.e., Signed off, ready for review, etc.) that you can enforce.  Right-click on the XLF file in your project and choose Import translation and the XLIFF file that was modified.  Once imported, when I build next the signed-off items will be indexed within my app’s resource lookup (resources.pri) and packaged.  You will not see any new RESW files generated as using this process does the indexing during the build process with the XLF file and a build task.

Amanuens

Another tool that I’ve come across is Amanuens, which is more of a service/tool than anything that integrates into Visual Studio or runs on your machine.  This service acts as a broker to translators.  You basically create a project and then upload files to be localized.  After you login and create a project (specifying the type as Metro as they now support Windows 8 application file types) then you upload your “master” RESW/RESJSON file.  After doing that you can assign a translation and this is the core of their service.  You can assign a file for translation to a person that is a user on the system as you may have a German speaking friend who might help you out.  Or you can assign to an agency and get a quote:

This way you can send it off and wait.  Either way when the translation comes back you just download the file, put it in your project in the appropriate folder and rebuild your app.  Amanuens is a pay service with a free option, but if you have an app and want to manage the workflow of that process, it seems like a pretty cool service.  They also have automatic source control synchronization that you can opt-in for so as your translations come in, they are automatically in your app via a repo sync.

Culture-correct localization

While all the above tools are awesome and fast to get you started, to build a really targeted localized app it is highly recommended you do more than machine translation, or at a minimum verify that machine translation.  Many times, especially for east Asian languages, the machine translation can be grammatically incorrect or sometimes culturally insensitive as most do dictionary-based translation rather than really understanding any context.

I recall a time in high school where a classmate went to Germany for exchange.  Having taken 6 semesters of German she felt pretty confident in her skills.  Little did she know her hoch Deutsch would prove to be a problem.  Upon arrival she went to a café with some friends and proclaimed she was hot.  However, her dictionary translation was bad and she effectively said “I’m horny” which immediately caught the attention of all the men in the room.  So it is key to understand context and culture when translating!

For this services like Amanuens really help out in both the flow and identifying a person to do the translation.  If you don’t know anyone who speaks Swedish, but want to target that market, using a service could help you get more culturally-correct translations for your app over just machine translation.  This, of course, does not come without a cost, but usually it is minimal and is a one-time translation.

One thing I’d love to see happen is somewhat of a co-op of software developers from around the world to offer translation help.  Working at Microsoft I had the chance to get correct translations of my Sudoku app for German, Japanese, Korean and French.  It was helpful to just send off the RESW file and get back the translation from a human who speaks the language and understands technology terms as well.  A service like Amanuens can help facilitate that co-op having a bank of users that are willing to donate their translation services for your project.  I think the struggle is that it is mostly English apps that need the help and hard for an English person to really reciprocate the value.  But if you are willing to help out other software developers perhaps we can start this co-op idea?

Testing your localized app

[!!_Śò ẃĥâт đõ Уôú ďó įƒ ўôú đõи'ť ћãνê тŕáйşłâţêď ţę×т ýęţ áйď ẅàήт тó тęšť ÿòµѓ ãрρ?_!!!!!!!!!!!!!!!!!!!!!!!!]

Could you read that?  Squint a little more.  It is what we call Pseudo Language.  Not a ‘real’ language but something that simulates a lot of different characteristics of localized language challenges.  Using the Multilingual Toolkit you can have all your strings translated to this Pseudo Language (sometimes called “ploc” within the walls of Microsoft) to test your app before your real language translations come in.  Using ploc helps you identify various artifacts that may exist in localizing an app.  Let’s take a simple example from above.  We had a button that said “Click to Save” in English and we translated it to German.  When rendered it would look like this respectively:

Notice that the German translation didn’t fit within the Button MaxWidth we had set because the translation of the text was longer than our English version.  Testing this is important for us to realize we need to change the constraint of the XAML sizes to accommodate our languages that we are targeting.

Historically testing localized versions of apps may have been challenging requiring you to install a language pack, try to navigate menus that you may not understand, or relying on others to verify for you.  In Windows 8, this process has become easier using the language list preferences.  The Building Windows 8 blog had a post called “Using the language you want” which talks about this concept in detail. 

NOTE: If using the Pseudo Language option and you want to test, when in the Language panel search for “qps-ploc” and you’ll see it under English (qps-ploc) as an option and then you can really test the boundaries of your app with the ploc strings!

Effectively as a developer I can go into the Language panel, add German, set it as my first language and run my app.  Now I’ll get my German resources first and I can visible verify things that need to be changed without installing any language pack on my machine…and I can quickly change back without any reboots.

Summary

Developing your application to be world-ready doesn’t have to be a huge undertaking and can turn out not to be difficult at all for your app.  While not every app is going to be the same and how you choose to architect your code may dictate how you get your resources, the concepts are still the same and starting with the mindset that your app may be localized at some point is the right thing to do.  Using RESW/RESJSON from the start and understanding the options you have for extracting those resources will make localization later very easy…in fact in some cases as easy as just putting in the updated RESW file and recompiling.

Start smart from the beginning and think global even if you aren’t ready for it just yet.  You never know when your German friend might help out translating for you and then you can instantly expand to that market within a day!

Hope this helps!

Just a little post to point out a hidden gem if you are a .NET developer creating a Metro style app: you can bind to anonymous types.  This came up in a discussion with a customer today that I was having and, frankly, I never tried it until then because my mind was back in Silverlight where this isn’t possible.  There may not be a tone of cases where this is valuable for you, but knowing it is there may help.

Let’s assume I have a basic class Person:

   1: public class Person

   2: {

   3:     public int Age { get; set; }

   4:     public string FirstName { get; set; }

   5:     public string Gender { get; set; }

   6: }

And in my application I have a list of that Person type that I somehow received.  In this example, I’m just hard-coding it right now.

   1: List<Person> people = new List<Person>();

   2: people.Add(new Person() { Age = 38, FirstName = "Tim", Gender = "Male" });

   3: people.Add(new Person() { Age = 9, FirstName = "Zoe", Gender = "Female" });

   4: people.Add(new Person() { Age = 5, FirstName = "Zane", Gender = "Male" });

I can then decide I want to bind to a ListView control which has a particular template:

   1: <ListView x:Name="PeopleList" Width="500" Height="300">

   2:     <ListView.ItemTemplate>

   3:         <DataTemplate>

   4:             <StackPanel Orientation="Horizontal">

   5:                 <TextBlock Text="{Binding TheName}" Margin="0,0,10,0" />

   6:                 <TextBlock Text="{Binding GuysAge}" />

   7:             </StackPanel>

   8:         </DataTemplate>

   9:     </ListView.ItemTemplate>

  10: </ListView>

Notice that I’m binding to properties (TheName and GuysAge) that don’t exist on my Person class?  In my code, I can then create a LINQ query to filter out only the “dudes” from my list and bind that result:

   1: var onlyGuys = from g in people

   2:                where g.Gender == "Male"

   3:                orderby g.FirstName descending

   4:                select new

   5:                {

   6:                    GuysAge = g.Age,

   7:                    TheName = g.FirstName,

   8:                    Gender = "Dude"

   9:                };

  10:  

  11: PeopleList.ItemsSource = onlyGuys;

The result is that my ListView now shows 2 people in the list.  Nice.

Get in the real world

Now I would probably agree that since you already have a strongly-typed class this is probably not the use case here.  It certainly might be helpful, but you already have a class (and in this example, one that you completely control so you could shape it to be what you really need).  What about those times you don’t have a class or you don’t own the type coming back?  JSON ring a bell?  Using the sample JSON response (I’m not focusing on how to retrieve data here just how to bind to it) from Twitter APIs, we can demonstrate how this might be more helpful.  Here’s the Twitter JSON data I’m referring to in this example: Twitter Mentions API.

My app wants to retrieve and bind to Twitter data but I don’t really want to have a “TwitterResponse” data type that I have to serialize in/out in my code.  The mention data is an array of mentions.  For the sake of simplicity I’ve basically put my JSON string in a file rather than confuse this sample in how to work with Twitter.  My code looks like this (assume that ‘data’ is the resulting Twitter mentions JSON string:

   1: // parse the data into a JsonArray object

   2: var mentions = JsonArray.Parse(data);

   3:  

   4: // build the query out of the mentions

   5: var qry = from m in mentions

   6:           select new

   7:           {

   8:               MentionText = m.GetObject()["text"].GetString(),

   9:               FromUser = m.GetObject()["user"].GetObject()["screen_name"].GetString(),

  10:               ProfilePic = m.GetObject()["user"].GetObject()["profile_image_url"].GetString()

  11:           };

  12:  

  13: MentionData.ItemsSource = qry;

Notice the LINQ query for creating a “new” type that I will bind to my ListView.  In my XAML I have a simple DataTemplate to demonstrate:

   1: <ListView x:Name="MentionData" Width="500" Height="300">

   2:     <ListView.ItemTemplate>

   3:         <DataTemplate>

   4:             <StackPanel>

   5:                 <TextBlock Text="{Binding FromUser}" />

   6:                 <TextBlock Text="{Binding MentionText}" TextWrapping="Wrap" />

   7:             </StackPanel>

   8:         </DataTemplate>

   9:     </ListView.ItemTemplate>

  10: </ListView>

The result is me being able to create a LINQ query and create a new anonymous type and directly bind to it.

Voila!  Perhaps you already discovered this little gem and are using it.  It is a welcome addition to the data binding story for Metro style app development with XAML and .NET!  Of course the same benefit can be had for XML data using XLINQ queries, so while this example is for JSON data, really any source data applies…it is all about that new anonymous type you create!

Hope this helps!