Multi-lingual WordPress the Easy Way

Imagine you run WordPress with English as default language, but some posts are in another language. Dutch, maybe? Up until a couple of months ago, you wouldn’t really notice anything about that setup. Google might be slightly confused, but us bloggers aren’t really into SEO anyhow, no? But with the release Safari 5.1, Firefox 16 and especially Internet Explorer 10, support for CSS Hyphenation became (somewhat) widely available and if your theme (WordPress TwentyTwelve or its performance-optimized 2012.FFWD child theme for example) has support for in the CSS, your hyphenation would yield weird results because of the fact that the browser uses the language attribute in the HTML to decide which dictionary to use.
The solution, if your theme is HTML5, is to add the lang-attribute to the article-tag if you have something to check the language with. In my case I just had to copy TwentyTwelve’s content.php and change line 11 into:

<article id="post-<?php the_ID(); ?>" <?php if (in_category('lang:nl')) { ?>lang="nl" <?php } ?><?php post_class(); ?>>

A real simple hack indeed; I check if the article has category “lang:nl” attached to it (which I already used) and set the language-attribute with the correct value if it does. Hyphenation now works for Dutch blogposts and I guess Google will be happier as well that way?

5 tips to tackle the problem with iframes

Iframes have always been frowned upon by web-purists (confession: myself included). But things are never black and white and sometimes iframes can be the best solution for a problem (you could substitute “‘iframes” with “Flash” in the previous 2 sentences, but that’s another discussion). So here are 5 quick tips which might lessen some of the SEO- and usability-problems associated with the use of iframes;

1. Google loves doesn’t hate iframes done right!

Although Google is rather vague about the subject, iframes and SEO do not have to be mutually exclusive. But you will have to make sure it’s your main page that shines in search results, not the iframe-content. The main page (where the iframes are defined) has to be more then a mere placeholder for one or more iframes. Migrate as much information (titles, description and other text) from the iframe-content to your main page, which should describe what goes on in the iframe(s). Use the iframe title-property and insert alternative content between opening and closing iframe-tags. A quick example:

<h2>Calculate your mortgage rate</h2>
<p>Calculating your mortgage rate was never easier; just enter the loan-amount and the duration below!</p>
<iframe src=”http://page.url/iframe-container-page1″ …  title=”Calculate your mortgage rate here”>Your browser does not seem to handle frames properly, but you can calculate your mortgage rate <a href=”http://page.url/iframe-container-page1″>here</a></iframe>

2. Own the stage

Avoid visitors viewing the iframe-content out of the context of the main page (e.g. because they followed a link in search-results). Add javascript to the iframe-content to check if it is accessed stand-alone and redirect to the main page (or explain and provide link to the main page) if that is the case.

if(self.location==top.location) top.location.replace('http://contain.er/page-url/here');

3. Don’t draw blanks

When a visitor clicks a link at the bottom of a long page inside an iframe and the target is a shorter page inside the same iframe, then he/she will see a blank page which is … well not very usable, no? The (hackety-hack) solution; tell the browser to scroll to the top of the iframe each time a new page in it is loaded, by calling the function below (with the iframe id as parameter) when the iframe’s onLoad event fires:

<script>
var firstrun = new Object();
function frameMagic(el) {
if (typeof firstrun[el] === ‘undefined’) { firstrun[el]=true; }
else { document.getElementById(el).scrollIntoView(); }
}
</script>
<iframe id=”iframe” onLoad=”frameMagic(‘iframe’);”>

Update: the above code has been updated heavily, check my frameMagic.js blogpost

4. Your users really do need scrolling=”auto”!

Help your visitors access all iframe content no matter what configuration they’re using: don’t disable the iframe scrollbars! Disabling them will render the iframe partially inaccessible for some of your users, because the size your iframe-content needs depends on things outside your control such as operating system & versions (e.g. font & screen resolution), browser (e.g. css-implementation) and browser configuration (e.g. non-default font-size). Instead define a reasonable iframe-width and height, make the iframe-content width flexible (fluid) and let the browser decide if a vertical scrollbar is needed.
Update: squeezeFrame.js might be a solution to your scrollbar-woos

5. Smart sizing without scrollbars

If you really really really don’t want scrollbars, if you want your iframe to adapt to the size needed by the iframe-content automatically and if you’re not afraid to experiment; there are some nifty javascript-solutions that allow the iframe-content to communicate the required height to the main page. Check out Framemanager (stand-alone, has some issues though) and the JQuery-postmessage iframe-example (which does everything in javascript, which isn’t really ideal from an accessibility point of view).
Conclusion: iframes aren’t necessarily evil (either), but you’ll have to make a small effort to render them somewhat SEO- and user-friendly.

Don’t let Google fool you; tame your Flash!

As I wrote some time ago, Google indeed does index Flash. Great? Well, maybe not: you might even lose valuable site visits this way! This is because Google does not direct users to the page on your site that contains the Flash (as it does for image search results), but to the standalone SWF-file. That means that people doing a normal search in Google, will in some circumstances get high-ranking links straight to your Flash-files instead of to your website and that these prospects will not be drawn into your website’s sales funnel at all. So much for SEO.
Solutions? Well, you could refrain from using Flash all together, there’s too much of that stuff around anyhow. Or you could prohibit googlebot (and others) from indexing swf-files by specifying this in your robots.txt-file.
These are both great remedies, but somehow I think not everyone will agree. So what if we could perform some ActionScript-magic to make a Flash-file force itself in its correct context? Although I am not a (Flash-)developer by any account, I hacked together a small demo (in ActionScript 2) to show how that could be done.

And indeed, if you point your browser to the standalone swf-file, you’ll see you are redirected to this page. How this is accomplished? Quite easily actually;

  1. add a flashvar (e.g. “embedded=true”) to the object/embed tags in the html
  2. check for the value of that flashvar in the first frame of your movie:
    var embedTrue=_root.embedded;
    if (embedTrue=="true") {
         // all normal flashyness goes here
         stop();
    }
    else {
         gotoAndPlay(2);
         stop();
    }
  3. and in frame 2 we do the redirect to the correct url:
    onEnterFrame = function() {
    // weird, stupid test to avoid this from being executed more than once
    if (!runOnce) {
    		var targetUrl = "http://blog.futtta.be/2008/05/06/";
    		geturl(targetUrl);
    		runOnce="1";
    	}
    }
    stop();

I’m sure the code stinks and it indeed is only actionscript2 and not 3, but maybe someone out there can build something usefull out of this general idea. And if not, I’ve had fun learning some (very) basic actionscripting. Now off to “Add/remove software” to get rid of that hog of an IDE! 🙂

Google lust Flash, maar willen we dat wel?

Ge weet het, ik ben geen fan van sites die geheel of grotendeels Flash-gebaseerd zijn (idem voor Flex of MS Silverlight, vanzelfsprekend). Daarvoor geloof ik te sterk in de kracht van gestandardiseerde html, css en javascript en hecht ik te veel belang aan toegankelijkheid, gebruiksvriendelijkheid en ‘searchability’.
Maar met de  ‘searchability’ van Flash zit het blijkbaar dan toch wel snor; Google indexeert blijkbaar ook swf-bestanden (flash dus). De “do no evil”-zoekgoden maken daarvoor gebruik van de Adobe Search Engine SDK die onder andere een applicatie bevat om (html-)strings uit een swf-file te halen. Swf2html lijkt qua functionaliteit gelijkaardig aan swfstrings, onderdeel van het open source swftools.
Dat Google nu ook Flash indexeert, is echter niet altijd ideaal. Probeer bijvoorbeeld een eenvoudige zoekopdracht naar “student woon samen sparen kbc“. Het 3de (!) zoekresultaat is een link naar een “instructie-filmpje” over de KBC Spaarservice. Normaal gezien krijg je die presentatie enkel in de KBC-site te zien, maar dankzij Google wordt het flash-bestand zonder die context ontsloten. Ik durf te wedden dat dat toch niet echt de bedoeling is? En dat een grootbank of webcommunicatie-bureau vermoedelijk toch prefereert dat zoekresultaten naar de site (van de klant) gaan, in plaats van naar het individueel geindexeerde flash-bestand?
Mijn mening over flash blijft dan ook grotendeels onveranderd:

  1. geef de zoveel mogelijk de voorkeur aan ‘plain old html’, zeker voor navigatie
  2. gebruik flash enkel voor pagina-elementen en niet voor hele pagina’s
  3. gebruik flash enkel als die technologie een duidelijke meerwaarde biedt (voor video of iets game-achtigs bv)
  4. zorg voor een beschrijving van de inhoud van de flash in de html (in de div waar de flash wordt geplaatst, of in noscript-tags)
  5. mijn enige nieuwe advies: voorkom dat swf-files worden geïndexeerd (dmv robots.txt) of voeg code toe aan je flash, zodat die enkel in de juiste context getoond wordt (ik veronderstel toch dat dat kan, zoals ook een html-pagina met wat javascript in de juiste iframe-context kan gedwongen worden?).

Om af te sluiten nog een bijzonder leerrijk (flash-)filmpje misschiens?