Some of the transforms in the page library currently require localized strings to be passed in as arguments. They are to be added to the DOM during these transformations. Currently this the apps have the translated strings and pass them in when they invoke the transformations client-side.
It would be good to already know the translated strings on the server side (and pass in the locale, and be aware of potential language variants).
 Change the transforms to take a Locale as a parameter instead of the translated strings.
 Need to set up I18N either in page library or PCS.
 Probably need some mapping of domain names to locales; deal with language variants some more.
Examples of strings:
* `description_edit_add_description`: "Add title description"
* `table_infobox`: "Quick facts"
* `table_other`: "More information"
* `table_close`: "Close"
`FooterTransformer` and `References` would have some more strings if we go this route.
When we want to run these transformations server-side we have two main options:
1.) We already need to know the translated strings on the server side (and pass in the locale, and be aware of potential language variants).
* Need to set up I18N either in page library or PCS.
* Probably need some mapping of domain names to locales; deal with language variants some more?
* These strings seem more UI chrome than actual content.
2.) We defer making additional DOM manipulations on the client side.
* Extra additional DOM manipulations needed on the client side -> flash of content either showing English first or nothing first; slower to display correct content. This is worse in `mobile-html` since the client side DOM transformations run actually later than in the old model where a nearly empty HTML was used as the starting point.
So, the question is really: Do we want to set up I18N server side?