What Languages Can Your Bulk Email Tool Speak?

, Thursday, March 15th, 2007

Recently, we had two different clients ask us for assistance in finding mass email tools that have built-in support for multiple languages. They were specifically interested in sending out Arabic and Chinese emails to their supporter list.

If you dabble in the area of internationalization (i18n) in tech tools, then you would agree with me when I say that it is particularly difficult to find a technology solution that can fully support languages like Arabic and Chinese. Generally, tech tools are really good in supporting languages that have a Latin-base (ex. Spanish). They are not that great with a non Latin-based language like Chinese. They are downright poor when it comes to a non Latin-based language that also reads from right-to-left (RTL) like Arabic. And, don’t even get me started on RTL languages that share most characters but not all (Arabic & Farsi/Persian).

Before we delve into the multi-lingual mass email support issues, here is an over-simplified version of the technically complex process of creating emails:

Email written up or “encoded” in a language (i.e. Arabic, Chinese, etc.) –> Sent out by bulk mailer –> Received by email server –> “Decoded” for view or display in your email client.

Side note – Problems in the decoding end of things require a separate post, so I will ignore it for now.

Most email solutions including < insert most eCRM and email marketing tool names here > do not go beyond Spanish for their multi-language support line item in the features list. So, no multi-lingual support, no encoding, no sending out, no nothing.

A small number of vendors and solutions support multi-lingual emails, but it ends up being an interim solution. In the encoding process, they create HTML emails where letters are represented by their numeric character references. This is somewhat akin to using & in HTML code to indicate &. All HTML-enabled email clients display this fine for the recipient to read. Most email clients, including the browser-based ones like Google and desktop-based ones like Outlook, are HTML-enabled these days. So, most recipients would have no problems with this solution.

The issue with this approach however is what happens in the back-end. This approach means that you can send out only HTML emails and not plain-text ones. If you viewed the source in these emails, you will see a string of these numeric character references. This means that many of the functions that depend on actual letters instead of numeric references (ex. search) will not work. Sort of reminds one of those Hollywood studio sets that look grand from the outside. :)

This approach runs out of its usefulness if your organization wants to (or is mandated by its mission to) provide the full-spectrum experience to your supporters, donors, and advocates who speak other languages. This is becoming an important need. As I mentioned at the beginning of this post, we recently had TWO clients ask for bulk email tools supporting multiple languages. So, hopefully things would change soon. But, much of this innovation will probably originate from regions where multiple languages are the norm rather than the exception.

A note in the “somewhat related” category – European Union has 23 official languages and India has 22. Conflict of interest or disclaimer or something of that sort – My native language is one of those non-Latin-based languages, so I may have “vested” interests.

A note in the related category – If you are developer, here is a slightly dated, but still relevant article on email, MIME, Content-Transfer-Encoding header, etc: http://www.eveandersson.com/arsdigita/asj/mime/

3 Responses to “What Languages Can Your Bulk Email Tool Speak?”

  1. npdigg.org Says:

    Beaconfire Wire What Languages Can Your Bulk Email Tool Speak?

    Recently, we had two different clients ask us for assistance in finding mass email tools that have built-in support for multiple languages. They were specifically interested in sending out Arabic and Chinese emails to their supporter list.

    If you dabb…

  2. mjp Says:

    Ahhhh…and I thought the encoding issue was finally solved. I remember, back in the day, there were some serious encoding wars going on, especially for Russian. There were two major encodings, KOI-8 (pronounced koi-vosem’) and Win-1251. Not to mention the Mac! It got so bad, at one point, that an organization I worked for decided to opt out of the whole thing, and made their own fonts using a Latin encoding and just changed the glyph that appeared (thing Zingbats!) And now that the encoding war for Russian has ended, they have thousands of pages in this font, and probably a lot of annoyed people who have to download a font to use their site! Egads.

    As far as the foreign language content only being accessible in HTML, well, to me, that’s not enough. We’re eliminating the super low-tech people (who might even be in some of those countries we’re trying to represent) who only use text-only emails, and the high-tech people sending and receiving emails from their PDAs (almost always in text).

  3. dan mcquillan Says:

    aach. the use of numeric character references is horrible!

    of course, the base problem is that SMTP is a 7-bit protocol, so only supports US-ASCII directly.

    but i thought that MIME encoding allowed you to send UTF-8 emails; the headers should look something like
    MIME-Version: 1.0
    Content-Transfer-Encoding: 8bit
    Content-type: text/plain; charset=utf-8

    AFAIK this should allow utf-8 in the email headers and the message body.

    if vendors insist on sending HTML emails then there’s really no excuse for not sending it as properly formed UTF-8.

    i was struggling with multilingual web pages 3-4 years ago, and the way to deliver unicode-encoded HTML was clear. The problems actually came at each end i.e. getting standards-compliant text in, and getting it rendered properly by the user agent (browser).

    getting the text in was getting easier as mirosoft word caught up with various languages, and open office was really forging ahead as well.

    the real killer was getting the browsers to properly render complex scripts like bengali, and also to make available (open source) opentype fonts that allowed them to do so.

    so i note your point that “Problems in the decoding end of things require a separate post, so I will ignore it for now.” Look forward to hearing about your experiences!

    p.s. of course, it’s maybe no surprise that US-based mainstream providers don’t put minority / economically unimportant languages at the top of the product backlog.
    i found it useful to connect to the language communities themselves, via projects like The Free Bangla Fonts Project – sometimes they were way ahead. I actually quote this experience in my write up of digital diasporas & human rights