Experience – Stéphane Caron – No Margin For Errors http://www.no-margin-for-errors.com Thu, 07 May 2015 00:40:40 +0000 en-US hourly 1 https://wordpress.org/?v=4.9.8 JavaScript string localization done right http://www.no-margin-for-errors.com/blog/2010/12/01/javascript-string-localization-done-right/ http://www.no-margin-for-errors.com/blog/2010/12/01/javascript-string-localization-done-right/#comments Thu, 02 Dec 2010 02:38:41 +0000 http://www.no-margin-for-errors.com/?p=758

Related Posts

If what you were reading interested you, those might too! Check them out! ]]>
I live and work in a bilingual environment and most of the things I work on needs to be localized.

While it’s easy to do localization on the server side, it’s not so easy on the client side. There are several solutions available online, but most of the times they are either over-complicated or contains all the languages strings in one file, none of them really cut it for me.

Since I’m obsessed with optimization and performance in the things I develop, I tried to come up with the best solution in that sense. Please note that this method works well if you have a back-end to feed you the localized strings, if you have to do localization that usually means you have some kind of framework running behind the front-end.

So basically, I always only include one localized JavaScript file in my projects, let’s call it “localization.php” and here’s a sample:

<?php header("Content-type: text/javascript"); ?>

var localized_errors = {
	connect : "<?php echo _('Oops! We couldn\'t connect you to the server') ?>",
	loging : "<?php echo _('Oops! We couldn\'t log you onto the server') ?>"

var localized_label = {
	previous : "<?php echo _('Previous') ?>",
	next : "<?php echo _('Next') ?>"

Now you might have noticed that it’s a PHP file that contains JavaScript, the key here is to make sure that this PHP file is served as JavaScript using the correct header.

Note the the variable scope is global so these are accessible from any javascript file elsewhere in my projet.

Now if you looked closely, you’ll see the I reference the gettext PHP function. If you’ve never heard of it, I highly suggest you read into it, if you’re already using something similar, you should see where I’m going 🙂

The gettext function basically takes a label for parameter and then go look for that label in the proper translation table. So all of the hard work is done on the server side, none of it really happen in the JavaScript.

Here’s what the browser actually see:

var localized_errors = {
	connect : "Oops! We couldn't connect you to the server",
	loging : "Oops! We couldn't log you onto the server"

var localized_label = {
	previous : "Previous",
	next : "Next"

See that? It’s a nice JavaScript file containing two JSON objects, nothing else. It cannot get easier than this.

Now to reference the labels from anywhere in you application you only need to reference them like so:


Now let me explain why it’s better to use that method.

The usual localization solutions for JavaScript are done using a JSON object containing all the localized labels, that means that not only do you have to maintain your usual localization tables, but you also need to maintain it for your front-end and experience tells me that you’re just adding another potential breaking point.

Also, if you use the “traditional” method and you have 3 languages, your localized JavaScript is three times bigger as it should be, bigger is not alway better 😉

So that’s it, let me know what you think of if you have any other better method.

http://www.no-margin-for-errors.com/blog/2010/12/01/javascript-string-localization-done-right/feed/ 17
CSS tip: Float an image without text wrapping under it. http://www.no-margin-for-errors.com/blog/2009/12/10/css-tip-float-an-image-without-text-wrapping-under-it/ http://www.no-margin-for-errors.com/blog/2009/12/10/css-tip-float-an-image-without-text-wrapping-under-it/#comments Thu, 10 Dec 2009 21:47:56 +0000 http://www.no-margin-for-errors.com/?p=262

Related Posts

If what you were reading interested you, those might too! Check them out! ]]>
I thought I’d share this little CSS tip that can be useful to some of you.

Let’s say you have this content that contains a thumbnail, you want to float the thumbnail but don’t want the text to wrap under it like below.


Instead you want the thumbnail to float and the text beside it, in it’s own column, like below.


Well that’s fairly easy to do, your markup should look something like this:

<div class="content">
    <img src="thumbnail.jpg" width="50" height="50" alt="Thumb!" />
    <p>Lorem ipsum dolor sit amet, consectetur adipiscing elit. Duis ligula arcu, luctus nec elementum quis, condimentum a lectus. Suspendisse potenti. Proin neque diam, dictum ac elementum scelerisque, aliquet eget diam....</p>

Now what you actually do, is that instead of floating the thumbnail, you “position:absolute” it inside the content and add padding to the content so the text displays beside the thumbnail.

You CSS should look something like that:

.content {
	padding: 0 0 0 75px; /* 75px being the width of the thumbnail + how much space you want to put between it and your text */
	position: relative; /* So the thumbnail is relative to this */

	.content img {
		left: 0;
		position: absolute;
		top: 0;

This should produce the result below. What actually happen is that the thumbnail which is absolutely positioned don’t take the padding of it’s container into account. That’s why it can be positioned over the padding.

Working demo

Check out my working demo to see it in a real world example.

Bottom line

So by using this technique you’re always sure your text will never wrap under your thumbnail, that’s one less thing to worry about!

http://www.no-margin-for-errors.com/blog/2009/12/10/css-tip-float-an-image-without-text-wrapping-under-it/feed/ 36
The real world costs of an heavy website http://www.no-margin-for-errors.com/blog/2009/11/30/the-real-world-costs-of-an-heavy-website/ http://www.no-margin-for-errors.com/blog/2009/11/30/the-real-world-costs-of-an-heavy-website/#comments Mon, 30 Nov 2009 23:46:36 +0000 http://www.no-margin-for-errors.com/?p=185

Related Posts

No related posts. ]]>
You often read about why you should keep your web pages as light as possible to be quick to load. While all of this is true, there’s also a very important reason why you should keep your web pages as light as possible and that’s regarding bandwidth costs.

We often take for granted unlimited bandwidth and that all of this is free, but it’s not and a change as small as an additional image in your page can have a big impact. at the end of your month.

It’s true that the bandwidth cost is quickly coming down, but when building websites for your clients (or yourself) you should always try to keep your pages as light as possible.

Disclaimer: I didn’t (obviously) take caching into consideration.

What about numbers

To demonstrate what I mean, I’ll use my current hosting as an example. I currently have 250 gigs of bandwidth a month and I get about 100k pageviews a month. With an average pagesize of 175k  that mean I approximately use 16gig out of my 250 available. Nothing to be scared of, look like I won’t need to upgrade anytime soon. Also note that exclude all my projects download, which cost me another 15 gigs a month.


So as you can see, I could get a lot more views and my page could be a lot heavier and this wouldn’t be a problem. But still, add 75kb to my average page size and this suck around 7 gigs of bandwidth which at some point might save me from upgrading my servers.

It’ll take me a long time until I need to upgrade my hosting. I’d need around 1.5 million views to break the 250 gigs a month. But then again, my website is fairly small and if I ever reach that number I’ll be more than happy.

What about the big boys?

You know the kind of website where users click around like crazy, the kind of websites that get around 100k views a day (3millions/month) and when you start playing with those kind of numbers you really gotta start considering optimizing your page size not for the end user but for the person paying the bills.


As you can see a change as small as 25k can make a pretty big difference in the end. 70+ gigs is not a small number and that can mean a service upgrade if the bandwidth is not available.

What about Google?

Just for fun now! According to alexa.com, Google gets about 620 millions visits a day. That’s quite a lot of hits. I built the graph using their homepage size.


As you can see a tiny kilobyte can cost them 600 gigs of bandwidth, for a single day. I often hear people complaining about how their homepage is so plain. I think these numbers alone can explain why Google don’t use much images in their design.

Bottom line

When building a website, might it be for me, friends or clients, I always try to keep that in mind. Big players made some moves recently to cut down on bandwidth. You might remember MySpace disabling the auto play on their music player, not only did they save big on wasted bandwidth they also saved us from going crazy trying to find where that frigging music was coming from. Vimeo also did something similar by disabling the auto play on their video player.

Remember that you can nearly always save some kilobytes here and there and they are easier to find that you might think.

http://www.no-margin-for-errors.com/blog/2009/11/30/the-real-world-costs-of-an-heavy-website/feed/ 24
This tweet got me thinking. http://www.no-margin-for-errors.com/blog/2009/11/16/this-tweet-got-me-thinking/ http://www.no-margin-for-errors.com/blog/2009/11/16/this-tweet-got-me-thinking/#comments Mon, 16 Nov 2009 20:48:29 +0000 http://www.no-margin-for-errors.com/?p=48

Related Posts

No related posts. ]]>
Today James Padolsey posted something quite interesting on his Twitter account that got me thinking:

Wondering what the client-side would be like if there were multiple languages, not just JavaScript…

Not only it got me thinking, but it also scared me. The way it works now is, you download a browser, you deal with what technologies comes bundled with it. It may be CSS3, ECMAScript 5, HTML5, every browser support the standards they want to a certain extent. Some does it well, some suck at it (don’t think I need to drop names!).

If you take a look at the “back-end” side. Depending on the technologies you want to use, you just need to install the proper libraries on your server in order to feed it properly to the web browser. YOU decided what you feed and how you feed it. Every time a new programming language emerge, you can start using it and be sure that everyone coming to your website will be able to see it as long as your webserver is setup properly.

And that’s what so “complicated” with front-end. You just don’t know who will come on your website and what they’ll be using. You totally depend on browser penetration.

Why I got scared?

Remember netscape 4, the <layer> tag, IE6 just to name a few?

In the current state of things I don’t think it’d be a good thing to add another language.

In the past, and even today, we’ve often been held back by older browser. Not because they suck, I think they were perfectly fine for their time, but because people were slow to upgrade. It can be the IT department that don’t want to go through the pain of updating all the employees computers or the users that are not aware enough, the end result is still the same, we need to support them until they die.

However, I think that sometime soon browser vendors AND users will be saavy enough to understand it is important to keep their browser up-to-date. Then we’d be able to take advantage of a new emerging client-side programming language since the adoption would be fast and widespread enough for us to use it.

But until then…I’ll be scared

What’s your view on the subject?

http://www.no-margin-for-errors.com/blog/2009/11/16/this-tweet-got-me-thinking/feed/ 8