AHGmail mis-translating our English-only emails into other languages
We've noticed an issue recently where Gmail's auto translation feature will occasionally think one of our marketing emails is in a language other than English, with a banner across the top asking the reader if they want to translate the email into various languages.
For the record, all of our marketing emails are in English only. But to date I've seen Gmail misidentify one of our emails as being in Hungarian, Norwegian, and even Czech.
We use Responsys to send marketing emails, follow best practices for permissions-based email marketing, CAN-SPAM compliance, and deliverability. This only seems to happen to emails that contain dynamic content for personalized recommendations.
The weird translation error does not always happen with emails that contain dynamic content, but up until recently it did not seem to effect inbox placement so we were not too concerned. But now we've noticed some of these emails being marked by Gmail as spam, even with users who are highly engaged with our emails.
I'm wondering if anyone else has experienced this bizarre Gmail translation issue, especially if you use Responssys.
Thanks,
Alan
Do you have a
langattribute in your code?You should always add one to the
<html>elements, but it's also good to add one to an element that's wrapping your code for when the html tag is stripped.Mark, I checked our templates and we did not have the
lang="en"attribute, so I added it to the<html>tag.Looks like it worked! Thanks so much for the quick and easy fix.
Unsure from which ESP emails are coming from, but I've seen plenty of emails arrive in my Gmail inbox which Gmail ask to be translated to English from another language, even if they are already in English. If it's not effecting inbox placement or engagement rates, I wouldn't worry too much about it.
The only thing I would add to this is that if someone is on the fence about marking something as spam or not, and they see an e-mail is asking to be translated from some random country, it could cause them to mark it as spam when they otherwise might not and just optout instead. This higher rate of spam complaints could then impact deliverability.
I agree with Jonathan here, inbox placement is obviously extremely important, but having Gmail indicate to an on-the-fence subscriber that you email is possibly in a random non-English language is likely encourage a negative response.
We are Responsys customers experiencing the same problem http://jwage.com/post/168014035296/gmail-translation
I have lang="en" on the <html> element and the problem persists. Any ideas?
Hey Jonathan,
That sucks to hear! We tried lang="en" and it seems to have fixed the problem... for now.
Do your emails also contain RPL/Responsys Personalization Language/dynamic content? I'm convinced that Gmail is misinterpreting the RPL and thinking it's in a non-English language because it never seems to happen when there is no data personalization.
Hi
Do you have a solution for this problem yet? we experience the same problem but can't find any solution.
Yes, we use RPL heavily. Though gmail wouldn't ever see the RPL, it gets evaluated on the Responsys server-side before the html is sent to the e-mail address.
So I may have spoken too soon, because I noticed today the Google Translate issue is back despite having added both
lang="en"andxml:lang="en"to the opening<html>tag...Dang. That is too bad. It is still happening for me too.
Hi Alan, I came across this discussion and I wondered if you had any luck resolving this issue?
We have found (empirically) that mails containing a lot of CSS and HTML before any actual content get classified as English even though the content is in another language.
Our workaround is to send a multipart text and html email, with a text version before the html part. Of course the text must be consequent, not just "Bonjour ...", as otherwise the HTML tags/CSS are still dominant.
The translation algorithm does not seem to make any attempt to strip out html/css from the body of the mail, or if it does, perhaps it truncates the message before stripping and so ends up with very little content to use for detection purposes. (It is easy to end up with >5000 caracters of headers and CSS these days before a single line of content.)
<html lang="fr"> did not help in our case either.