So far, everything is strings except for some weird metadata with no key name, which is an object. Horrible explanation, code incoming. Here's a "pretty" version of the generated `$ cat app/i18n/an/client.json | json` file locally:

```json
{
  "1991": "",
  "1992": "",
  ...
  "2005": "",
  "2006": "",
  "2007": "",
  "": {
    "project-id-version": "PACKAGE VERSION",
    "pot-creation-date": "2014-02-19 21:13+0000",
    "po-revision-date": "YEAR-MO-DA HO:MI+ZONE",
    "language-team": "LANGUAGE <LL@li.org>",
    "language": "",
    "mime-version": "1.0",
    "content-type": "text/plain;",
    "content-transfer-encoding": "8bit"
  },
  "old and new passwords must be different": "",
  ...
```

So without knowing exactly what we're getting back from the translators, it looks like all the keys/values are strings (including the numeric-only years). The one exception being the "" key which has no name, but is an object with nested `product-id-version`, `pot-creation-date`, `po-revision-date` keys. The only validation I attempted there was saying that the "" key has an object data type, I didn't try getting fancy and validating sub properties and are the `[blah]-date` fields valid dates, or is the `language` value non-empty, or is the `product-id-version` a parseable number, etc.

My validation logic was basically "are all the required properties there? Do all the data types match whatever values are in the .pot files (via the awesome po2json script).

Heck, here's a gist of my generated [client-schema.json](https://gist.github.com/pdehaan/87b2e60a46484a412291) and [server-schema.json](https://gist.github.com/pdehaan/87b2e60a46484a412291#file-server-schema-json) files. My first time playing w/ z-schema, so there are probably some improvements I could make if I had any clue what I was doing. Not sure if this protects us against extra, unexpected properties. That was still on my internal todo list of things to investigate.

We probably want to reconsider this PR and see if its worth it and if I understand half of the translation rules. I think my main concern was that we'd have some translations that are missing a key or have an extra key, so I wanted to keep everything in sync as much as possible. Plus I mainly wanted to try and understand Grunt file I/O and JSON schema validation.