Typography and language as a WordPress theme developer

Today I have submitted Museum Core version 1.0.9. Unless there are any major issues with the update, it should get approved and be available in the WordPress themes repository in the next couple days. Among other features both under the hood and out in the open, this is the first version of any theme I have ever written with a full translation in another language thanks to anemoone‘s Polish translation. I’ve had to teach myself a lot about the internationalization (i18n) process, about proper use of _e, __(), _n, sprintf and how and why those are different from echo which I’ve learned both through managing the i18n process for Event Espresso and through the theme review process. However working with an actual translator made me discover things I had previously not considered about typography and how it changes depending on what language you are looking at it in.

The first thing I had to address was that I was _doing_it_wrong, at least in terms of i18n. I was dealing with typefaces from a programmer’s and a designer’s standpoint — not from the standpoint of someone actually looking to use the theme in another language. While I could say “yes, this theme supports translations” I wasn’t doing it in a way that was actually very supportive. A designer/developer will look at a font file and try to cut the file size as much as possible to decrease page load time. One way to do this is to strip out non-latin characters. That’s great for English speakers, but it means that everyone else is left in the lurch. Rather than rebuilding my font files with the extra characters included, 1.0.9 is letting Google handle the heavy lifting of supplying the fonts because, presumably, their servers will serve the entire character set faster than yours will.

The second thing is typeface design. I will freely admit that I have my own tastes as far as typefaces go, and that colors the fonts used in the themes that I build. I have a strong dislike for Times New Roman, for example, and while I like Georgia, I feel it’s over used. While it’s not my favorite serif typeface (that would probably fall to Goudy Bookletter 1911, but that didn’t really fit with the clean and modern design of Core), I included PT Serif in Core as a serif option because it has many similarities to Times and Georgia while not being too spindly (like Times) or wide (like Georgia). However, all of that goes out the window when you are looking at a typeface in a different language. Our eyes naturally follow the shape and contours of the letters in our own language, but I couldn’t tell you what an attractive type in Poland would be. Not only do the letterforms follow some different rules, but there are different tastes and preferences in what an attractive typeface is. So when I was told that some of my embedded fonts didn’t support Polish characters, I asked what a good font for the Polish language was, and was pointed in the direction of Lato, by a Polish designer. To me, it just looks like a bit of a squat sans-serif (at least when compared with Droid Sans), but who am I to judge its ability to display Polish characters like ł and ą in an attractive and readable way?

We all interpret words differently. We bring different experiences to the act of reading an article or blog post, so different things will resonate with each of us. What we as designers and developers (especially for open source software that may be used in other parts of the world that we may never have even considered — as opposed to client work for a specific person or organization in a native-language-speaking country) may not appreciate is that the same rules apply to type and design — what is seen as attractive and appealing in Tokyo is certainly not the same thing as what we see as attractive and appealing in Utah. The internet is making the world more of a melting pot than it was before as styles and trends from one part of the world affect preferences in another. Even so, individual preferences and tastes will always be unique, making design a unique challenge when you are trying to appeal to a range of potential users.

Theme Frameworks

What’s the next big thing in themes right now? Theme frameworks. Everyone is doing it. WooThemes has their own core framework, StudioPress has Genesis, now MojoThemes has partnered with Themify to use that as their own in-house framework. Plus there’s themes that can be used as frameworks all over the place, from Builder to Justin Tadlock‘s Hybrid to WordPress’ own Twentyten.

What’s the big deal with frameworks?

Frameworks make a theme designer’s job easier — even an armchair one who just wants to recolor the background and add a couple fonts.  They also make it infinitely easier to maintain a bunch of themes.  Think about it: you’re a theme developer and you have written a handful of themes.  Which is easier to maintain?  Six individual themes, or a single theme framework upon which all of those themes are based?  The answer is simple: it’s much easier to deal with a single framework and only have to tweak the individual themes if there’s a specific bug or feature enhancement.  And the WordPress API makes it easy to take a function built into your framework of choice — or even WordPress itself — and change the behavior of it, tweaking it to the particular needs of the theme you’re designing.

This is a concept we’ve been playing around with for a while, trying to figure out how to build a model out of it.  Up to now, all of our themes have been loosely based on the free AP-Blueprint theme framework we built and maintain here.  Each theme starts with that framework and evolves from there.  That gives us  good starting point for coding, but it doesn’t solve the problem with having to maintain half a dozen or more individual themes.  There’s got to be a better way, right?

Here’s the plan…

This is the idea I came up with the other night: we do the theme framework thing.  We build a single theme framework upon which all of our themes will be based.  We adapt all the current themes we have to use this single theme framework as child themes.

Then we make the framework completely free.  Ideally, we get it added to the official WordPress theme repository.

If you want to use our framework to build your own themes, or even start your own business: go for it.  Once we get it added to the repository, you’ll benefit from automatic updates and the knowledge that the framework meets WordPress’ high quality standards.  All of our themes will stay the same, simply enhanced by a core framework that can be regularly updated.  Not only that, but having a single framework and building all of our themes as child themes means that we can design new themes much faster.

Win-win, right?  You may applaud politely now.

So when’s the switch?

I’m currently mulling over a new theme design that will hopefully be ready in the next month or so.  Said new theme design will be the first to be built entirely on the new theme framework.  Once that’s done, I’ll start porting over the other themes to use the framework.  The framework will most likely be a modification of the AP-Blueprint theme but will be able to be used as a standalone theme if you so desire.

I won’t say anything about what the new theme design will be, but I will say this: it rhymes with Mean Crunk.