I'm not sure I fully understand, but I don't think there's a need to completely throw everything out.
The wrappers go around english strings, because using token strings is horrible in terms of legibility and converting existing strings, and also goes against gettext's standard.
The interface of the wrapper's is as it is because of maintaining compatibility with the old translation method, but if we adopt gettext fully (recommended) the interface could obviously be changed.
There are a few places where the wrappers are used around segments of strings side by side in template pages, which preserves english order (which I think is your point..?). This isn't a fault of the translation mechanism, rather it's a fault of my lack of time, and can easily be changed. It doesn't need a rewrite of the translation engine, it just needs those templates to be modified and the strings updated.
Also, you can totally pass variables to translation engine. I may not have done this in some places, because time :)
Latest code has some more logging, might want to give it a try...
@gomezr Yes and no. Known doesn't internally make much use of caching, but this tool is a utility that could be used in high load environments if you modify your code to make use of it.
If you have a single user install you _can_ use the domain, but you have to explicitly set "single user" mode. This is because that mode puts the user header on the top of the front page, which has all the rel=me links that IndieAuth uses...
Hmm... bridgy seems to not like private accounts. I'll see if I can create a new instagram and try again...
Hmm... do we have a record of what's sent to known / getting from known? (I've not got a public instagram, so not tried to replicate)