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! Feel free to post on the Internationalisation and localisation forum to discuss any of these issues.
- CRM-16388 Add multilingual support to localization settings (money format, date format)
- CRM-14349 4.7.x? Word Replacements table needs to be multilingual to support multilingual sites
- dev/translation13 5.10 Language switcher for all (allow switching languages of the interface even if the database is not multi-lingual)
- PR 15411 5.17 Fix custom translation function. Previously CRM-19896.
- CRM-21719 4.7.31 Require Multibyte PHP Extension
- CRM-21627 4.7.31 Fix for enabling multi-lingual after installation
- CRM-21698 4.7.31 Changes in money formatting, which should fix some issues with using a comma as a decimal separator.
- CRM-21407 4.7.30 ISO compliance for German counties
- CRM-21470 4.7.29 WordPress Polylang plugin support
- CRM-21319 4.7.28 Total amount not translated on Contribution Page
- CRM-21268 4.7.28 Missing French overseas departments
- CRM-21283 4.7.27 Incorporate Barbados and Antigua and Barbuda Parishes into States list
- CRM-21234 4.7.27 Missing subdivisions of Tajikistan
- CRM-21196 4.7.27 Event reports translation
- CRM-16395 4.7.23 When installing in a specific language, load settings for that locale, ex: default currency, date formats
- CRM-20803 4.7.23 Enable Farsi (fa_IR), Serbian (sr_RS), Ukrainian (uk_UA) in the languages option group so that we can install in those languages
- CRM-19683 4.7.15 Fix multilingual word replacements (partial fix, see CRM-14349)
- CRM-16355 4.7.13 Schedule reminder language settings (to send reminders in the contact's language)
- CRM-16352 4.7.13 CiviMail in multilingual sites: allow to define the language of the mailing (for tokens, unsubscribe links)
- CRM-19135 4.7.11 preferred_mail_format not selecting translated labels in international versions
- CRM-18991 4.7.10 localize descriptions for financial_account_type and account_relationship in data
- CRM-18362 4.7.9 Cleanup confusion between $config->lcMessages and global $tsLocale.
- CRM-14426 4.7.0 Logging activation fails with multi-language enabled
- CRM-16176 4.7.0 Make it possible to translate relationship types label
- CRM-15375 4.7.0 Add wysiwyg editor in the multilingual popup for fields that need it
- CRM-14588 4.7.0 Non Local Date format used in membership thank you and confirm contribution pages (4.7.0)
Have a (very) long page to list all contribution page title/description, event title/description, option values, etc, to have a quick way of translating everything and finding strings? Have a way to search?
- nb: still requires a patch on core to fix overriding the 'ts' function.
- 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.
Add support for
- 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
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_valueto 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).
- Use the "filter" column of
- 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
- 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
- Naming convention for first/last name, middle name, nickname, etc. How do various languages use them?
- 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
- forum.civicrm: promote locale/locality forums higher up
- create a forum for all languages > 20% ?
- find a new home for non-English Q&A (the forum will go read-only in 2017)
- www.civicrm.org: better download page for each language, make sure we link to the i18n install docs (see: https://civicrm.org/download-translations)
- CRM-16363 Display i18n downloads if browser language not English
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
- 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.
- Automatic synchronisation of regional translations.
- Jenkins task to detect new strings. Not necessarely 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.