7 Steps to Translating a Website Language

Tools for the Job

Translating a website is not straightforward and can be time consuming. However, there are tools that you can use to help with the process. Cascading Style Sheets (CSS), for example, let you keep the content separate from the design. In using CSS, you can change the content for your chosen foreign language and not have to start each page from scratch. The direction of your text can also be switched, meaning that you will save a lot of time if you are working into languages such as Urdu or Arabic.

Another useful tool is Unicode UTF-8; it can work with over eighty written languages and their various distinctive characters. Non-Latin characters found in the Nordic languages like Swedish and Finnish are covered, as are non-Latin scripts such as Arabic.


You’ll have to be culturally sensitive with regard to any images on your website. This is because what is considered amusing in some countries can be considered offensive in others. In Arabic, images, as with text, are interpreted right-to-left. So, if you are a washing powder company and you have two images: the first on the left being dirty clothes going into a washing machine and the second on the right being the clothes coming out clean, they will be interpreted the wrong way around.

Choosing the Right Colors

You’ll need to consider what colors will be best to use for your foreign website; everything from logos to text will need a lot of thought. The reason is that colors have different meanings in different countries. Xerox has an International Color Guide on their website, which is worth checking out in researching what colors to use for different countries. White, for example, is associated with mourning in China, while in the United States it is associated with purity.


Words in Finnish tend to be a lot longer than their English counterpart. For example, the word for ‘towel’ in Finnish is ‘pyyheliina’, which is more than double the number of characters. So, if you are making a website for the Finnish market, you’ll need to think about how much more space will be needed to incorporate the translation. For all foreign languages, you’ll need to consider their effect on headings, main text and text within images — all of which can result in changes to the layout.

Use the Most Optimal Domain

You’ll want your website to be perceived as local; a good way to add to its localization is by having your chosen foreign market’s top level domain. For example, if you are an IT consultancy based in England, having a version of your website translated into Japanese with the domain http://www.mywebsite.co.uk will not be as credible as http://www.mywebsite.jp. There is also the option of creating a sub-domain, for example, http://www.mywebsite.com/jp. This will also boost your Search Engine Optimization (SEO) as search engine algorithms take location of the search into account, and local results are more likely to have a countries top level domain and will been seen as locally relevant.

Think about Keywords

You’ll need to be aware that the keywords from your home website might not translate directly into a foreign language, and their meaning might not be the same. Maximise your foreign website’s SEO by ensuring that your keywords mean the same thing after translation and that they’re suitable for that foreign market. For example, if you are a company that sells baby products and ‘baby stroller’ is your keyword, this can translate directly to ‘coche’ in Latin American Spanish without any initial problems. However, ‘coche’ in Spain is the word for a ‘car’ and the direct translation would instantly fail.

Localizing your Content

Following on from the keyword language problem, you’ll need to be aware that a language is not exactly the same the world over. For example, French spoken in France is not exactly the same as it is in Switzerland, Canada or Haiti. Dialectic pitfalls can be avoided with the right research and proper translation. A proper translation however, will not be the one that is found free online. Don’t rely on machine translation software as they only give a basic direct translation; the Spanish example in the keyword point highlights the problem with that. The same goes for dictionaries. The most accurate way of translating and best option in avoiding the dialectical pitfalls is to use a professional translator, who is a native speaker, and lives in the country your website is being created for.


Every PHP Developer Should

PHP development is hot right now, but there are also lots of people in PHP development. If you want to make it as an independent PHP developer you have got to know more than just PHP.

JavaScript, HTML, and CSS

It isn’t enough these days to just know how to write PHP code. If you want to start a PHP business, you’ve also got to know how to properly code websites using HTML and CSS as well. Chances are likely that in your projects you’ll have to fix mistakes that designers make, so you’ll need to know how to do that – and how to do it well. If you don’t know these other languages along with PHP, you’re going to be outbid for many jobs by contractors who are much more well-versed in web development than you are.

Knowing What You Don’t Know

As important as it is to make sure you can do as much as possible towards developing websites, it’s also important to know what you don’t know. This is a skill some new PHP developers seem to forget when starting out in a market where it’s hard to find entry-level PHP development jobs. You’ve got to understand how to read proposal requests and how to put in bids on jobs that you can do competently. Otherwise, you’ll end up over committing yourself and damaging your reputation in the long run.

Business Communication

As a freelance or contract PHP developer, you’ll be the one communicating with all your clients. Learn how to use a phone to ensure that email messages are received, and learn how to communicate like a professional. Lots of techie types have trouble with basic business communication (which is probably why they choose to work at home by themselves in the first place). If this is you, go take a class on business communication, or talk to a professional about how you can improve these skills.

Business Finance

Again, as a one-man (or woman) business, you’ll be managing your own business’ finances. You don’t necessarily have to learn how to do your own taxes, which can be tricky for independent contractors, but you should certainly learn how to manage the day-to-day finances of your business. This includes learning how to set a fair rate for yourself based on the market rates and the taxes that you’ll have to pay out of your business income.

Project Management

As an independent contractor, you won’t have anyone over your shoulder begging you to get a project done by a certain deadline. You’ll also most likely be juggling multiple projects and multiple clients at any given time, so make sure you know how to manage your own time, write proposals, and manage the scope of your projects so that you can commit and deliver and build a great reputation for yourself.


Networking with other freelance PHP designers – and web development freelancers in other niches – can help you find more jobs and get referrals. Use Twitter, Facebook, and LinkedIn to network with other developers, as well as with clients you work for or have worked for in the past. Networking skills can be invaluable in a competitive job market.

Freelancing Tips to Survive Disasters

I recently heard a tragic story of a freelancer who lost her business seemingly overnight because she’d been very ill for more than a month. It’s hard enough to be diagnosed with something fairly major health-wise, let alone have 95% of your business disappear in just over a month.

Here are few tips that may just help you survive a disaster as a Freelancer.

Have savings

Keep some of your profits in a separate bank account, in case you suddenly can’t work. Ideally, it’s enough to pay all of your expenses for at least a month.

Have flexibility

Keep a flexible schedule that allows you to burst through work when you’re inspired, and enough slack that you could take a few days off to recover without most clients noticing.

Have income options

Always keep your options open – keep an eye on what the market is doing, so if all else fails, you can at least take a job fairly quickly. Never, ever burn bridges with clients or competitors – one day, they could be your prospective employer.

Have insurance

Health insurance is an obvious one, however many countries also have options for unemployment or loss of income insurance. The premiums may be a small price to pay if you need to stop work for an extended period.

Have a positive attitude

Your health is affected by your attitude more than you believe. Living a healthy life isn’t about working 60 hour weeks and being constantly stressed. Take important time out to enjoy life, and work on keeping a positive attitude.

HTML DocTypes

Why DocTypes is important

When you use an HTML editor such as Dreamweaver to create an HTML document, you’ll likely see a special line at the very top of your file’s source code, before the opening <html> tag. For example: <!DOCTYPE html PUBLIC “-//W3C//DTD XHTML 1.0 Transitional//EN” “http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd”&gt;

This line is called a Document Type Definition, or DocType for short. It tells web browsers what kind of HTML your page is using. The truth is that all HTML is not equal. There are many different flavors and versions of HTML. Undoubtedly, you’ve heard buzz about HTML5. In reality, this is just the latest revision to the standards upon which HTML is built. Before HTML5, there was HTML 4.0, HTML 3.2, etc. In the same way, there is XHTML, a flavor of HTML that requires stricter formatting and adheres to an XML-like structure. So, the DocType simply tells browsers exactly what version and flavor of HTML you’re using in your page.

Adding a DocType to your pages

The DocType definition line should be the very first line in your HTML page. Even though there are quite a few DocTypes you can choose from, the good news is that there are usually only a couple you need to worry about.

One of the most flexible and common ones is XHTML 1.0 Transitional: <!DOCTYPE html PUBLIC “-//W3C//DTD XHTML 1.0 Transitional//EN” “http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd”&gt;

If you’re creating a frameset page, you’ll want to use this definition:
<!DOCTYPE html PUBLIC “-//W3C//DTD XHTML 1.0 Frameset//EN” “http://www.w3.org/TR/xhtml1/DTD/xhtml1-frameset.dtd”&gt; Because these DocTypes are XHTML based, they require stricter formatting (e.g. closing all tags).

From a best-practices standpoint it’s good to close tags to avoid confusion. However, if you’re working with older HTML and don’t want to update, a slightly more flexible doctype is the HTML4 Transitional DocType. It doesn’t require closing certain tags such as <img> or <p> or <br>:
<!DOCTYPE HTML PUBLIC “-//W3C//DTD HTML 4.01 Transitional//EN” “http://www.w3.org/TR/html4/loose.dtd”&gt;

If you want to use HTML5 features (like the <video> or <audio> tag), you’ll need to use an HTML5 DocType – which is actually simpler than any of its predecessors. In fact, it is generally best to use an HTML5 DocType at this point for all new pages you create, since it represents the latest version of the HTML specification. This one is so simple, you can easily memorize it: <!DOCTYPE html>

Why is it important?

Just as the HTML specification has evolved over the last 20+ years, so have browsers. The Wild West days of the 90s Internet meant that every browser essentially “did its own thing” and often disregarded the official standards. Fortunately, over the last decade or so, browsers have become mostly standards-compliant– that is, they closely adhere to the the standards set forth by the World Wide Web Consortium ( W3C, an international standards organization that devises the official standards for the HTML language).

The unfortunately reality, though, is that there are still crummy web pages on the web from the 90s, and these crummy pages were designed to run properly only on the crummy web browsers of their day. To maintain backward compatibility for these pages, browsers essentially started including at least two rendering engines – the old “quirky” engine for rendering ancient pages that don’t adhere to standards, and the new standards-compliant engine for rendering newer pages that do adhere to standards and want to take advantage of new functionality.

The DocType tells the browser whether it should render the page in “Quirks mode” or Standards-Compliant mode. You can now see why specifying a DocType for your pages is so important. If you don’t specify one, browsers will go retro when rendering your beautifully-crafted pages… and you’ll end up with all of the wonderful bugs and display problems of a 10- or 15-year-old browser. That one little line can save you a lot of time and headaches. Fortunately, making sure you have one isn’t very difficult.