Translation issueshttps://lab.civicrm.org/dev/translation/-/issues2020-09-26T00:27:07Zhttps://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.0https://lab.civicrm.org/dev/translation/-/issues/85Some strings in core afforms do not translate2024-03-25T18:55:32ZbgmSome strings in core afforms do not translateFor example:
- Enable CiviCampaign
- Go to the CiviCampaign dashboard
![image](/uploads/49a1d30b027b36f57971cbc4fb9d48ff/image.png)
For the tabs, the strings are correctly wrapped with `ts`, and I double-checked that the strings are t...For example:
- Enable CiviCampaign
- Go to the CiviCampaign dashboard
![image](/uploads/49a1d30b027b36f57971cbc4fb9d48ff/image.png)
For the tabs, the strings are correctly wrapped with `ts`, and I double-checked that the strings are translated in my translation file.
For the placeholders on the filter fields, the strings are not correctly wrapped in `ts`, but even if I do wrap them, and I make sure to add the strings to my translation files, they do not translate.
cc @colemanwhttps://lab.civicrm.org/dev/translation/-/issues/84`testLocalizedData()` failing after recent strings update2024-03-29T02:04:10Ztotten`testLocalizedData()` failing after recent strings updateIn CI, the test `testLocalizedData()` has started failing consistently. I've done some hunting and may have an explanation (*but don't know the next step*).
__The Test__: `testLocalizedData()` generates the SQL data-set in two locales. ...In CI, the test `testLocalizedData()` has started failing consistently. I've done some hunting and may have an explanation (*but don't know the next step*).
__The Test__: `testLocalizedData()` generates the SQL data-set in two locales. It spot-checks the data for a common string that should usually be translated. Specifically, `New Organization` is a link in the default menu. It's translated as `Neue Organisation` (`de_DE`) or `Nouvelle organisation` (`fr_FR`).
__Compare__: The test passes on my laptop but not in CI. My laptop has older translation data than the server.
You can manually inspect by running a small script and grepping the output (`cv scr printsql.php | grep Neue`):
```php
function _getSqlLive($locale) {
$schema = new \CRM_Core_CodeGen_Schema(\Civi\Test::codeGen());
$files = $schema->generateLocaleDataSql($locale);
foreach ($files as $file => $content) {
if (preg_match(';^civicrm_data\.;', $file)) {
return $content;
}
}
throw new \Exception("Failed to generate $locale");
}
echo _getSqlLive('de_DE');
```
Both outputs include some translated strings, but the newer doesn't have as many:
```diff
---Local machine, old data
+++Server machine, new data
("Individual,Contact",NULL,"4","0","1","new_individual","Neue Person"),
-("Organization,Contact",NULL,"5","0","1","new_organization","Neue Organisation"),
-("Household,Contact",NULL,"6","0","1","new_household","Neuer Haushalt"),
+("Organization,Contact",NULL,"5","0","1","new_organization","New Organization"),
+("Household,Contact",NULL,"6","0","1","new_household","New Household"),
```
If I inspect the data (`msgunfmt civicrm.mo -o civicrm.po`), I find these in the old data-set:
```
msgid "New Individual"
msgstr "Neue Person"
msgid "New Organization"
msgstr "Neue Organisation"
msgctxt "menu"
msgid "New Individual"
msgstr "Neue Person"
msgctxt "menu"
msgid "New Organization"
msgstr "Neue Organisation"
```
And these in the new data-set:
```
msgid "New Individual"
msgstr "Neue Person"
msgctxt "menu"
msgid "New Individual"
msgstr "Neue Person"
msgctxt "menu"
msgid "New Organization"
msgstr "Neue Organisation"
```
So it's missing `New Organization` in the default context. Additionally, the phrases `Phone Call` and `Meeting` appear in the old data-set but not the new data-set. I see similar omissions in `fr_FR`.
I assume that the SQL translation is evaluating everything in the default context. (It doesn't seem to use the `menu` translations). I don't know if that's good or bad. But regardless, it's probably bad that `Phone Call` and `Meeting` are missing.
In the CI logs for `testTranslatedData()`, the failure starts on roughly Feb 4. (Some places seem to start Feb 5 -- l10n data is cached for a bit.) I'm guessing this is related the new strings released around Feb 4 (https://chat.civicrm.org/civicrm/pl/jyqia56a47dp5dnrouiabnmnuw).
(ping @bgm)https://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.