Skip to content

Language switcher for all

Back in December and January, I asked about making the language switcher available in single-language mode and separating the language for the interface from that of the content. The idea has been talked about previously but has not resulted in a patch previously.

Background

In the default single language mode, CiviCRM uses English (US) for the interface. The Default Language for the installation can be set on the Localization Settings page and can be any language for which the translation files have been installed. The setting here affects all users. Content like an event's title is entered in whatever language is desired and is not necessarily the same as the interface language.

[This writeup uses event title as an example of a localizable field, but the details apply to all other localizable fields.]

When CiviCRM is configured for Multiple Languages on the Localization settings page, there are several changes to Civi's functionality:

  • the Localization settings page adds two new settings:
    • Available Languages: a set of checkboxes for each of the Added languages
    • Add Language: a dropdown with all the Installed languages
  • the database schema is changed. Each field that is marked as localizable is renamed to have a suffix of the existing single language. So assuming the default of 'en_US', table columns such as civicrm_event.title are renamed to civicrm.event.title_en_US
  • if more than one language is Available, a 'Language Switcher' block is enabled that allows the user to select which language is shown. In contrast to the Default Language setting, this only affects the language for the user making the selection, not for all users.
  • the Default Language dropdown is restricted to the Added languages instead of the Installed languages.

Note the differences:

  • Installed: languages that have translation files are installed on the server
  • Added: languages added by the 'Add Language' option. Localizable fields have a table column for each Added language.
  • Available: a subset of Added languages that can be selected via the language selector.

If the 'Add Language' option is used, further changes are made to the database to add a new table column for each localizable field. So for example, if French is Added, a new column title_fr_FR is added to the civicrm_event table. This can significantly change the database. For example, at the time of writing the civicrm_event table has 69 columns. Of those, 23 are localizable and so for every language Added, 23 columns are added to the table. There are limits on the number of columns and on the row length (see http://dev.mysql.com/doc/refman/5.7en/column-count-limit.html) that mean this approach has a practical limit of around 4-5 languages.

When additional languages are enabled, new functionality is enabled so that localizable content can be entered. For example, in our English/French example, the event configuration page has an option to set the event title in both English and French.

When the event info is viewed, and either the Default Language is French, or the user has selected French via the language selector, the French title is shown and also the interface is in French (eg 'Quand' instead of 'When').

Analysis

For organisations that operate in a single language, the default installation works well. The interface language is set by the administrator and there is only one version of localizable fields.

For organisations that operate in a small number of languages, the current multi-lingual system allows both the content and interface to be presented in one of the selected languages. Users can choose which language they use via the Language Switcher.

However, consider the example of an organisation that operates in many countries and languages:

  • Staff and users speak multiple languages and want to have the interface presented in their own language.
  • Events are run in multiple languages, but each event is single language and there is no need to provide the details in multiple languages.

The current choices are:

  • In mono-lingual mode, localizable fields (eg event title) are entered in the relevant language for that event without limitation. However, the interface language is limited to a single global setting which is not appropriate everywhere.

  • In multi-lingual mode, users are able to select their choice of interface language from the Available ones, but there is a practical limit of 4-5 languages. The limitation is introduced by the impact to the database schema although the additional fields are not actually useful.

In this scenario, a mono-language system with the Language Switcher that allows the user to select their choice of language would be better. This allows an unlimited number of interface languages to be made available and separates the interface language from that used to select localizable content.

Summary

Approach:

  • 'Available Languages' is enabled for mono-lingual mode as well as multi-lingual mode
  • Available languages is changed to select any Installed language, not just Added ones
  • in multi-lingual mode, the interface language is selectable separately from the localizable content language: the $lcMessages variable is used in both mono- and multi-lingual modes to select the interface language. In multi-lingual, if $lcMessages is in the list of Added languages, that is used for the localizable content, otherwise it falls back to the default language, or the value of $lcMessagesDb.

This has the effect of enabling the Language Switcher so that it appears in mono-lingual mode providing the administrator has configured more than one Available language. In multi-lingual mode, the language selector is available as previously, but is not limited to the languages used in the database.

To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information