Servage Magazine

Multilingualism is something you should plan before starting to work on a project. If you start with a single language, it may be difficult to add multiple languages at later stages of development if everything is hardcoded in the source code. If you have the slightest feeling that your application will support multiple languages at some point, it’s best to make it multilingual from the beginning. Here’s how you can do that on both the front and back end.

Localization on the Back End

Let’s start with the back end. Regardless of which framework you use, the process of setting up and using language files doesn’t differ significantly. A good practice is to store the language files in a resource directory and use separate directories for all languages. For example, in a Laravel project, you can store the language files under resources/lang/<language>, for example resources/lang/en. You can split the language files by categories, for example by having one file where you store all messages related to orders and another for support tickets.

In the case of a Laravel application, the language files are PHP files that return an array: return [‘order_now’ => ‘Order Now’, ...]. To support multiple languages, duplicate the file under a new directory and change the values but keep the keys of the array unchanged.

When you want to return a localized string of text, load the appropriate language file and read the value of the key you want to return. Most frameworks can read from language files with helper functions, which is usually the best way to do it. If your framework doesn’t offer such a feature, you can also read the contents of the file and store it in a variable: $language = include(‘/path/to/file.php’) and access the strings using $language[‘order_now’].

Using the Front End for Translation

It is also possible to handle the translation process on the front end. The process of doing so is mostly the same as for the back end: you have at least one language file and you know which language to use. You can then load the correct file and read the desired string of text from that file.

But since the back end doesn’t translate the strings, in what format should they be sent to the front end? A common solution is to use a machine-readable format, such as “order_now”, or “submit_support_ticket” since they are easy to map with a language file on the front end. Another way is to use a default language, such as English, and see if a translation for that string is found. If not, the text falls back to the original English version. In general, the first choice is preferred.