While I agree this is a possible attack vector, I think it is extremely unlikely, at least in the localization realm, for several reasons: 1. The localization

While I agree this is a possible attack vector, I think it is extremely unlikely, at least in the localization realm, for several reasons: 1. The localization company should never know what programming language you're using. 2. You shouldn't give localization companies direct access to your internal strings. More than hacking your code, they're almost guaranteed to screw the formatting up. 3. Typically, translators are hired for their native language abilities, and not for their technical prowess. I've met precious few who knew how to open a text editor, let alone hack your product via its strings. I worked with Python and I18N/L10N for about 15 years. The way I always handled localization was to parse all our strings into a PostgreSQL database, and then provide a web interface for translators to do their work. This interface provided translators with the full-context of the strings they were translating, which internal strings often don't, prevented the inclusion of certain characters and keywords, and kept the translators from screwing up the formatting. By doing it this way, we got much better translations, and our internal strings were never out of our control.