Back to search

Build a localized app with Laravel - Part 1: Internationalization and accessibility

  • Fisayo Afolayan
August 6th, 2018
Things that you need to install the software. 1. Git, 2. PHP, 3. Composer, 4. Laravel CLI

This is a simple implementation of how to build an International Application using Laravel. It has basic authentication features set up. In this tutorial, we are going to see how to build an international application with support for multiple languages.

When your application has users from different countries with different languages, having different content tailored to each region is a good step at improving the overall user experience of your application. You would have to worry about content, images, illustrations all appearing in the local language. You also need to consider multiple accessibility options to ensure every user can access your application and extract value from it.

Introduction

When thinking about internationalization, it is easy for things like sorting out domain names, web server configuration, URL structure for website content, page layout and multiple translations for content and multiple currency support to be your priority. In many cases, they are the easy things to solve. What gets neglected the most are accessibility specifications and concerns, which are the little details that create a good user experience.

BCP-47 provides a lot of specifications around multiple language support in our applications to improve user experience and guarantee high accessibility. Going through the document will help you understand how best to serve your content to users even when you have content in multiple languages on the same page. At the surface level, it is easy to ignore this, but we will look at why it is important to cater for these little things as we proceed with this guide.

Another thing to note when designing an international application is to clearly differentiate if you are making a multilingual application, a multi-regional application or both. In each of these situations, what you have to consider becomes a lot different.

A multi-regional website

A multi-regional website explicitly targets users in various regions, generally different countries. An example is a website serving audience from Nigeria, Ghana and South Africa. They are all English speaking countries with a few distinctions like currency being the most common.

Multi-regional websites try to create localized experiences for users. Users tend to feel a lot more comfortable with websites localized for them as webmasters put their cultural disposition into consideration and use items or phrases that are more relatable.

A multilingual website

A website is multilingual if the content on the website exists in different languages. If you are making a website for a country like Canada or Switzerland, it should be a multilingual website because you will have to cater for people in the same region who speak different languages. The focus should be on a language of the content rather than on layout, or type of content.

Both multilingual and multi-regional

For example, if you have to make a website to be used in the US and Canada, you may be concerned with making a multi-regional application that is also multilingual. When a Canadian resident is accessing the website, you may wish to serve the website in either English or French to the users. For a US resident, you may choose to serve a totally different content to the user.

If you properly localize your website, when you use the $ on items, a Canadian will understand it to be Canadian Dollars while an American user will see it as USD. It will create convenience and improve the user experience, as they would not have to worry about converting from CAD to USD and vice versa.

A few accessibility issues you should address

Using proper language codes

The first and maybe the most important thing you need to do for your international application is to specify the language the content you are serving exists in. This is important for your users who may use assistive devices to access your website.

Not specifying a language would make the assistive device use the default language of the browser when interacting with your content. While it is fun hearing the browser read English words in Spanish, your users will not find that much fun at all.

Also, if you set the language of the entire page, you can take advantage of styles targeting specific languages on the page. We will learn more about this later in this series.

To see the language subtag registry containing standard iso-codes for different languages, click here.

Selecting a primary language

Setting a primary language on the page is required when you have parts of your page in one or more other languages. An example is a situation where you have a section on your page that explains what an image means with French and German translations side by side.

Your primary language is the language most of your content exists in. In the case of the example, if you have everything in English and then have those translations in French and German explaining an image, your primary language is English.

You should specify it at the start of your page like:

    <html lang="en">

Including another language different from the primary language

The majority of web pages use one language at a time for serving their content. There are cases where you may need to have the content on the page in more than one language. Take the example used in “2. Selecting a primary language”, a good approach would be to mark off the section of your page in French so that any screen reader or assistive device used in surfing your website can interact with the text appropriately.

If you have your text in a div tag, you can mark off the languages of the text like this:

    <div lang="fr">
      Salut! Ça va?
    </div>

    <div lang="de">
      Hallo! Wie gehts?
    </div>

Also, if you have a user who uses a translator, this will make translating each section as accurate as possible, because the translator can pick the language to use for each section.

NOTE: Google does not use language tags on your page to determine the language of the page. It tries to figure out the language out by interacting with the content. This, according to Google, is to enable them to serve better results to searchers based on their location and/or preferences.

For a multilingual website, each webpage may have alternate versions in different languages. You may include links on each page to indicate where it exists in different languages. This is good so users who find your website can easily find versions in a language they are most conversant with.

When including the link, you should also specify that the link is in a different language like this:

    <a href="" hreflang="fr">French</a>

If you want the text of the link to be in the language of the page it targets, you can do:

    <a href="" lang="fr" hreflang="fr">Francais</a>

NOTE: Do not use hreflang on any other tag that is not a link.

Font sizes

When you have multiple language versions of your content, it is important to also consider changing the font sizes as languages change. For languages like English, French, German, they are very similar so you can use the same design and font sizes for them and they would come out fine.

Languages like Chinese, Japanese and Arabic might be difficult to read at font sizes that are suitable for English or related languages. You need to adjust the font sizes for these languages to make them legible to their readers.

You can use the CSS :lang() selector to target these languages and style appropriately. You can do this like:

    :lang(languagecode) {
        css declarations;
    }

To be more specific to a particular element, say p element, you can do:

    p:lang(languagecode) {
        css declarations;
    }

Language direction

You may not encounter language direction accessibility issues except when making your website in a right to left language like Arabic. In this situation, you need to set the alignment of the content on your page to be right justified.

Character encoding

Character encoding helps computers understand your information. If you use the wrong encoding your pages may not be found by some search engines or the browser may not interpret them correctly.

The most widely used character encoding is Unicode. It contains characters for most languages and scripts in the world. It has wide support across multiple operating systems and platform. This means setting the encoding on your page to Unicode will make it accessible almost everywhere.

To set the character encoding on your page, use:

    <meta charset="UTF-8">

Layout of the page

You may use the same layout structure for your all language versions of a page regardless of which language it is in. If this is the case, you should know that words in English may appear longer in other languages and vice versa. If you serve the same page in French, it may look messy with words falling out of alignment. In Japanese, you may have too much white space everywhere.

You should consider this when making your page translations. You should try to use phrases or words with similar length across multiple language versions of your page, to maintain its neat design. You may also consider taking items out of the page as you change the language of the page.

Amazon English

Amazon French

If you take a careful look at the two images, you would see a lot of differences in text size and how items align. You would also notice the header of the page looks a little cramped when viewing the French version. While the site is still very usable, you would notice how issues would arise if Amazon arranged their header a little differently.

URL structure

The structure of your URLs are very important for several reasons. Here are a few of them:

  • Users can easily tell which version of your site they a viewing (or language).
  • Users can easily switch to a version of your site they are more comfortable with.
  • Search engines can show the localized version of your site to users looking for your content.

If you read Working with multi-regional websites on Google’s Webmaster Central Blog, you will see how Google uses the structure of your URL to determine what to return to the search page. Your focus is not to optimize your website URL for search engines, but to make your website easily accessible to users. You want people in Canada looking for your website to find the Canadian version of your website as opposed to not finding it at all. You also want them to know the page they are about to open is made for Canada and will suit their needs.

Let us look at the common URL patterns you can use:

  • The subdomain - en.example.com This is a great choice. It keeps your URL clean and makes it easy for users to know where they are. It will also be a great choice if you want to use analytics or separate users who visit your website as you can achieve it easily with subdomains.

However, it can make users not feel so sure of where they on your website and can get confused. Also, it can increase the cost of building and managing as you have to treat each subdomain like a unique domain and cater to its security needs.

  • The sub directory - example.com/en This is my preferred pick. It is the least expensive to set up, the easiest to manage and the easiest for users to interact with. If you use the same URL across the different language versions, your users can just change the language or region and have the same content for that region or language.

For example, example.com/en/great-tourist-locations can be the main page and

example.com/fr/great-tourist-locations would be the French version. Users can just change language codes and get alternative versions once they see a pattern.

Serving content based on user browser language preference

When a browser makes a request to the server, it also sends along with the request, the language it may like to accept. From the server, you can read the HTTP request to know what language to return to the user regardless of the URL the user is accessing from.

The browser sends language information in a header called HTTP_ACCEPT_LANGUAGE. The data will be in this form:

    es,en-us;q=0.3,de;q=0.1. 

This means the user can accept Spanish, English (US) and German. The q=* is part of the HTTP spec and must be a number between 0 and 1. If it is not specified, it is assumed to be 1. The number shows the degree of preference the browser has for the language the content should be returned in.

From that, we can read:

  • Spanish is the preferred language.
  • In the absence of Spanish, send English content.
  • In the absence of English, send German content.

By addressing these issues, you will improve the user experience of your website and make it accessible to everyone, especially:

  • People who use screen readers or other technologies that convert text into synthetic speech.
  • People who find it difficult to read written material with fluency and accuracy, such as recognizing characters and alphabets or decoding words.
  • People with certain cognitive, language and learning disabilities who use text-to-speech software.
  • People who rely on captions for synchronized media.

Conclusion

Internationalization is great when you want to serve a larger audience that cuts across multiple countries and regions. Considering important issues that may arise and addressing them will ensure that anyone using your application will extract value from it.

You want to ensure your users have a great experience when using your application. If they do not, then the time and resources you deploy to making an international application go to waste. To understand more about content authoring and markup of your webpage for internationalization, read this w3c guide.

In the part - 2 of this guide, we are going to build the backend of our international application. We will build a simple tour guide booking platform targeted at users from France, Germany and English speaking countries coming to the US for a vacation.

  • no pusher tech

© 2018 Pusher Ltd. All rights reserved.

Pusher Limited is a company registered in England and Wales (No. 07489873) whose registered office is at 28 Scrutton Street, London EC2A 4RP.