Great article, I had to do something similar few years back. Good to see some of the ideas we had were the same. Just wait till you have to mirror the site for Arabic etc. That's when it gets fun.
It seems you're already over the hurdle of not assuming other languages have the same grammar as English. From my experience (internationalizing a site for English and Japanese with both heavy back and front end rendering) with that groundwork laid, at least Japanese is relatively simple.
A favorite solution for varying lengths of content is html's flex box. Luckily I only had to support WebKit.
How can a website nowadays need 9 months to add a new language? I mean good article, but seriously. If you have to refactor your whole codebase to add i18n, you did it very wrong in the first place.
A small product built in one of today's modern frameworks? Sure, that'll be much faster. 5+ years ago when 99designs was kicked off, the landscape looked much different.
Importantly, the founders choices allowed them to iterate quickly and essentially capture global Anglophone market for our product. If that made i18n a little harder, it was no doubt still a good trade-off to make.
We did something similar due to very old/messy code, but not with a 3rd party service. We just built an Apache OutputFilter that recognizes text (also in alt, title, button value attributes) and replaces it based on a set of more than 200k regexps. Sounds slow, but works fine due to (tmpfs + mmap based) caching after some warmup. The first working prototype took about 4h.
