How to make your website multilingual. Case study part 1: Select a method
Marcin Tabaka and Piotr Zieliński
January 9, 2020
Planning to add more language versions to your website? This is a step-by-step guide on how to do that. A real project we completed partially pro bono as a Christmas gift for a charity organization will serve as an example.
Two language versions of Onkobieg registration website – English version is still in the testing phase.
This mini-series of articles outlines:
How to select the appropriate method of adding support for multiple languages to your website (below).
Step 1. Select the appropriate multi-language solution for your website
Before you start translating, take a moment to consider which method is best for your website.
We had 3 implementation models to choose from when taking on the Onkobieg (Oncorun) registration website CMS. Learn about the advantages and drawbacks of different solutions.
A. Copying the entire website
Procedure:
Copy the source code and the database. Launch the website under a different address and replace all text content with translations.
Advantages:
Simplicity. This solution is the simplest and quickest to implement.
No changes to the database. There is no need to modify the database – simply make a copy of it.
Altering text content in templates (e.g. footer content) is easy. Simply edit the content – no tools are necessary to handle multilingualism in templates.
Diverse content. Different language versions of the same site can differ from one another – some may have more content, some less.
Drawbacks:
Separate databases. Different language versions cannot share data without additional synchronization. Example: user accounts. If a user creates an account using the Polish language version, they will have to make another account if they want to use the English version.
No linking between subpages. Switching between different language versions of a single resource is more difficult. Example: returning to the main page from a subpage. If a user is browsing the Polish version of a subpage, they will be redirected to the home page after switching to the English version instead of staying on the same subpage.
Higher maintenance costs. Changes (to templates, database alterations, new functions) must be implemented separately for every language version.
B. Translation of individual database content
Procedure:
Add new language fields to the database (e.g. article title EN, article description EN). Translate the website by filling out the fields with content in the target language.
Advantages:
Little tampering with system architecture. Language switching is possible by adding a single global parameter to the website URL.
Easy switching between language versions. Every resource in the system exists in all language versions. This means that resource ID is the only thing required to retrieve data in a different language.
Single database. All language versions use the same database.
Low maintenance costs. Every change to a template affects every language version.
Drawbacks:
Identical website content. Language versions must be identical. This means that every resource must be translated into every language.
Altering text in templates is difficult. Text content needs to be placed in separate language files.
Limited scalability. Every new language version requires additional fields to be added for every resource in the administrator panel.
C. Single system for multiple website versions
Procedure:
Create separate language versions of a website within a single system. Link every website to a separate domain, subdomain or folder in the primary domain. Assign individual resources (e.g. subpages or blog articles) to the appropriate language version of the website.
Advantages:
Scalability. Once implemented it significantly simplifies adding new language versions.
Diverse content. Different language versions of the same site can differ from one another – some may have more content, some less. No need to translate all content (e.g. archived blog articles).
Easy switching between language versions. The database is shared. All language versions of every subpage have a common identifier.
Single database. All language versions use the same database.
Low maintenance costs. Every change to a template affects every language version.
Drawbacks:
Significant tampering with system architecture. Every module needs to be altered so that its resources are assigned to the appropriate site.
Altering text in templates is difficult. Text content needs to be placed in separate language files.
Our choice
Onkobieg is a registration website for a running event. It enables users to create accounts, make payments online and generate start cards for printing. The nature of the website makes it impossible to launch an English version using a separate database (method A.).
Ultimately, we opted for solution C. – though it is more labor-intensive, it also scales better and does not require all website content, such as archived posts, to be translated.
We also needed a tool for translating content embedded in the source code, such as content in the templates, notifications and error messages. As Onkobieg uses Laravel as its framework, we used its built-in translation package.
As a result of the changes, a growing number of Onkobieg (Oncorun) attendees from outside Poland will be able to register for the race in English. Thanks to our solution, the organizer will easily add new language versions at any time.
“A partner this involved is difficult to find. The majority of the translation was done free of charge as a Christmas present for the Association. We are very grateful for that!”
