Alright, I've managed to get this working on my site.

I decided to use Konkani because it's at the bottom of this list.
Steps are as follows:

1. Duplicate the resource file you want to change. I changed blogresources.resx in my case.
2. Rename the file to use the language extension you want, as found in the link Joe shared.
3. Open the user.config and add your override code as found here. In my case I added two keys:
   <add key="UseCultureOverride" value="true" />
   <add key="site1uiculture" value="kok" />
   It is important to note that you should probably only use the uiculture for this, so your date and time format strings aren't changed.
4. Change your new resource file to include what keys you want. It is probably a good idea to remove all of the keys except for the ones you want to change.

A really great aspect about this method is that mojoPortal already supports using different cultures for each site in your mojo installation, so it makes it easy even if you have multiple clients on the same install or if you want to use different text for your own different sites.

Thanks again Joe, this will work well for me I think.
-Isaac

The only limitation for this technique is it can only be relied on if English is the default fallback.

It is possible to force a different language as the default from web.config <globalization element, but if you change it there to a language that has any missing keys or files it will cause null reference errors. The only language we have where the resx files are guaranteed to never be missing any files or keys is English.

So for example if I'm forcing my site to French using:

<add key="site1uiculture" value="fr-FR"/>

then I need to keep English as the default so that no errors can happen.

Therefore if I'm forcing the site to use French already I cannot also force it to use another language resx files for overrides.

If I made sure that there were no missing keys or files for French, then I could set the default to French in the <globalization element, and then I could force the site to use a different language and take advantage of this technique. So it isn't impossible, if anything it may encourage more help with keeping translations up to date. (Too bad about Ammanuens going away I wish there was something else equivalent but don't know of anything).

Still this technique can be used by lots of people and it is pretty clever. I will compile the info from this thread into a documentation article soon and give credit to Isaac for the great idea.

As far as which language to override, it only matters whether its a language you might ever care to support in your own site. Since additional languages are downloaded separately it really only matters whether it would ever conflict with a language whose resx files you did want to deploy.

Although recommending a specific one in the article might be fun, like if we use Konkani we could dub this technique the Konkani technique or the Sanscrit technique which might be catchy ;-D

But another idea is to force a variant of English that we won't likely ever have resx files for like en-ZE which is the Zimbabwe variant of English, and if we get visitors from Zimbabwe on our site chances are they will be able to read it just fine anyway.

Definitely the override resx files should only contain the keys you are actually overriding in any case, that way if something changes for an existing key that you are not overriding you will get it from the default English files. Also I think that makes it easier to manage because you know exactly which keys you are overriding when you open one of those files since there are not any keys in there that you are not overriding.

Best,

Joe