Translation issueshttps://lab.civicrm.org/dev/translation/-/issues2018-02-13T01:54:21Zhttps://lab.civicrm.org/dev/translation/-/issues/2Localization of extensions2018-02-13T01:54:21ZcivideskLocalization of extensions* Missing documentation (or link to such in main page of this wiki)?
* Usage in extensions is currently cumbersome - does PHP 5.6/7.0 bring new features we could leverage for easier usage?* Missing documentation (or link to such in main page of this wiki)?
* Usage in extensions is currently cumbersome - does PHP 5.6/7.0 bring new features we could leverage for easier usage?https://lab.civicrm.org/dev/translation/-/issues/6Test translation issue2018-03-13T01:31:29ZbgmTest translation issueThis is a test for eileen/Product-maintenance#8, please ignore.This is a test for eileen/Product-maintenance#8, please ignore.https://lab.civicrm.org/dev/translation/-/issues/12Add Macedonian to officially distributed languages2018-06-13T14:56:21ZbgmAdd Macedonian to officially distributed languagesMacedonian is 100% translated, therefore should be added to the official distribution.
Request by `nikolam` on the translation channel.Macedonian is 100% translated, therefore should be added to the official distribution.
Request by `nikolam` on the translation channel.5.3.0bgmbgmhttps://lab.civicrm.org/dev/translation/-/issues/14InnoDB Advanced Logging cannot be enabled on multi-lingual2018-08-28T09:41:10ZbgmInnoDB Advanced Logging cannot be enabled on multi-lingualHow to reproduce:
* Install/configure a multi-lingual CiviCRM site with 2 languages
* Enable the [innodbtriggers](https://github.com/mlutfy/nz.co.fuzion.innodbtriggers) extension
* Run: `System.updatelogtables` to update the log tables....How to reproduce:
* Install/configure a multi-lingual CiviCRM site with 2 languages
* Enable the [innodbtriggers](https://github.com/mlutfy/nz.co.fuzion.innodbtriggers) extension
* Run: `System.updatelogtables` to update the log tables.
Result: fatal error, as encountered here: https://github.com/eileenmcnaughton/nz.co.fuzion.innodbtriggers/issues/1
Related, but not a duplicate: dev/translation#85.6bgmbgmhttps://lab.civicrm.org/dev/translation/-/issues/11Transifex localization strings out of date2018-09-11T20:28:33ZfrancescbassasTransifex localization strings out of dateTransifex strings are not updated since CiviCRM 4.7.12 version.Transifex strings are not updated since CiviCRM 4.7.12 version.bgmbgmhttps://lab.civicrm.org/dev/translation/-/issues/15Backend credit card contribution are left as Pending if contribution statuses...2018-10-24T20:56:28ZbgmBackend credit card contribution are left as Pending if contribution statuses are localizedHow to reproduce:
* Modify the Contribution Statuses, so that the label for Complete is 'Terminé' (https://dmaster.demo.civicrm.org/civicrm/admin/options?gid=11&reset=1) - this changes the label, not the `name`, so that we can localize ...How to reproduce:
* Modify the Contribution Statuses, so that the label for Complete is 'Terminé' (https://dmaster.demo.civicrm.org/civicrm/admin/options?gid=11&reset=1) - this changes the label, not the `name`, so that we can localize the contribution statuses.
* Go to a contact record and record a new credit card contribution (you can use the dummy processor)
![contribution-pending-status-complete](/uploads/0eb1ea21b9b42a7494182e5423b9aa10/contribution-pending-status-complete.gif)
If I change the contribution status back to 'Complete', it works as expected.
I suspect the culprit is here:
https://github.com/civicrm/civicrm-core/blob/master/CRM/Contribute/Form/Contribution.php#L1181
The `$statuses` are fetched using:
```
$statuses = CRM_Contribute_BAO_Contribution::buildOptions('contribution_status_id');
```
PS: the front-end form uses a hardcoded value:
* https://github.com/civicrm/civicrm-core/blob/master/CRM/Contribute/Form/Contribution/Confirm.php#L1649
* https://github.com/civicrm/civicrm-core/blob/master/CRM/Contribute/Form/Contribution/Confirm.php#L2465
```
protected function completeTransaction($result, $contributionID) {
if (CRM_Utils_Array::value('payment_status_id', $result) == 1) {
try {
civicrm_api3('contribution', 'completetransaction', array(
'id' => $contributionID,
'trxn_id' => CRM_Utils_Array::value('trxn_id', $result),
'payment_processor_id' => $this->_paymentProcessor['id'],
'is_transactional' => FALSE,
'fee_amount' => CRM_Utils_Array::value('fee_amount', $result),
'receive_date' => CRM_Utils_Array::value('receive_date', $result),
'card_type_id' => CRM_Utils_Array::value('card_type_id', $result),
'pan_truncation' => CRM_Utils_Array::value('pan_truncation', $result),
));
}
catch (CiviCRM_API3_Exception $e) {
if ($e->getErrorCode() != 'contribution_completed') {
throw new CRM_Core_Exception('Failed to update contribution in database');
}
}
}
}
```5.8https://lab.civicrm.org/dev/translation/-/issues/9Create API action to rebuild Multilingual Schema2019-01-24T18:11:20ZseamusleeCreate API action to rebuild Multilingual SchemaWe often run into a situation of late where the multilingual views haven't been properly updated. It is often difficult to instruct people how to rebuild the schema, Adding in an API action makes it simpleWe often run into a situation of late where the multilingual views haven't been properly updated. It is often difficult to instruct people how to rebuild the schema, Adding in an API action makes it simplehttps://lab.civicrm.org/dev/translation/-/issues/5Cannot export member addresses if the location_type display name has an accent2019-02-24T21:10:49ZbgmCannot export member addresses if the location_type display name has an accentHow to reproduce:
* Add a location type "Expédition", where name = `expedition` and display_name = `expédition`.
* Go to the member dashboard, click to list all active members
* Edit one of the contacts, so that they have an address of ...How to reproduce:
* Add a location type "Expédition", where name = `expedition` and display_name = `expédition`.
* Go to the member dashboard, click to list all active members
* Edit one of the contacts, so that they have an address of type "expédition"
* Back in the search results, export all results
* Select a custom mapping:
* Display name
* City, location type = Expédition
Result: the city is empty (for that contact that was edited).
If we remove the accent from the display name, it works fine. Also, it doesn't seem to be a mismatch issue between the name / display_name, because if it's "Expedition123" it works fine.5.5.0https://lab.civicrm.org/dev/translation/-/issues/22Can't resave custom field definitions on multilingual sites2019-04-26T19:09:35ZJoeMurrayCan't resave custom field definitions on multilingual sitesOn multilingual site 5.10.3 (Joomla, but that shouldn't make a difference), I entered pre help for a custom field. Save. Edit again. Remove value from field. Save again. It hangs. Error in Civi log:
https://gist.github.com/JoeMurray/ec6...On multilingual site 5.10.3 (Joomla, but that shouldn't make a difference), I entered pre help for a custom field. Save. Edit again. Remove value from field. Save again. It hangs. Error in Civi log:
https://gist.github.com/JoeMurray/ec6eb90a42a78a5d9fd2b242739178af
Further testing showed it hangs on any edit. Dropping the index would let it save once, but hang on 2nd and subsequent attempts.https://lab.civicrm.org/dev/translation/-/issues/26Notice error2019-05-02T13:34:44ZJoeMurrayNotice errorOn dmaster, enabled multilingual. On enabling French (Canada) as second language, I got
Notice: Undefined property: CRM_Core_DAO::$Create_Table in CRM_Core_DAO::checkConstraintExists() (line 945 of /srv/buildkit/build/dmaster/sites/all/...On dmaster, enabled multilingual. On enabling French (Canada) as second language, I got
Notice: Undefined property: CRM_Core_DAO::$Create_Table in CRM_Core_DAO::checkConstraintExists() (line 945 of /srv/buildkit/build/dmaster/sites/all/modules/civicrm/CRM/Core/DAO.php).
Notice: Undefined property: CRM_Core_DAO::$Create_Table in CRM_Core_DAO::checkConstraintExists() (line 945 of /srv/buildkit/build/dmaster/sites/all/modules/civicrm/CRM/Core/DAO.php).
Notice: Undefined property: CRM_Core_DAO::$Create_Table in CRM_Core_DAO::checkConstraintExists() (line 945 of /srv/buildkit/build/dmaster/sites/all/modules/civicrm/CRM/Core/DAO.php).https://lab.civicrm.org/dev/translation/-/issues/13Language switcher for all2019-05-29T13:26:01Zaydunsaidan.saunders@squiffle.ukLanguage switcher for allBack in [December](https://chat.civicrm.org/civicrm/pl/hritpyr87fg8zncpfq711eys9e) and [January](https://chat.civicrm.org/civicrm/pl/sod6xyw7wfbw3enr5ds9gz1yro), I asked about making the language switcher available in single-language mod...Back in [December](https://chat.civicrm.org/civicrm/pl/hritpyr87fg8zncpfq711eys9e) and [January](https://chat.civicrm.org/civicrm/pl/sod6xyw7wfbw3enr5ds9gz1yro), 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.5.10https://lab.civicrm.org/dev/translation/-/issues/28On Language prefix url setup in D8 or D7, custom searches doesn't respect the...2019-05-31T11:07:01ZMonish DebOn Language prefix url setup in D8 or D7, custom searches doesn't respect the language prefix after form submissionSteps to replicate:
1. Go to any existing or new custom search on any of the enabled language mod say French. The url will be https://www.example.com/fr/civicrm/contact/search/custom?csid=8&reset=1
2. Simply submit the form.
**Result**...Steps to replicate:
1. Go to any existing or new custom search on any of the enabled language mod say French. The url will be https://www.example.com/fr/civicrm/contact/search/custom?csid=8&reset=1
2. Simply submit the form.
**Result** : Reloads to https://www.example.com/civicrm/contact/search/custom?_qf_Custom_display=true&qfKey=16af65d8c7fd031923c056632ed145ce_3600 (The language prefix ```fr``` is missing)
**Expected** : Should reload to https://www.example.com/fr/civicrm/contact/search/custom?_qf_Custom_display=true&qfKey=16af65d8c7fd031923c056632ed145ce_36005.15.0Monish DebMonish Debhttps://lab.civicrm.org/dev/translation/-/issues/29Missing strings in the translation files (Date Received, Paid By)2019-08-06T15:06:04ZbgmMissing strings in the translation files (Date Received, Paid By)From the offline contribution receipt, there are strings that are always in English.
* Received Date
* Paid By
![Capture_d_écran_de_2019-08-06_08-55-38](/uploads/9186c620cfac07db2c9140813d0feb54/Capture_d_écran_de_2019-08-06_08-55-38.p...From the offline contribution receipt, there are strings that are always in English.
* Received Date
* Paid By
![Capture_d_écran_de_2019-08-06_08-55-38](/uploads/9186c620cfac07db2c9140813d0feb54/Capture_d_écran_de_2019-08-06_08-55-38.png)
I looked at Transifex and the strings seem to be missing. They are not in the gettext mo files either.https://lab.civicrm.org/dev/translation/-/issues/18Resolve difference between github and lab repos2020-01-16T18:17:12ZseamusleeResolve difference between github and lab reposOur automated jobs use the github repository as the primary source for po and the bin scripts. There have been some changes since the last time the repo was pushed to lab. We should probably aim to decide which should be the source of tr...Our automated jobs use the github repository as the primary source for po and the bin scripts. There have been some changes since the last time the repo was pushed to lab. We should probably aim to decide which should be the source of truth and then either alter the automated jobs to use the lab repo or set up a sync job in test.civicrm.org
ping @bgm @tottenbgmbgmhttps://lab.civicrm.org/dev/translation/-/issues/19DB Error: no such field after enabling Multiple Languages option2020-01-16T18:27:24ZYepaDB Error: no such field after enabling Multiple Languages optionWe've a single language installation with CiviCRM 5.6.1 & Drupal 7
After we've enabled the "Multiple Language" option under "Multiple Languages Support" section in the config page:
https://www.domain.org/civicrm/admin/setting/localiz...We've a single language installation with CiviCRM 5.6.1 & Drupal 7
After we've enabled the "Multiple Language" option under "Multiple Languages Support" section in the config page:
https://www.domain.org/civicrm/admin/setting/localization?reset=1
We have the following error:
```
Initialization Error
Array
(
[callback] => Array
(
[0] => CRM_Core_Error
[1] => simpleHandler
)
[code] => -19
[message] => DB Error: no such field
[mode] => 16
[debug_info] =>
SELECT v.label as label ,v.name as value, v.grouping as grouping
FROM civicrm_option_value v,
civicrm_option_group g
WHERE v.option_group_id = g.id
AND g.name = 'languages'
AND g.is_active = 1 AND v.is_active = 1 AND ( v.component_id IS NULL OR v.component_id IN (SELECT id FROM civicrm_component WHERE name IN ("CiviEvent","CiviContribute","CiviMember","CiviMail","CiviReport","CiviPledge","CiviCase","CiviCampaign")) ) ORDER BY v.weight [nativecode=1054 ** Unknown column 'v.label' in 'field list']
[type] => DB_Error
[user_info] =>
SELECT v.label as label ,v.name as value, v.grouping as grouping
FROM civicrm_option_value v,
civicrm_option_group g
WHERE v.option_group_id = g.id
AND g.name = 'languages'
AND g.is_active = 1 AND v.is_active = 1 AND ( v.component_id IS NULL OR v.component_id IN (SELECT id FROM civicrm_component WHERE name IN ("CiviEvent","CiviContribute","CiviMember","CiviMail","CiviReport","CiviPledge","CiviCase","CiviCampaign")) ) ORDER BY v.weight [nativecode=1054 ** Unknown column 'v.label' in 'field list']
[to_string] => [db_error: message="DB Error: no such field" code=-19 mode=callback callback=CRM_Core_Error::simpleHandler prefix="" info="
SELECT v.label as label ,v.name as value, v.grouping as grouping
FROM civicrm_option_value v,
civicrm_option_group g
WHERE v.option_group_id = g.id
AND g.name = 'languages'
AND g.is_active = 1 AND v.is_active = 1 AND ( v.component_id IS NULL OR v.component_id IN (SELECT id FROM civicrm_component WHERE name IN ("CiviEvent","CiviContribute","CiviMember","CiviMail","CiviReport","CiviPledge","CiviCase","CiviCampaign")) ) ORDER BY v.weight [nativecode=1054 ** Unknown column 'v.label' in 'field list']"]
)
```
To solve this issue, we've hacked the DAO.php file to set the global var: $dbLocale
```
@@ -423,10 +423,8 @@ class CRM_Core_DAO extends DB_DataObject {
global $dbLocale, $_DB_DATAOBJECT;
+ if (!$dbLocale) {$dbLocale = '_en_US';}
+
if (empty($_DB_DATAOBJECT['CONNECTIONS'][$this->_database_dsn_md5])) {
// Will force connection to be populated per CRM-20541.
new CRM_Core_DAO();
```
Do you have an idea about this?https://lab.civicrm.org/dev/translation/-/issues/16All forum references at readme.md of this project should be supressed2020-01-16T21:49:38ZcalbasiAll forum references at readme.md of this project should be supressedHi,
CiviCRM forums are not available from long ago. We should suppress their references at this repo readme.md file.
I'm not sure if merge requests are available to users like me ;-)Hi,
CiviCRM forums are not available from long ago. We should suppress their references at this repo readme.md file.
I'm not sure if merge requests are available to users like me ;-)https://lab.civicrm.org/dev/translation/-/issues/33Errors in link ReCaptcha and Extension Directory2020-01-26T18:48:06ZHanVErrors in link ReCaptcha and Extension DirectoryAfter registrating this on stackexchange, I got the comment that I must registrated this here:
In version 5.20.0 there are errors in links.
Administer > System Settings > Misc, the first link reCaptcha is with additional quotes around ...After registrating this on stackexchange, I got the comment that I must registrated this here:
In version 5.20.0 there are errors in links.
Administer > System Settings > Misc, the first link reCaptcha is with additional quotes around target. The link is working but opened in the same tab.
Administer > System Settings > Payment Processors, in the Payment Processors Help, the link one for Extension Directory is wrong. The same error for the help WYSIWYG Editor when : Display Preferences.5.23.0https://lab.civicrm.org/dev/translation/-/issues/36Select_string only accepts integers: 12020-02-20T13:47:08ZbgmSelect_string only accepts integers: 1I noticed this bug on 5.23 beta1 and dmaster, and somehow I don't think it's specific to 5.23, but I'm not seeing it elsewhere:
* Change the CiviCRM language to another language (ex: en_UK) [link](https://dmaster.demo.civicrm.org/civicr...I noticed this bug on 5.23 beta1 and dmaster, and somehow I don't think it's specific to 5.23, but I'm not seeing it elsewhere:
* Change the CiviCRM language to another language (ex: en_UK) [link](https://dmaster.demo.civicrm.org/civicrm/admin/setting/localization?reset=1)
* Use the default phpgettext, not native gettext
* Go to Find Contacts, then click Find. (i.e. search all, doesn't matter)
Resulting fatal: Select_string only accepts integers: 1
Relevant backtrace bit:
```
array(6) {
["file"]=>
string(79) "/var/aegir/platforms/civicrm-d7/web/sites/all/modules/civicrm/CRM/Core/I18n.php"
["line"]=>
int(451)
["function"]=>
string(8) "ngettext"
["class"]=>
string(14) "gettext_reader"
["type"]=>
string(2) "->"
["args"]=>
array(3) {
[0]=>
string(14) "%count Contact"
[1]=>
string(15) "%count Contacts"
[2]=>
string(3) "241"
}
}
```
This is from a `ts` call in `ResultTasks.tpl`. Oddly, that file has not changed in many years.
Enabling Native gettext (which I recommend) mitigates this problem, but obviously not a good core fix.
Can someome confirm if it is a regression?
![Peek_19-02-2020_17-21](/uploads/f376180834d0ac90b94f30d8c2923608/Peek_19-02-2020_17-21.gif)5.23.0https://lab.civicrm.org/dev/translation/-/issues/37Ancient switch statement that provides hardcoded translation doesn't do anyth...2020-02-24T16:28:47ZDaveDAncient switch statement that provides hardcoded translation doesn't do anything anymore@bgm FYI since you might find this academically interesting since it's like "Translation Archaeology".
These lines do nothing: https://github.com/civicrm/civicrm-core/blob/5.22.1/CRM/Activity/Selector/Activity.php#L397-L420
Except for ...@bgm FYI since you might find this academically interesting since it's like "Translation Archaeology".
These lines do nothing: https://github.com/civicrm/civicrm-core/blob/5.22.1/CRM/Activity/Selector/Activity.php#L397-L420
Except for a code-format whitespace change, these lines are unchanged from when they were added 13 years ago and predates the concept of option value labels and was likely added when translation capability was first being added. The comment even still says "DRAFTING".
In particular note that $row['activity_type'] here is the `LABEL` for the option value. **So this switch() doesn't do anything.** Here's a table:
| Scenario | Effect of the switch() |
|------------------------------------------------------------------------------------------------------------------------------------------|---------------------------------------------------------------------------------------------------------------------------------------------------------------|
| US English | Does nothing |
| UK English, labels and names are the same | Does nothing |
| UK English, labels and names are different | Almost never does anything (see next scenario) |
| UK English, but for example the label for activity type Meeting has been changed to Email. I don't know why anyone would do that though. | It would translate Email to Email since it's english, so still does nothing. |
| Non-english, and the label is non-english. | Does nothing |
| Non-english, but you've for some reason changed the label for e.g. Email back to english. But why would you do that? | It will translate it, but in this situation that's a bug because you changed the label to english on purpose because you wanted english, for whatever reason. |
Extra
-----
What's also interesting but is a separate TODO that I'm not going to look closer at right now: I'm not 100% sure when this code even runs. You can trigger it by visiting manage case if the client has some non-case activities, but I don't know why it's even retrieving those non-case activities when you're looking at manage case. And the function is NOT called when looking at a contact's activity tab. It does NOT run when showing results for an activity search.
For manage case it's called from Case_Page_Tab which calls Core_Select_Controller(output = SESSION).
Note that getRows isn't returning any case activities, just the non-case ones. The actual rows you see on manage case come from CRM/Case/Form/ActivityTab.tpl via ajax call to civicrm/ajax/activity, which is CRM_Activity_Page_AJAX::getCaseActivity()5.24.0https://lab.civicrm.org/dev/translation/-/issues/35Getting Started dashlet does not cache per language2020-03-10T19:36:41ZbgmGetting Started dashlet does not cache per languageTo reproduce:
* Go to Localization Settings: https://dmaster.demo.civicrm.org/civicrm/admin/setting/localization?reset=1
* Under "Available languages", add "French (France)"
* Switch languages: https://dmaster.demo.civicrm.org/civicrm?r...To reproduce:
* Go to Localization Settings: https://dmaster.demo.civicrm.org/civicrm/admin/setting/localization?reset=1
* Under "Available languages", add "French (France)"
* Switch languages: https://dmaster.demo.civicrm.org/civicrm?reset=1&lcMessages=fr_FR
* Click "configurer votre tableau de bord" (configure dashboard)
* Add "CiviCRM Resources"
Now notice that the dashlet is available in French.
However, go back to English and refresh the dashboard data, and it will still be in English:
* To switch back: https://dmaster.demo.civicrm.org/civicrm?reset=1&lcMessages=en_US
![Capture_d_écran_de_2020-01-22_17-27-39](/uploads/4a3a40a74edf4741683c55f88973f086/Capture_d_écran_de_2020-01-22_17-27-39.png)
Small print:
* This depends on first fixing the 'evalUrl' function to use the correct tsLocale.5.23.0