I'm going to edit this as another answer, so it will get seen - and will removed it as a comment, since it offers a new path.
I started looking at the problem in detail, and tracked the error handling and its translation back into Yii as handler. Translation of Yii stock form error messages should just work.
Then I looked again at your site, and messages are in French, e.g. invalid email, even though the site is presenting in English, which I presume is your problem. I imagine French is the base language of the site, which shows I think that the translation is active for templates.
So maybe your problem is not fully switching to English as far as Yii is concerned.
Are you setting define('CRAFT_LOCALE', 'en_us'); in your /en/index.php file?? In my experience it has to be en_us to match the standard translations. If you set it up as en only, for example, your templates could use your English template versions depending on your other settings choices, but not I think access the stock translations, like these form errors.
Maybe that's your problem?? I don't think Ajax is any part of the problem, as the same (translated) error strings would be passed there as are made available for the template. If you look at the error handler which does Ajax also.
Here's another edit. I'd like to present the relevant portion of a properly configured general.php file for three languages, which successfully presents in-locale Contact Form error messages in English, Russian, or Swedish depending on the operating Locale:
'environmentVariables' => array(
'siteStore' => '/storage/avNNNNN/www/the_site_html/public/',
'sitePath' => 'http://www.thesite.com/',
),
'siteUrl' => array(
'en' => 'http://www.thesite.com/en/',
'ru' => 'http://www.thesite.com/ru/',
'sv' => 'http://www.thesite.com/sv/',
),
etc..
The magic coding in Craft will properly handle https operation automatically, and this configuration pattern also makes sure that Live View operates properly in Entry edits. Note you match the 'en' 'ru' etc.. to however you've defined locales in Locale CP config screens, not necessarily to more specific variants like en_us.
I use the sitePath and siteStore as {sitePath} for example in Asset definitions, so that their paths will come out correctly on the base site rather than the language variant path. This affects Live View for instance also, makes it work.
Yes, it's all very sensitive, precise, and not yet fully described in doc here, unless they caught up on it in the last update which included much doc. I've asked...and they are very busy producing towards all of need.