Skip to content
Snippets Groups Projects

roadmap

Last edited by bgm

What's planned for those using CiviCRM in another language than English? The following is a list of issues that have been identified and need work. Any help is most appreciated!

Disclaimer

This roadmap is not actively updated. It might be more accurately called "the old backlog of translation issues". Issues on Gitlab might give a better idea of what is being worked on.

Issue tracking

There are two places for tracking translation issues:

2025 Update

CiviCRM installer

We have been working to improve the CiviCRM installer and the installation documentation. More specifically, in the past few years, we:

  • Removed the ".sql" files required for installing CiviCRM in another language than US-English (which meant making sure that all CMS-specific installers used the "new" installer, known as civicrm-setup).
  • Removed the requirement to install the civicrm-l10n.tar.gz file, since now the translation file can be fetched live by the installer. Which was made possible by having an "l10n" directory that lives under the "uploads" directory, instead of under civicrm-core directory (which is usually read-only, or at least, not web-writable).
  • Default settings for various locales are being added to core: https://github.com/civicrm/civicrm-core/pull/32610

We are now at the point where we do not recommend the installation of the civicrm-l10n.tar.gz file, and instead recommend that people install Update Language Files. Although there are also discussions about distributing the translation files ("mo" files) directly with core, at least for CiviCRM Standalone.

Packaged SearchKit translation

When we replace parts of the CiviCRM interface with SearchKit/Afform, the SearchKit side is not multi-lingual. The language of the cache flush will determine the language of the SearchKit configurations.

These issues have been stuck for a while, and are blockers to replacing more interfaces in CiviCRM.

Message Admin

The core extension "Message Admin" provides a new interface to editing Message Templates. It also makes it possible to translate Message Templates using more "fuzzy" rules. For example, if an organization mainly operates in English, but has contribution receipts in various languages. Some of those receipts might have a translation specific for Spanish in the Americas and another translation for Spain, or it might just have a translation for Spanish (regardless of the region).

core#4699

Revamping multi-lingual

Message Admin introduced a new civicrm_translation table, that can be used to translate configurations using an Entity ID/Field model. This does not work for everything (such as SearchKit/FormBuilder), but it works well for most basic entities (Contribution Pages, Events, etc).

Moving to this model would fix the current limitation on multi-lingual, which makes it difficult to have an installation in more than 3-4 languages.

This work is not funded nor prioritized, but patches welcome (ideally, starting as a few small core patches, with an extension for early adopters).

CiviCRM core

  • CRM-16388 Add multilingual support to localization settings (money format, date format)
    • This is less necessary now that CiviCRM uses a library for formatting Money, which is derived from the locale/language. Time/Date might be an issue, but the YYYY-MM-DD HH:MM (24h) tends to be more common, except for the US.
  • dev/core#600 Word Replacements table needs to be multilingual to support multilingual sites

Extensions

  • Extensions cannot add translatable menu item titles
    • Add a "domain" (or 'extension') column to civicrm_menu, so that we can properly translate the menu title in ts() with the good domain.
    • Update hook_civicrm_navigationMenu() so that translation authors add the required metadata to their navigation menu items.
  • Propose/document ways to handle a common translation between regional translations (ex: common 'es' translation for 'es_ES' and 'es_MX'?) Could be done in l10nupdate.
  • Update the i18nexample extension with better examples for JS (ts closure), smarty and E::ts.

Dev backlog

These are limitations that we are aware of, but no one is working on it.

  • Decimal/Thousand separator
    • Use the "filter" column of civicrm_option_value to map to a constant of supported mappings for decimal/thousand configurations.
    • Extension that removes custom decimal/thousand settings, and move formatting to the HTML form layer. Whenever a user submits/blur a form, it gets encoded to computer format (without thousand separator, and dot as decimal separator).
  • Greeting formats translation
  • Mailing labels translation
    • add the address format in the civicrm_country table?
    • have tokens for the formatted address? (not just the individual address parts)
    • impact on the mailing labels creation?
    • formatting of addresses in places such as the ThankYou page of online contributions? (ex: the country is formatted as a 2-letter abbreviation) Format as the UI language?
  • UI for multilingual -> disable the standard field to force people see the different languages
  • CiviContribute
    • CRM-17199 in honor/memory of: the title and description text is not localizable? (the code is weird, see CRM/Contribute/Form/SoftCredit.php buildQuickForm().
    • "Other Amount $" hardcodes a currency symbol after the field label (c.f. CRM/Price/BAO/PriceField.php, line ~ 330: $label .= ' ' . $currencySymbol).
  • Setting for "first day of the week" (has an impact on reports). See also 4.7 work on user-defined report date ranges.
  • Make the "organisation name" and "job title" multi-lingual? (goes with forcing to use the popups when editing those fields, in the past people would edit an organisation name in one language, and forget to update in the other language) - optional ?
  • Event locations are not multi-lingual, event description? (should be.. bug?)
  • (duplicate - cf CRM-16388) address format for labels should be multi-lingual (or depending on country?) .. sort of related to greetings (combinatory settings)
  • (big one) be able to enter titles/descriptions in multiple languages when creating new entities, not just edition. Ex: when creating a new group, the group must first be created in one language, then the user has to go back to editing the group and translate its name. This is really annoying for example when creating a new smart group from the advanced search.
  • CRM-10006: When a language is removed in multilingual, the database is not cleaned up.
  • When the CiviCRM core upgrader is run, if a localised install, make sure that the l10n files are present (sometimes admins forget to re-download the l10n files).
  • When cloning contribution (and event?) pages, only the current language is cloned (ex: contribution page title).
  • When a new language is added, pre-populate the translation of various option values.
    • we can't assume that people install English first, then French (for example). They might be using Ukrainian and Russian.. so we can't just send strings in ts(). An option would be to move option-values from xml/templates/civicrm_data.tpl to an XML file, and then do lookups in the XML file using the option_value.name.
  • Test RTL support for the CiviCRM menu.
  • Contact Type token uses the name instead of the label (not translated)
  • CRM-10509 - multilingual label for country / state (still a problem ?)
  • Report instances titles (and other settings?) should be multi-lingual
  • a/b testing interface of CiviMail is not translated
  • civimail/letter or anything else with templates: have a way to select a template based on gender?
  • "New %1" (ex: new organisation) -> causes gender problems, also very confusing to users that the page title is not the same as the menu item.
  • Export/import of settings: the API has a option.language parameter, but what would be the most efficient way to upload/update settings?

Websites / community / marketing

  • Create a forum for all languages > 20% ?
  • Find a new home for non-English Q&A (the forum is read-only since 2017)

Documentation

User documentation, with good practices for multi-lingual CiviCRM, ex:

  • multi-lingual mail/PDF templates (using if/else for language, vs using 1 template per language)
  • scheduled reminders
  • mailings
  • saving the contact's preferred communication language
  • formality, greetings, address formats
  • document how to use string replacements in multi-lingual
  • procedure for the user-admin book translation.

Infrastructure

  • Jenkins task to detect new strings. Not necessarily push them automatically to Transifex.. but.. would be neat feedback to have regularly, have a faster cycle to push new strings (currently mostly manual).
  • commit-hook to test/enforce ts() syntax usage.

Comments

    Please register or sign in to add a comment.