Cancel

Jeff Chandler

I18n and RTL Support Are Top Priorities For Web Savvy Marketing

photo credit: Sarah Elizabeth Altendorf - cc
photo credit: Sarah Elizabeth Altendorf – cc

This year’s State of the Word at WordCamp San Francisco emphasized WordPress going global through improvements to internationalization. This year also marks the first time non-English downloads of WordPress have surpassed its English counterpart.

Catering to Customer’s Needs

With WordPress raising the bar, it won’t be long until users and customers expect themes and plugins to be translatable and available in multiple languages. Rebecca Gill, of Web Savvy Marketing, announced its catalog of themes are now translatable and coded for localization and multilingual use.

In her post, Gill explains the thought process behind the move.

If 50% of our product sales are internationally based, then I need to spend time making sure these buyers are being taken care of and clearly I wasn’t. I was expecting this to be handled by Genesis, the WordPress core, or translation plugins.

I didn’t realize how badly I was ignoring the needs of our international customer base. And for that, I am truly sorry.

The work was completed through a collaborated effort between Carrie Dils, Nir Rosenbaum, and Gary Jones. Each theme has been updated to include I18n and RTL (Right to Left) support. Files included in each theme are:

  • POT File – A file with i18n ready strings.
  • en_US.po File – A file with translated strings and English strings.
  • en_US.mo File – A file converted to a format optimized to be read by machines.
  • RTL Style Sheet – Overwrites horizontal positioning attributes of your CSS stylesheet in a separate stylesheet file named rtl.css.

Ever theme is an opportunity to learn techniques, code, and best-practices. I believe the quickest way to make an impact and to raise awareness is for commercial theme companies to support and advertise I18n and RTL as cool features.

The fact these improvements are part of a smart business move doesn’t detract from their importance. The more theme developers and companies who place I18n and RTL near the top of the priority list, the better.

Category: ,
Tags: , , ,
29

29 responses to “I18n and RTL Support Are Top Priorities For Web Savvy Marketing”

  1. Thanks so much for sharing our announcement Jeff!

    We’re going “all in” to support international buyers. We are dedicated to supporting the market outside the US and we plan to take this latest news even further. This will be announced later this week. =)

  2. This is great news! It’s nice to see that other commercial theme providers are following our lead and making more of an effort to be inclusive of people in other countries and with different ability levels.

    I’m looking forward to seeing more announcements like this from other commercial WordPress theme shops in the future. :)

    • I do not really see you leading UK is nice that you were able to influence others to start. . Responsive is internationalized and is translated in over 40 languages.

      There are over 1000 free themes that are translation ready https:// wordpress.org/themes/tag-filter/

    • I love you, Rob, and Compass is amazing, but what makes you think this was following your lead versus WSM responding to customer demand?

  3. I was under the impression that all commercial theme shops sold internationalized themes and have been doing so for years. This is the standard, not a feature.

    • If thats true, theme shops are doing a terrible job of marketing or showcasing those things as being part of a theme. I looked at a few different products from popular theme shops and couldnt tell one way or the other if they support RTL or I18n

      • I didn’t really think of it as something to be marketed. It’s so standard that everyone should be doing it. To me, making a theme translation-ready is no different than a theme showing your blog posts. Maybe I need to start marketing it more on my site.

        • Maybe ‘marketed’ is the wrong word, but ‘mentioned’ certainly – it’s surely always good to give buyers as much info on themes as possible and I think people aren’t always as aware (heck, Jeff wasn’t) as developers tend to assume. Just my 2cent’s worth…

          • It should be standard but the reality is that it is not…
            In many themes supporting RTL is missing or has many flaws…
            For example, if the theme developer wrote CSS rules (mainly positioning rules) as part of the theme files (php or javascript files), it is very limiting (not to say impossible) for the average user to use the theme out of the box for an RTL website…

            I have some peers working on just converting themes and plugins to support RTL…

          • RTL styles can be tricky, especially if you’ve never had to design a real site in RTL. It’s hard for some people to wrap their brain around it if they’ve never had good exposure to an RTL language. There are some automated tools that help, but I find that they only really handle the most basic of things. My more recent themes have RTL styles (most older themes do not), but I’ve had very little feedback from the community on them.

      • You can always just check the theme’s “Theme Tags” as it’s the official way of declaring support for certain features in themes.

        i.e. rtl-language-support, translation-ready, etc

        e.g. Justin’s Stargazer theme has the followings tags:

        custom-background, custom-colors, custom-header, custom-menu, editor-style, featured-images, left sidebar, one-column, post-formats, responsive-layout, right sidebar, rtl-language-support, theme-options, threaded-comments, translation-ready, two columns

        As seen on the .org repo page https://wordpress.org/themes/stargazer

      • While I congratulate this particular theme shop for adapting their themes to make them translatable and accessible to RTL languages, I agree with Justin that this has been the standard for premium themes and also a lot of free themes for quite a while.

        There are a lot of themes on WordPress.org that are not only translation-ready, but that also ship with translations for certain languages. Making these themes more easy to find for users is on the roadmap for the WordPress.org Theme Repository.

        Also on the subject of adding i18n support, the steps outlined in the article are great, but there is much more to the subject than that. What we are talking about is the baseline support, after which all the fine tuning starts to make translating the theme a great experience.

        In terms of marketing themes, if a shop wanted to have a real impact, they would hire professional translators and make their themes available fully translated into the languages they want to target.

  4. Why is the en_US.mo/po included? As far as I know there is no point including it as a the text in the code is in en_US other than the original text being in en_GB.

    • Hi Ulrich,
      The en_US.mo/po files are absolutely not needed.
      Unfortunately, users are keep asking in the support forum to get these files…trying to explain and educate them that is redundant doesn’t always work…

    • Ulrich we didn’t have US.mo/po included to start, but users immediately asked for it as a starting point for transactions. We tried to educate them this was unneeded, but it was futile. So we just created it and knew we would have less issues with ongoing support it the files were there.

      • For the short term, that makes sense. From a long-term perspective, education on how to use the themename.pot file works better. I’ve been down that road and used to include the en_US.po file because that’s what users were asking for. Education always wins in the end though,

      • I am surprised to hear that as I never had that problem but then I used a hosted solution to do translation and invited the translators to the team. You should be able to not include the mo file as it is not human readable.

        I am worried that mentioning in in the article will somehow make it look like it is a best practice when it is not.

  5. I was wondering the same things as Justin and Ulrich.But RTL styles are definitely a bonus. I hope there really aren’t so many commercial (or free) themes without translation-ready support.

    • That’s easier said than done. The only way for that to really happen is:

      1) Hire multiple people on an ongoing basis to translate themes. They’d have to keep them updated, so it’s not a single, one-off job. That can get expensive. It can also lose you money if you’re providing translations that aren’t needed for your user base.

      2) Get the community involved. One of the things I do is teach people how to translate. They, in turn, send the translation files back to me for others to use. WordPress.org will also soon have this capability directly on their site, so there’ll be no need for teaching them how to use Poedit.

      • I’m not saying it’s easy, I’m saying it’s the way it should be. It’s like selling an ikea furniture. It’s fine and cheap. We’re far from an oak table delivered to your place…

        1) Theme companies will come to it when the en_US market will be overloaded. Don’t worry.

        2) We’re building it everyday at WP-translations. Offer translators a nice platform to translate and you as a developper do the rest to get their translations (everything is almost automatic) Let’s see with what WP comes with. Translations are the future of WP, Matt told it…

        • No one claimed that you said it was easy. You did say that it’s the way things should be. I agree with that, assuming a particular theme has reached a certain level of popularity. You got to have the popularity before you can be L10n ready. Either that or have the resources to invest in it. I don’t have any, but I’d love to see some ROI figures from anyone who’s done this out of the gate. Unless you only have a handful of products, most theme shops aren’t going to take that risk. So, you rely on the community, which is a much safer bet.

  7. Built-in support for multi-lingual sites in WordPress core would have even greater impact, I think. While there are steps being taken into that direction with the Babbel plugin, it’s almost impossible to do it properly without changes in the WordPress database schema.

  8. As a Canadian that is really nice to read. I ditched my standard WP for the Canadian English version this year too. I haven’t really noticed a difference but I really love having the option. The feeling of being recognized versus shuffling along and pretending it doesn’t bother me.

  9. Internalization should be standard, so huge props to Gary and Carrie for helping Web Savvy get there. This is the sign of a good community.

    Bradley Vercher wrote a great tutorial on Post Status about automating .pot files and RTL using Grunt if anyone else is interested in standardizing this as part of their workflow: http://www.poststat.us/automating-i18n-wordpress-themes/.

    I also think bundling the localizations is a great experience for non-English users. WP Translations (http://wp-translations.org/) is great for free themes and plugins on wordpress.org, though it’ll be exciting to see where language packs goes in core.

    At DevPress, we’ve partnered with Fx Benard to manage translations. It’s a terrific asset to have someone verifying your i18n work and creating professional translations. The whole process of pushing updated strings, and pulling down translations has also been automated using Grunt- which makes it incredibly easy after it’s set up.

    • I suggested, and Carrie used, grunt-wp-i18n and grunt-cssjanus, and Brady’s excellent article is one I pointed Carrie and Nir to several times.

      I also suggested to Brady, and he implemented, a .pot to .po task within grunt-wp-i18n. There’s a grunt-potomo package than can automate creating the .mo as well.

      WSM have also setup a GlotPress install, so users can contribute back to the 35+ themes they’ve got.

  10. As a spanish developer, internationalization was one of the first things I cared when I started coding plugins and themes for WordPress and I still do. However, it doesn’t end there: RTL is another important feature for hebrew, arabic or persian languages and is many times overlooked or implemented scarcily, sometimes only in admin interface, others only in front end.

    Lately there’s another issue with the introduction of Google Fonts: designers tend to use Google Fonts that don’t have the proper subset for special characters found in some languages. First one that comes to my mind is Czech Republic and its language that requires the latin-ext subset. Many themes include only the latin subset leaving some languages to render special characters using system fonts. Result: uglyness. What’s worse, sometimes themes include a font that doesn’t have the subsets available at all with no fallback to a font that does have them. For example, the Oswald font has latin and latin-ext subsets, but good luck typing something in cyrillic or greek. Theme vendors adding Google Fonts should empower users to add/change fonts with the proper subset, be it a simple filter or a complete user interface, something that allows them to correctly render their language.

You may also like

Newsletter

Subscribe Via Email

Enter your email address to subscribe to this blog and receive notifications of new posts by email.

%d bloggers like this: