Translation issueshttps://lab.civicrm.org/dev/translation/-/issues2021-03-18T00:43:45Zhttps://lab.civicrm.org/dev/translation/-/issues/58Cannot create proper `Group`s on multilingual with MySQL 5.6 and Civi 5.31-rc2021-03-18T00:43:45ZtottenCannot create proper `Group`s on multilingual with MySQL 5.6 and Civi 5.31-rcThe unit-test `CRM_Mailing_MailingSystemTest::testGitLabIssue1108()` sets up a multilingual configuration and creates two groups. The test is failing, which reveals a problem with `Group`s on multilingual.
Steps to reproduce
-----------...The unit-test `CRM_Mailing_MailingSystemTest::testGitLabIssue1108()` sets up a multilingual configuration and creates two groups. The test is failing, which reveals a problem with `Group`s on multilingual.
Steps to reproduce
-------------------
Use an environment like `bknix-min` (e.g. MySQL 5.6 + PHP 7.1). Create a site on 5.31. Then either:
* Run the unit-test
* Use the live site -- [Enable multi-lingual](https://gist.github.com/totten/e1244d9a98c9d9fd1ebc899f5e780252) and [create two groups](https://gist.github.com/totten/b405a10cd82f35d125d64c792786d6f1). (Note: You get the same problem if you create the groups in the web UI.)
Discussion
----------
I bisected to find that the failure originates [with a schema update for civicrm_group](https://github.com/civicrm/civicrm-core/pull/18599/files#diff-9f8f69e770bcc926a5831339a92183bbb70aad496a16dee07beaf9c6ff7b42d9L34). Specifically, the `title` column now has `<required>true</required>`.
The problem shows some environmental variation
| Runtime | Base-branch | Group schema | Outcome |
|----|----|----|----|
| bknix-min (mysql 5.6.47, php 7.1.33) | 5.31 (rc) | `civicrm_group.title` required | Failing |
| bknix-min (mysql 5.6.47, php 7.1.33) | 5.31 (rc) | `civicrm_group.title` not required | Passing |
| bknix-max (mysql 5.7.27, php 7.3.10) | 5.31 (rc) | `civicrm_group.title` required | Passing |
To see the problem, it helps to inspect what happens after creating the first group. Compare the outcome in different environments:
1. __Failing case__
By default, when you create the first `Group`, it throws an exception:
```
INSERT INTO `civicrm_group_en_US` (`name` , `title` , `description` , `is_active` , `visibility` , `group_type` , `parents` , `is_reserved` , `created_id` )
VALUES ('First_tmp' , 'First' , NULL , 1 , 'User and User Admin Only' , '' , '' , 0 , 202 )
-- [nativecode=1423 ** Field of view 'dmastercivi_ssc8b.civicrm_group_en_US' underlying table doesn't have a default value]
```
This is partially because I'm using a dev-build which has `STRICT_TRANS_TABLES`. If I hack `CRM_Core_DAO::init()` to omit `STRICT_TRANS_TABLES`, then appears to be more forgiving. It creates the `Group`:
```
mysql> select id, title_en_US, title_fr_FR from civicrm_group;
+----+---------------------------+---------------------------+
| id | title_en_US | title_fr_FR |
+----+---------------------------+---------------------------+
| 1 | Administrators | Administrators |
| 2 | Newsletter Subscribers | Newsletter Subscribers |
| 3 | Summer Program Volunteers | Summer Program Volunteers |
| 4 | Advisory Board | Advisory Board |
| 5 | Case Resources | Case Resources |
| 6 | First | |
+----+---------------------------+---------------------------+
```
However, the empty value of `title_fr_FR` is a problem. As soon as you create a *second* `Group`, it will violate the uniqueness constraint (`UI_title_fr_FR`).
2. __Passing__
In the two passing cases, the first `Group` is created without a problem:
```
mysql> select id, title_en_US, title_fr_FR from civicrm_group;
+----+---------------------------+---------------------------+
| id | title_en_US | title_fr_FR |
+----+---------------------------+---------------------------+
| 1 | Administrators | Administrators |
| 2 | Newsletter Subscribers | Newsletter Subscribers |
| 3 | Summer Program Volunteers | Summer Program Volunteers |
| 4 | Advisory Board | Advisory Board |
| 5 | Case Resources | Case Resources |
| 6 | First | First |
+----+---------------------------+---------------------------+
```
Note the synchronized title.https://lab.civicrm.org/dev/translation/-/issues/51inheritLocale regression2020-09-26T00:27:07ZbgminheritLocale regressionTo reproduce:
* Tested on Drupal7
* Enable locale/i18n and two languages (ex: English and French)
* Enable language-prefix language detection
* In CiviCRM, enable multilingual, and two languages
Then use the Drupal language switcher to...To reproduce:
* Tested on Drupal7
* Enable locale/i18n and two languages (ex: English and French)
* Enable language-prefix language detection
* In CiviCRM, enable multilingual, and two languages
Then use the Drupal language switcher to change the language.
Result: the language only changes if we flush the CiviCRM cache. This is because the cache-flush removes data from `civicrm_cache`, including some session data.
Bug happens since 5.29, also in 5.30 and master.
cc @haystack @sluc23 @samuelsov (fyi)5.31.0https://lab.civicrm.org/dev/translation/-/issues/40Can't install 5.23 in another language2020-03-25T04:34:05ZDaveDCan't install 5.23 in another language5.23.3 drupal 7
Also affects 5.24
Also reported on Stackexchange for wordpress by two separate people (but it's a bit buried inside another question https://civicrm.stackexchange.com/questions/35014/local-flywheel-wordpress-install-with...5.23.3 drupal 7
Also affects 5.24
Also reported on Stackexchange for wordpress by two separate people (but it's a bit buried inside another question https://civicrm.stackexchange.com/questions/35014/local-flywheel-wordpress-install-with-civicrm)
You get a white screen and the apache error log has a truncated stack trace:
```
PHP Fatal error: Uncaught RuntimeException: Undefined constant: CIVICRM_TEMPLATE_COMPILEDIR in http://example.org/sites/all/modules/civicrm/CRM/Utils/File.php:583
Stack trace:
0 http://example.org/sites/all/modules/civicrm/Civi/Core/Paths.php(65): CRM_Utils_File::baseFilePath()
1 [internal function]: Civi/Core/Paths->Civi/Core/{closure}()
2 http://example.org/sites/all/modules/civicrm/Civi/Core/Paths.php(145): call_user_func(Object(Closure))
3 http://example.org/sites/all/modules/civicrm/Civi/Core/Paths.php(228): Civi/Core/Paths->getVariable('civicrm.private', 'path')
4 http://example.org/sites/all/modules/civicrm/Civi/Core/Paths.php(82): Civi/Core/Paths->getPath('l10n')
5 [internal function]: Civi/Core/Paths->Civi/Core/{closure}()
6 http://example.org/sites/all/modules/civicrm/Civi/Core/Paths.php(145): call_user_func(Object(Closure))
7 [useless since it's truncated] in http://example.org/sites/all/modules/civicrm/CRM/Utils/File.php on line 583, referer: http://example.org/sites/all/modules/civicrm/install/index.php
```5.24.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.0