Translation issueshttps://lab.civicrm.org/dev/translation/-/issues2022-11-25T16:01:21Zhttps://lab.civicrm.org/dev/translation/-/issues/41Invoice for recurring contribution should be sent in the preferred language o...2022-11-25T16:01:21ZbgmInvoice for recurring contribution should be sent in the preferred language of the contactThe contact record has a "preferred language" field, which can be automatically set when people fill in Contribution or Event forms.
That field can be used in certain circumstances, such as in Mailings and in Scheduled Reminders.
Howev...The contact record has a "preferred language" field, which can be automatically set when people fill in Contribution or Event forms.
That field can be used in certain circumstances, such as in Mailings and in Scheduled Reminders.
However, it is not used in the following circumstances:
* In Administration > CiviContribute > Component settings, enable "tax and invoicing", and enable PDF invoices.
* In Administration > Localization > Languages, enable multilingual, and enable a second locale.
* Setup a form that supports recurring contributions, enable email receipts
* As an anonymous user, donate on that form in the second language (not the default global language), selecting a recurring (ex: daily) donation.
Double-check that the contact record that was created has the second-language. Change if it necessary (I forget where the setting is, for defining the pref. language).
Then, as time passes, notice that the recurring email receipts are in the default site language. This is because the cron or IPNs will usually run in the default site language.
`CRM_Core_BAO_ActionSchedule::setCommunicationLanguage()` would be a good implementation reference. We should probably move it to `CRM_Core_I18n` for clarity.https://lab.civicrm.org/dev/translation/-/issues/31civicrm_mailing_component name is limited to 64 charaters, missing label2020-05-18T00:29:46Zbgmcivicrm_mailing_component name is limited to 64 charaters, missing labelThe `civicrm_mailing_component` has a `name` column limited to varchar(64). This name column is exposed to users, and extracted for translation.
However, in some languages the translation for some of the strings, such as "resubscribe me...The `civicrm_mailing_component` has a `name` column limited to varchar(64). This name column is exposed to users, and extracted for translation.
However, in some languages the translation for some of the strings, such as "resubscribe message" can be over 64 characters, causing the CiviCRM installer to fail.https://lab.civicrm.org/dev/translation/-/issues/27Translation option missing for "on behalf of label"2021-06-02T18:01:34ZMartinTranslation option missing for "on behalf of label"I might be misunderstanding how this is supposed to work, but here's the situation that I'm seeing. I have multilingual for civi turned on, and have a contribution page. For the text/longtext fields there is a translation icon next to th...I might be misunderstanding how this is supposed to work, but here's the situation that I'm seeing. I have multilingual for civi turned on, and have a contribution page. For the text/longtext fields there is a translation icon next to the field label in the admin when configuring the page. But when I enable the "allow on behalf of" option, the "on behalf of label" does not have this translation option showing (see screenshot). So it seems that we're not able to provide the right text to the end user in this case.
In addition, when displaying the translated page the following Drupal error shows:
> Notice: Undefined index: for_organization in CRM_Contribute_Form_ContributionBase->buildComponentForm() (line 976 of /home/mysite/public_html/sites/all/modules/civicrm/CRM/Contribute/Form/ContributionBase.php).
Running civicrm 5.12.4 on drupal 7.66 with php 5.6 (I know, I know). Issue was also seen previously on civi 4.7.31.
[civi_trans_issue_1](/uploads/a300619c6ab7cbcabb43e521f7bd46ed/civi_trans_issue_1.jpg)https://lab.civicrm.org/dev/translation/-/issues/25Unselecting from 'Available languages' doesn't drop respective locale views f...2021-08-12T19:25:28ZMonish DebUnselecting from 'Available languages' doesn't drop respective locale views from DBSteps to replicate the issue:
1. Add more than one language from 'Add Language' list say English and French(Canada)
2. Then change civi instance to multilingual
3. DB creates views with locale suffix en_US and fr_CA
4. Now unselect Frenc...Steps to replicate the issue:
1. Add more than one language from 'Add Language' list say English and French(Canada)
2. Then change civi instance to multilingual
3. DB creates views with locale suffix en_US and fr_CA
4. Now unselect French(Canada) and save
Bug: This doesn't drop the fr_CA views from DB as it is not required.https://lab.civicrm.org/dev/translation/-/issues/24On New Event, allow translations to be entered before first save2019-03-08T17:14:15ZJoeMurrayOn New Event, allow translations to be entered before first saveCurrently, on multilingual sites, it is only possible to enter text for the current language on the first form presented for Events > New Event (civicrm/event/add?reset=1&action=add). After that form is saved, translations can be entered...Currently, on multilingual sites, it is only possible to enter text for the current language on the first form presented for Events > New Event (civicrm/event/add?reset=1&action=add). After that form is saved, translations can be entered for any translatable field on any tab.
Proposed enhancement: allow translations to be entered for the text fields on the first form as well, prior to first save.
This enhancement idea is currently unfunded.https://lab.civicrm.org/dev/translation/-/issues/23Angular asset cache and multi-lingual2024-01-29T10:06:18ZbgmAngular asset cache and multi-lingualAngular extensions, such as CiviMail (classic) or Mosaico, will not always be displayed in the correct language when the Angular asset cache is enabled/auto (Admin > System Settings > Debugging). Tested on Drupal 7 (in case that makes a ...Angular extensions, such as CiviMail (classic) or Mosaico, will not always be displayed in the correct language when the Angular asset cache is enabled/auto (Admin > System Settings > Debugging). Tested on Drupal 7 (in case that makes a different with the "auto" setting of that cache).
How to reproduce on dmaster:
* Make sure you have the civicrm-l10n.tar.gz translation files (it's the case on dmaster.demo.civicrm.org)
* Go to Administer > Localisation, and enable another language, such as French (you don't need to enable multi-lingual).
* Use the CiviCRM Language Switch to set the language to French
* Go to Mailing > New Mailing (classic or mosaico, same bug)
* Now go back to the dashboard, set the language to English
* Go to Mailing > New Mailing, and notice that the UI is still in French.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/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/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/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.txt