Translation issueshttps://lab.civicrm.org/dev/translation/-/issues2020-01-16T18:27:24Zhttps://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/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/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/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/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/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/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/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/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/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/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/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/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/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/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?