Translation issueshttps://lab.civicrm.org/dev/translation/-/issues2020-08-11T11:18:57Zhttps://lab.civicrm.org/dev/translation/-/issues/1Distribution and management of l10n/xx_YY/settings.default.json files2020-08-11T11:18:57ZbgmDistribution and management of l10n/xx_YY/settings.default.json filesNow that CRM-16395 has been merged, we can provide localised setting files for supported languages.
Now we need to:
* [x] decide where to store (in the 'l10n' git repo) the settings files
* [x] bundle those json files in civicrm-5.x.xx...Now that CRM-16395 has been merged, we can provide localised setting files for supported languages.
Now we need to:
* [x] decide where to store (in the 'l10n' git repo) the settings files
* [x] bundle those json files in civicrm-5.x.xx-l10n.tar.gz
* [x] document the process by which people can send/update setting files
* [ ] update the documentation about non-English installation?
Example:
https://github.com/civicrm/civicrm-core/files/305643/settings.default.json.txthttps://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/3'minimal' subset of localized strings2020-06-28T22:02:47Zcividesk'minimal' subset of localized strings10% of strings are probably accounting for 90% of displayed text in CiviCRM - the rest are error messages or other help text that is rarely seen. Identify this subset of strings, and then structure Transifex so it's easy to translate thi...10% of strings are probably accounting for 90% of displayed text in CiviCRM - the rest are error messages or other help text that is rarely seen. Identify this subset of strings, and then structure Transifex so it's easy to translate this 'minimal' subset. This should very significantly facilitate translation of CiviCRM in new languages AND help in improving existing translations.https://lab.civicrm.org/dev/translation/-/issues/4Create nl_BE translation2020-04-10T01:47:08ZbgmCreate nl_BE translationDiscussed at CiviCamp Brussels, February 2018:
* [x] Create a nl_BE translation of CiviCRM
* [x] Synchronize from nl_NL, so that it is possible to re-use the existing NL translation, but adapt a few sentences where necessary.
cc @alainbDiscussed at CiviCamp Brussels, February 2018:
* [x] Create a nl_BE translation of CiviCRM
* [x] Synchronize from nl_NL, so that it is possible to re-use the existing NL translation, but adapt a few sentences where necessary.
cc @alainbhttps://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/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/7Update Localizing Documentation (Drupal configurations)2019-01-14T15:52:50ZshaneonabikeUpdate Localizing Documentation (Drupal configurations)There is some special mapping configurations for multilingual Drupal sites to map the proper languages between Drupal and CiviCRM. Is there a way I could update the existing documentation?
https://docs.civicrm.org/user/en/latest/the-civ...There is some special mapping configurations for multilingual Drupal sites to map the proper languages between Drupal and CiviCRM. Is there a way I could update the existing documentation?
https://docs.civicrm.org/user/en/latest/the-civicrm-community/localising-civicrm/
`"Inherit CMS language" and regional translations (ex: fr_CA)
If you have a multi-lingual site and you are using the "inherit CMS language" configuration option, but wish to, for example, use fr_CA instead of the default fr_FR (for French), you can define a constant in your "civicrm.settings.php" to override the default behavior.
See CRM-9558 for more information.
define('CIVICRM_LANGUAGE_MAPPING_FR', 'fr_CA');
`
From https://wiki.civicrm.org/confluence/display/CRMDOC/i18n+Administrator%27s+Guide%3A+Using+CiviCRM+in+your+own+languagehttps://lab.civicrm.org/dev/translation/-/issues/8Multilingual installation with logging enabled gives error when custom field ...2020-07-14T14:56:53ZtbuytaerMultilingual installation with logging enabled gives error when custom field is changedLogging of custom fields on a multilingual installation does not work, which makes it impossible to view changes if one of the changes is a custom field.
Steps to reproduce:
1. install a fresh CiviCRM installation: 5.0 (the issue also ...Logging of custom fields on a multilingual installation does not work, which makes it impossible to view changes if one of the changes is a custom field.
Steps to reproduce:
1. install a fresh CiviCRM installation: 5.0 (the issue also existed in versions before)
2. enable **Multiple Languages Support** on http://example.org/civicrm/admin/setting/localization?reset=1
3. enable **logging** on http://example.org/civicrm/admin/setting/misc?reset=1
4. change a custom field of a contact
5. view the changelog of that contact and click on the change
This results in follwing Database error:
> Database Error Code: Table 'databasename.log_civicrm_custom_group_en_US' doesn't exist, 1146
> Additional Details:
> Array
> (
> [callback] => Array
> (
> [0] => CRM_Core_Error
> [1] => handle
> )
>
> [code] => -18
> [message] => DB Error: no such table
> [mode] => 16
> [debug_info] => SELECT id, title FROM `databasename`.log_civicrm_custom_group_en_US WHERE log_date <= '2018-04-09 17:40:29' AND table_name = 'civicrm_value_constituent_information_1' ORDER BY log_date DESC LIMIT 1 [nativecode=1146 ** Table 'databasename.log_civicrm_custom_group_en_US' doesn't exist]
> [type] => DB_Error
> [user_info] => SELECT id, title FROM `databasename`.log_civicrm_custom_group_en_US WHERE log_date <= '2018-04-09 17:40:29' AND table_name = 'civicrm_value_constituent_information_1' ORDER BY log_date DESC LIMIT 1 [nativecode=1146 ** Table 'databasename.log_civicrm_custom_group_en_US' doesn't exist]
> [to_string] => [db_error: message="DB Error: no such table" code=-18 mode=callback callback=CRM_Core_Error::handle prefix="" info="SELECT id, title FROM `databasename`.log_civicrm_custom_group_en_US WHERE log_date <= '2018-04-09 17:40:29' AND table_name = 'civicrm_value_constituent_information_1' ORDER BY log_date DESC LIMIT 1 [nativecode=1146 ** Table 'databasename.log_civicrm_custom_group_en_US' doesn't exist]"]
> )
*I replaced the actual database name with 'databasename' in the error message above*https://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/10Missing downloadable file translation for CiviSEPA extension (and others?)2022-02-14T16:59:05ZfrancescbassasMissing downloadable file translation for CiviSEPA extension (and others?)I'm not able to find the file translation for CiviSEPA extension, I'm trying to download from https://download.civicrm.org/civicrm-l10n-extensions/mo/sepa/es_ES/sepa.mo without success. I'm missing something? CiviSepa has a Transifex pro...I'm not able to find the file translation for CiviSEPA extension, I'm trying to download from https://download.civicrm.org/civicrm-l10n-extensions/mo/sepa/es_ES/sepa.mo without success. I'm missing something? CiviSepa has a Transifex project but seems that .mo files aren't being generated at https://test.civicrm.org/view/i18n/job/CiviCRM-l10n-mo-build/gcsObjects/.https://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/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/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/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/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/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/17RTL issue: form label should be at right, and their input fields, at the left.2018-10-22T18:50:53ZcalbasiRTL issue: form label should be at right, and their input fields, at the left.I'm not sure if I should create this issue here or at civicrm core repository. Doing here, as first step to make a Merge Request at Github repository.
I'm attaching an screenshot of the wrong output. It's wrong, at least, in Arabic, but...I'm not sure if I should create this issue here or at civicrm core repository. Doing here, as first step to make a Merge Request at Github repository.
I'm attaching an screenshot of the wrong output. It's wrong, at least, in Arabic, but I suppose it's wrong for all other RTL languages. It's, too, a basic feature, because forms are used everywhere...
This issue happens at custom profile but also at system/default profiles.![Captura_2018-09-13_17-20-29](/uploads/3bdba1980909fd4fb5a0ea96979bd24d/Captura_2018-09-13_17-20-29.png)
![Captura_2018-09-13_17-17-19](/uploads/e6b36a362c68005b37c0a74e0d106194/Captura_2018-09-13_17-17-19.png)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/20DB Error: no such table when executing schedule jobs2022-11-07T18:05:35ZYepaDB Error: no such table when executing schedule jobsWe'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
If we prepare a mailing with a language different from the language interface, when we execute the schedule jobs, we have the following error:
```
Feb 14 18:17:32 [info] $Fatal Error Details = Array
(
[callback] => Array
(
[0] => CRM_Core_Error
[1] => handle
)
[code] => -18
[message] => DB Error: no such table
[mode] => 16
[debug_info] => select id, extends, extends_entity_column_value, style from civicrm_custom_group__en_US where is_active = 1 [nativecode=1146 ** Table 'drupal.civicrm_custom_group__en_US' doesn't exist]
[type] => DB_Error
[user_info] => select id, extends, extends_entity_column_value, style from civicrm_custom_group__en_US where is_active = 1 [nativecode=1146 ** Table 'drupal.civicrm_custom_group__en_US' doesn't exist]
[to_string] => [db_error: message="DB Error: no such table" code=-18 mode=callback callback=CRM_Core_Error::handle prefix="" info="select id, extends, extends_entity_column_value, style from civicrm_custom_group__en_US where is_activ$
)
Feb 14 18:17:32 [info] $backTrace = #0 /var/www/drupal/public_html/sites/all/modules/civicrm/CRM/Core/Error.php(232): CRM_Core_Error::backtrace("backTrace", TRUE)
#1 [internal function](): CRM_Core_Error::handle(Object(DB_Error))
#2 /var/www/drupal/public_html/sites/all/modules/civicrm/packages/PEAR.php(921): call_user_func((Array:2), Object(DB_Error))
#3 /var/www/drupal/public_html/sites/all/modules/civicrm/packages/DB.php(985): PEAR_Error->__construct("DB Error: no such table", -18, 16, (Array:2), "select id, extends, extends_entity_column_value, style from civicrm_custom_gr...")
#4 /var/www/drupal/public_html/sites/all/modules/civicrm/packages/PEAR.php(575): DB_Error->__construct(-18, 16, (Array:2), "select id, extends, extends_entity_column_value, style from civicrm_custom_gr...")
#5 [internal function](): PEAR->_raiseError(Object(DB_mysqli), NULL, -18, NULL, NULL, "select id, extends, extends_entity_column_value, style from civicrm_custom_gr...", "DB_Error", TRUE)
#6 /var/www/drupal/public_html/sites/all/modules/civicrm/packages/PEAR.php(224): call_user_func_array((Array:2), (Array:8))
#7 /var/www/drupal/public_html/sites/all/modules/civicrm/packages/DB/common.php(1907): PEAR->__call("raiseError", (Array:7))
#8 /var/www/drupal/public_html/sites/all/modules/civicrm/packages/DB/common.php(1907): PEAR->raiseError(NULL, -18, NULL, NULL, "select id, extends, extends_entity_column_value, style from civicrm_custom_gr...", "DB_Error", TRUE)
#9 /var/www/drupal/public_html/sites/all/modules/civicrm/packages/DB/mysqli.php(933): DB_common->raiseError(-18, NULL, NULL, NULL, "1146 ** Table 'drupal.civicrm_custom_group__en_US' doesn't exist")
#10 /var/www/drupal/public_html/sites/all/modules/civicrm/packages/DB/mysqli.php(403): DB_mysqli->mysqliRaiseError()
#11 /var/www/drupal/public_html/sites/all/modules/civicrm/packages/DB/common.php(1216): DB_mysqli->simpleQuery("select id, extends, extends_entity_column_value, style from civicrm_custom_gr...")
#12 /var/www/drupal/public_html/sites/all/modules/civicrm/packages/DB/DataObject.php(2415): DB_common->query("select id, extends, extends_entity_column_value, style from civicrm_custom_gr...")
#13 /var/www/drupal/public_html/sites/all/modules/civicrm/packages/DB/DataObject.php(1607): DB_DataObject->_query("select id, extends, extends_entity_column_value, style from civicrm_custom_gr...")
#14 /var/www/drupal/public_html/sites/all/modules/civicrm/CRM/Core/DAO.php(438): DB_DataObject->query("select id, extends, extends_entity_column_value, style from civicrm_custom_gr...")
#15 /var/www/drupal/public_html/sites/all/modules/civicrm/CRM/Core/DAO.php(1411): CRM_Core_DAO->query("select id, extends, extends_entity_column_value, style from civicrm_custom_gr...", TRUE)
#16 /var/www/drupal/public_html/sites/all/modules/civicrm/drupal/modules/views/components/civicrm.core.inc(3119): CRM_Core_DAO::executeQuery("select id, extends, extends_entity_column_value, style from civicrm_custom_gr...")
#17 /var/www/drupal/public_html/sites/all/modules/civicrm/drupal/modules/views/civicrm.views.inc(87): _civicrm_core_data((Array:301), (Array:8))
#18 /var/www/drupal/public_html/sites/all/modules/contrib/views/includes/cache.inc(93): civicrm_views_data_alter((Array:301))
#19 /var/www/drupal/public_html/sites/all/modules/contrib/views/includes/cache.inc(37): _views_fetch_data_build()
#20 /var/www/drupal/public_html/sites/all/modules/contrib/views/views.module(1319): _views_fetch_data("twitter", FALSE, FALSE)
#21 /var/www/drupal/public_html/sites/all/modules/contrib/views/views.module(1655): views_fetch_data("twitter", FALSE)
#22 /var/www/drupal/public_html/sites/all/modules/contrib/views/includes/view.inc(277): views_move_table("twitter")
#23 /var/www/drupal/public_html/sites/all/modules/contrib/views/views.module(1643): view->update()
#24 /var/www/drupal/public_html/sites/all/modules/contrib/views/views.module(762): views_get_view("tweets")
#25 [internal function](): views_block_view("tweets-block")
#26 /var/www/drupal/public_html/includes/module.inc(934): call_user_func_array("views_block_view", (Array:1))
#27 /var/www/drupal/public_html/modules/block/block.module(911): module_invoke("views", "block_view", "tweets-block")
#28 /var/www/drupal/public_html/modules/block/block.module(690): _block_render_blocks((Array:1))
#29 /var/www/drupal/public_html/modules/block/block.module(319): block_list("footer3")
#30 /var/www/drupal/public_html/modules/block/block.module(270): block_get_blocks_by_region("footer3")
#31 /var/www/drupal/public_html/includes/common.inc(5914): block_page_build((Array:11))
#32 /var/www/drupal/public_html/includes/common.inc(2761): drupal_render_page("\n<div id=\"crm-container\" class=\"crm-container\" lang=\"en\" xml:lang=\"en...")
#33 /var/www/drupal/public_html/includes/common.inc(2634): drupal_deliver_html_page("\n<div id=\"crm-container\" class=\"crm-container\" lang=\"en\" xml:lang=\"en...")
#34 /var/www/drupal/public_html/includes/menu.inc(542): drupal_deliver_page("\n<div id=\"crm-container\" class=\"crm-container\" lang=\"en\" xml:lang=\"en...", "")
#35 /var/www/drupal/public_html/index.php(21): menu_execute_active_handler()
#36 {main}
```
The global $dbLocale is equal to '__en_US' because it's not correctly set in the public function setLocale($locale) of i18n.php. The $locale is equal to '_en_US' when the fatal error occurred.
```
/**
* Change the processing language without changing the current user language
*
* @param $locale
* Locale (for example 'en_US', or 'fr_CA').
* True if the domain was changed for an extension.
*/
public function setLocale($locale) {
// Change the language of the CMS as well, for URLs.
CRM_Utils_System::setUFLocale($locale);
// change the gettext ressources
if ($this->_nativegettext) {
$this->setNativeGettextLocale($locale);
}
else {
// phpgettext
$this->setPhpGettextLocale($locale);
}
// for sql queries
global $dbLocale;
$dbLocale = "_{$locale}";
}
```
"inherit locale" option is enabled and no cache error.
Here is the backtrace from setLocale function: [locale_not_well_set_error.txt](/uploads/29d6263e244abc1d0973ff4679463615/locale_not_well_set_error.txt)
I tried without sendgrid extension, the error was the same.