Customizing MailChimp Using Translations

It seems like email opt-in forms are here to stay on websites, so I’ve spent a lot of time playing around with customizing and embedding them. While I love how easy MailChimp is to use, I find that it’s not entirely straightforward to customize the wording used, especially the form validation and confirmation messages.

Fortunately, it is entirely possible once you understand that MailChimp bundles all wording changes to those areas with language translations. There are two places to look to modify the wording, whether it be to a different language or just to a different way of saying the same thing in English.

1. Thank You Messaging

One of the most common wording requests clients’ have is for the confirmation message on embedded forms after the email address is submitted. By default it’s a pretty long message, which is both not that user-friendly (in my opinion – I’m a fan of short messages), and is hard to style into many opt-in areas.

You can find the fields to “translate” that wording when you go to edit or style the account forms. It’s a bit of a trip to get there:

Lists > click on list name > “Signup forms” tab > General Forms

Select the “Signup thank you page” from the dropdown list of different forms and form states, then click on the “Translate it” tab. You’ll see the available text strings:


The three to edit for that inline confirmation message are the “Almost finished…”, “To complete the subscription process…” and “We need to confirm your email address” lines. You can’t leave fields blank so you’ll have to come up with something short and pithy or cheat by breaking your sentences over the fields.

You can edit the regular page text for the MailChimp-hosted confirmation page separately from these fields, so I think breaking it over fields is safe but fair warning that I haven’t tested it super extensively to find any edge cases.

2. Error Messages

The newer MailChimp embed code has actually taken away most of the need for my custom embedding method, although I still use my method when I need multiple forms in a page since I can customize the selectors.

Either way, you end up with form code and script code, something like:

<!-- Begin MailChimp Signup Form -->
<div id="mc_embed_signup">
<form action="//" method="post" id="mc-embedded-subscribe-form" name="mc-embedded-subscribe-form" class="validate" target="_blank" novalidate>
    <!-- form code here -->
<script type='text/javascript' src='//'></script><script type='text/javascript'>(function($) {window.fnames = new Array(); window.ftypes = new Array();fnames[3]='FNAME';ftypes[3]='text';fnames[4]='LNAME';ftypes[4]='text';fnames[0]='EMAIL';ftypes[0]='email';}(jQuery));var $mcj = jQuery.noConflict(true);</script>
<!--End mc_embed_signup-->

As a side note, I always completely delete the included style components and in the above snippet I’ve also removed the actual form components and a bunch of the script contents to make it shorter. You can customize the form fields, labels, placeholders, etc., just by editing the HTML, although be careful to keep things like IDs and names the same unless you really know what you’re doing.

In order to translate the validation messages, you can add the following snippet inside the MailChimp-provided embed code, before the closing </script> tag:

    To customize your embedded form validation messages, place this code before the closing script tag.
$mcj.extend($mcj.validator.messages, {
    required: "Please enter your email",
    remote: "Please fix this field.",
    email: "Please check your email address.",
    url: "Please enter a valid URL.",
    date: "Please enter a valid date.",
    dateISO: "Please enter a valid date (ISO).",
    number: "Please enter a valid number.",
    digits: "Please enter only digits.",
    creditcard: "Please enter a valid credit card number.",
    equalTo: "Please enter the same value again.",
    accept: "Please enter a value with a valid extension.",
    maxlength: $mcj.validator.format("Please enter no more than {0} characters."),
    minlength: $mcj.validator.format("Please enter at least {0} characters."),
    rangelength: $mcj.validator.format("Please enter a value between {0} and {1} characters long."),
    range: $mcj.validator.format("Please enter a value between {0} and {1}."),
    max: $mcj.validator.format("Please enter a value less than or equal to {0}."),
    min: $mcj.validator.format("Please enter a value greater than or equal to {0}."),
    mc_birthday: "Please enter a valid month and day.",
    mc_date: "Please enter a valid date.",
    mc_phone: "Please enter a valid phone number.",

Then you can edit the text strings inside the quotation marks to change the wording. Again, this is a place to be judicious in your changes since it error messages are pretty important to user experience.

Customize MailChimp inline form messages using translations – who knew!?

Two “Where Have You Been All My Life” WordPress Plugins

There’s a type of WordPress plugin that provides functionality that is simple and targeted but so useful that once you’ve got it you wonder how on earth you functioned previously.

Here are two such plugins that I’ve started using recently and now install on almost all of the sites I work on:

1. Schedule Posts Calendar

schedule post calendar screenshotIf you ever need to schedule blog posts to publish in the future (which I think is probably everybody who blogs), you’re familiar with selecting a post date and time.

The problem with the “normal” way of doing this is that you’re just looking at numbers. For me, that means I have to reference a calendar to figure out the day of the week for each date.

Yes, it’s a total first world problem but it’s annoying and it’s unnecessary given that there’s a handy little plugin called Schedule Posts Calendar that adds a calendar picker to that area, letting you click to select a date (and time).

A calendar picker for scheduling WordPress posts? Yes please! It also has a “Today” button in case you want to jump to present.

2. Admin Collapse Subpages

Some sites end up with a lot of pages and subpages, which the admin “All Pages” screen is really not well set up to handle. At a certain point a humongous list of page titles with hyphens indicating hierarchy is basically unusable.

Don’t worry! The Admin Collapse Subpages plugin does exactly what the name implies:

pages with subpage collapse screenshot

It gives you that nice little +/- next to each parent page so that you can collapse all the subpages. So easy, so functional.

What are your must-use utility plugins for WordPress?

Industry Tips for Responsible Code

I recently was introduced to a new (I think) site called Code Responsibly via a comment on my post about the importance of soft skills for developers and I think it merits its own post.

Code Responsibly is a simple but powerful project with 10 tips from some really smart people in the industry (but, refreshingly, not all the “rock star” names you see all over the place) with the goal of helping developers avoid “reckless code.”

tips from Code Responsibly

I especially love how the tips focus not on which language is best but on general things we can all always stand to improve on, no matter where we are career-trajectory-wise. The two tips shown above are major areas I want to focus on in 2015 (along with learning and quality which also appear on the list and are baselines for my practice).


On Naming Media Queries & Abstraction

Yesterday there was some conversation on Twitter about naming media queries using variables, sparked by this tweet from Brad Frost:

At first I read that tweet and thought to myself, “I think I might disagree…” I know that those words are a little tricky because the person using the site at “mobile” width could very well not be on a mobile device, but I’ve used them myself in some cases because they’re still fairly general and easy to remember. Better than “iphone 5, “iphone 6s, “13 inch macbook pro” as another person jokingly suggested.

I skimmed through the replies to that tweet and saw various tweets from people who use name their media query variables after TV show characters or colors and thought to myself, “I ABSOLUTELY DISAGREE!”

Then, I noticed that Brad’s response when Alex Carpenter asked him what he suggests instead:

I calmed back down at that point because, upon pondering a bit further, I think I actually do agree with Brad.

I can absolutely see why it’s probably not a good idea to bring context into media query variables – since the context is really pretty distinct from the width these days it’s a false association. However, I think it’s worse to abstract too far and come up with variables that are memorable to you but will be confusing as heck to other people who may encounter your code down the line (or who don’t appreciate the same pop culture references).

Moving forward, I think I’m going to try to stick to neutral terms like those Brad suggested in his second tweet, maybe using something like t-shirt sizes as suggested by one or two other people: xs, s, m, l, xl. That feels like a good level of abstraction without taking it too far.

I’m curious, though – for those of you who use media query variables, what do you use? What do you think about super abstracted/ personalized variables?

It’s Okay to Just Do a Part of the Project

There’s kind of a weird idea floating around in the freelance/ small business world that it’s “better” to land big projects and to own the entirety of each project. That it’s the big brands and big project scopes that “make” you.

While there’s some truth to that (my projects with big names in my niche have certainly helped me out in terms of exposure), I’ve also found that taking on projects where my role is just one piece of the puzzle can be satisfying and can open up a lot of opportunities I might not get if I were trying to do the whole thing every time.

Some of the biggest brands that have approached me have been looking for internal sites, or for “just a blog” to add onto an existing infrastructure.

Minted's blog

Minted’s blog Julep was one of those projects, where I came on board to build just the blog (designed by Bri Emery of designlovefest).

Another is the blog portion of the redesigned and relaunched Makeshift Society website:

Makeshift Society's blog

In both of these cases, the main site is a complex build on a custom or enterprise-level CMS, which is not really my thing. Blogs, however, are something I do quite a lot. That specialty keeps me in the running for a lot of companies that have their own systems for the bulk of their web presence but don’t have the in-house skills or interest for that specialty area.

The Honey Bee blog from Burt’s Bees Baby™ (a project I took on with Aeolidia) is another example where I was only responsible for the blog coding:

Burt's Bees Baby blog

It does take some mental adjustment, though. It can be kind of humbling to not work on a brand’s “main site” and just take on a segment of the project, and even more humbling to work on something that will only ever be seen internally. For me, it’s always been worth it.

This idea that it’s ok to just take on a part of a project isn’t anything groundbreaking, but I still believe it’s worth putting out there in writing.

Whether you’re a designer who is making spot graphics while another team redesigns the whole website, or a developer with a specific area of expertise that relegates you to working only on a subset of features, you should work towards whatever kind of project makes you happy and makes your work rewarding. But I also think that it’s okay if sometimes those projects are the smaller, less flashy pieces of the overall puzzle.