Translation issueshttps://lab.civicrm.org/dev/translation/-/issues2021-07-27T13:36:29Zhttps://lab.civicrm.org/dev/translation/-/issues/69"On behalf of" and "in honor of" labels disappear when multilingual is enabled2021-07-27T13:36:29ZJonGold"On behalf of" and "in honor of" labels disappear when multilingual is enabledThis is related to #27 but is a separate issue. To replicate:
* Create a contribution page that allows giving on behalf of an organization.
* Load the contribution page, note the label on the new checkbox.
* Enable multilingual support....This is related to #27 but is a separate issue. To replicate:
* Create a contribution page that allows giving on behalf of an organization.
* Load the contribution page, note the label on the new checkbox.
* Enable multilingual support.
* Reload the contribution page. Note that the label is missing.
This is inconsistent with other l10n behavior, where the default language is the fallback. I propose that the behavior match on these fields.5.41.0JonGoldJonGoldhttps://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/56Membership Types are accidentally translated on Find Membership2023-05-18T23:33:29ZbgmMembership Types are accidentally translated on Find Membership* Switch the locale to French
* Create a Membership Type called "Premium"
* Go to Find Membership screen
Result: "Premium" is displayed as "Cadeau" instead of the intended label.
cc @alainb* Switch the locale to French
* Create a Membership Type called "Premium"
* Go to Find Membership screen
Result: "Premium" is displayed as "Cadeau" instead of the intended label.
cc @alainbhttps://lab.civicrm.org/dev/translation/-/issues/43Ticket to collect steps needed when adding a new language2020-10-22T14:36:09ZDaveDTicket to collect steps needed when adding a new languageSorry if this is already documented somewhere. I found [this page](https://lab.civicrm.org/dev/translation/-/wikis/New-official-language) but it's about policies not procedures.
As I learned recently, when a new language is added to civ...Sorry if this is already documented somewhere. I found [this page](https://lab.civicrm.org/dev/translation/-/wikis/New-official-language) but it's about policies not procedures.
As I learned recently, when a new language is added to civicrm-core:master, future PR's against the RC or current release will fail test runs in a confusingly unrelated way. So at least at the moment one of the non-obvious steps is that the language needs to be backported. (UPDATE: not strictly needed now as of 2020-04-08.)
So while it's fresh in my head trying to gather the steps.
ref: https://lab.civicrm.org/dev/translation/-/issues/4
* Create the new translation of CiviCRM in transifex.
* If a language variant, sync it from another variant (jenkins script).
* Update [conf/distributed_languages.txt](https://lab.civicrm.org/dev/translation/-/blob/master/conf/distributed_languages.txt).
* Wait until the language appears in the daily l10n tarball.
* Update [xml/templates/languages.tpl](https://github.com/civicrm/civicrm-core/blob/master/xml/templates/languages.tpl), and then run bin/regen.sh which will update
* install/langs.php
* sql/civicrm_generated.mysql
* Make a core PR against master including those three files, and an upgrade script to add the option value.
* ~~Backport the PR to the RC and current (maybe - pending https://github.com/civicrm/civicrm-core/pull/17021).~~ 17021 was merged so it's not strictly necessary - lang will show as the code, e.g `(nl_BE)`, and is technically usable, until master becomes current.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/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.0