Translation issueshttps://lab.civicrm.org/dev/translation/-/issues2023-11-18T02:17:26Zhttps://lab.civicrm.org/dev/translation/-/issues/21notice errors turning on multilingual2023-11-18T02:17:26ZJoeMurraynotice errors turning on multilingualdmaster running 5.12rc 2019-02-27, turned on support for multiple languages and got:
![2019-02-27_16-20-45](/uploads/a23e5662c75868489c625b1b3922e913/2019-02-27_16-20-45.png)dmaster running 5.12rc 2019-02-27, turned on support for multiple languages and got:
![2019-02-27_16-20-45](/uploads/a23e5662c75868489c625b1b3922e913/2019-02-27_16-20-45.png)https://lab.civicrm.org/dev/translation/-/issues/52POT Scan: Update for sequentialcreditnotes, eventcart, flexmailer, etc2023-11-09T18:52:41ZtottenPOT Scan: Update for sequentialcreditnotes, eventcart, flexmailer, etcOver the past half-year, there have been a few new folders within the `civicrm-core` file-hierarchy, e.g.
```
setup
ext/sequentialcreditnotes
ext/flexmailer
ext/eventcart
ext/ewaysingle
ext/financialacls
ext/greenwich
ext/afform
ext/sea...Over the past half-year, there have been a few new folders within the `civicrm-core` file-hierarchy, e.g.
```
setup
ext/sequentialcreditnotes
ext/flexmailer
ext/eventcart
ext/ewaysingle
ext/financialacls
ext/greenwich
ext/afform
ext/search
```
The POT scanner should check these folders. Eventually, we're going to notice missing strings. There are mitigating factors - e.g. the corpus of strings isn't huge, and a lot of the strings existed before (either in different core folders or in a standalone extension), so there may be a bit of lag-time between the file-reorg and the appearance of symptoms.
There are currently two distinct localization flows -- iirc:
* The core flow - which splits strings into multiple POT files (`contribute.pot`, `event.pot`, etc), sends those to transifex, gets the PO's back out, and recombines into one MO (`civicrm.mo`). To capture the updated folders in this flow, we'd need to update `create-pot-files.sh`.
* The ext flow - which scans multiple repos, creating one POT per repo, sends those to transifex, gets the PO's back out, and publishes multiple MOs. To capture the updated folders in this flow, we'd need to update `civiextensions-update-transifex.php` and/or `create-pot-files-extensions.sh` and/or the scheduled-job.https://lab.civicrm.org/dev/translation/-/issues/80Recurring contributions: ThankYou page does not translate the membership cont...2023-05-18T23:59:42ZshaneonabikeRecurring contributions: ThankYou page does not translate the membership contribution unitRelated to #32
To reproduce:
* Configure CiviCRM to non-English (ex: French)
* Setup a recurring membership contribution page
* Choose a membership and choose recurring option
Result:
> Cette adhésion sera renouvelée automatiquement ...Related to #32
To reproduce:
* Configure CiviCRM to non-English (ex: French)
* Setup a recurring membership contribution page
* Choose a membership and choose recurring option
Result:
> Cette adhésion sera renouvelée automatiquement tous les year.
(i.e. the frequency unit is not translated)
From the string:
> This membership will be renewed automatically every %1.
Like @mathieu I will ignore for now this string:
> This recurring contribution will be automatically processed every %1 %2s.
(which assumes that all plurals end with an 's', in every language of the world.)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/82Spelling error in Dutch deprecation notice2023-05-04T13:50:48ZJanecSpelling error in Dutch deprecation noticeCurrent: APIv3 is de legacy versie van CiviCRM's API. Hoewel nog ondersteunt, raden wij het gebruik in nieuwe projecten af.
Should be: APIv3 is de legacy versie van CiviCRM's API. Hoewel nog ondersteund, raden wij het gebruik in nieuwe ...Current: APIv3 is de legacy versie van CiviCRM's API. Hoewel nog ondersteunt, raden wij het gebruik in nieuwe projecten af.
Should be: APIv3 is de legacy versie van CiviCRM's API. Hoewel nog ondersteund, raden wij het gebruik in nieuwe projecten af.https://lab.civicrm.org/dev/translation/-/issues/72"Cancel" in registration update should have different translation than "cance...2023-03-14T01:46:02Zthoni56"Cancel" in registration update should have different translation than "cancel" as in "abort operation"When you change status of a registration, especially through the self-service registration update, you can choose between "Transfer" or "Cancel" in English. The Swedish translation of that precis "Cancel" should not be "Avbryt" (meaning ...When you change status of a registration, especially through the self-service registration update, you can choose between "Transfer" or "Cancel" in English. The Swedish translation of that precis "Cancel" should not be "Avbryt" (meaning something like "Abort"), as is the case with most of the other instances. In Swedish, at least, it should be translated to something different, like "Avbokad" (which means "Deregister") as that is used in the rest of the Swedish translation.
This seems to be impossible since the same translation for "Cancel" is used everywhere (correct me if I'm wrong and how to distinguish the two). I don't know if this is a problem with the tools for managing translations as this type of problem has popped up a few times.
I'm one of the main contributors to the Swedish translation.
(Sorry if I posted this issue in the wrong place. Please direct me to the right place and update the instructions on https://civicrm.org/bug-reporting as they say "Click Create New Issue in at the top of the left panel". I don't have that... This makes new Issue Tracker very confusing, disclosing the internal structure of the project.)https://lab.civicrm.org/dev/translation/-/issues/76Add support for extension .mo in [civicrm.l10n]2023-01-28T19:10:09ZbgmAdd support for extension .mo in [civicrm.l10n]#30 added support for translation "mo" files in a custom resource directory (such as `files/civicrm/l10n`). This makes it easier to update files regularly, such as with the l10nupdate extension, which must be able to write to disk.
Howe...#30 added support for translation "mo" files in a custom resource directory (such as `files/civicrm/l10n`). This makes it easier to update files regularly, such as with the l10nupdate extension, which must be able to write to disk.
However currently extensions must still have their "mo" files in their own directory. This causes challenges with the distribution of mo files for core extensions, but it is also annoying for non-core extensions that are available for automatic distribution (i.e. on Transifex).
Proposal: support both, as a transitional measure.
Eventually, I think we should deprecate the old behaviour, and always have a process such as l10nupdate which will fetch translations. That way we can also deprecate `civicrm-l10n-xx.tar.gz`.5.59.0https://lab.civicrm.org/dev/translation/-/issues/78Define `setLocale()` for languages which aren't "all there"2023-01-13T01:04:07ZtottenDefine `setLocale()` for languages which aren't "all there"## The Basic Question
__Q: What to do if someone activates a locale that isn't "all there"?__
To clarify the question:
* "Activate a locale" means "Call `setLocale('xx_XX')`". This could be:
* Click a button in the web UI to set t...## The Basic Question
__Q: What to do if someone activates a locale that isn't "all there"?__
To clarify the question:
* "Activate a locale" means "Call `setLocale('xx_XX')`". This could be:
* Click a button in the web UI to set the language of the screen. (This requires a call to `setLocale(...)`.)
* Send an email or SMS message in another language. The message includes tokens, and tokens can be localized. (This requires a call to `setLocale(...)`.)
* Process an API call in an alternate language (such as "Preview mailing in locale X" / "Render message in locale X"). It may respond with localized data. (This requires a call to `setLocale(...)`.)
* "All there" means that a locale is enabled/defined in all localization layers
* Is marked as active in `civicrm_option_value` (`languages`; ie *communication-preference languages*)
* Is marked as active in `civicrm_setting` (`uiLanguages`; ie *web UI languages*)
* Has `ts()` data (file `l10n/xx_XX/civicrm.mo`)
* (*In multilingual deployments*) Has SQL columns (aka setting `languageLimit`)
* Has currency formatting rules
* ~~Has date formatting rules~~ (*afaik, we don't actually track this on a per-locale basis right now*)
* Is supported by Drupal/Joomla/WordPress
Example: A staff member writes emails (`Mailing` or `MessageTemplate`) in few locales (eg `es_US` and `en_US`). They send email to a user who prefers `es_US`. The email has tokens, which can rely on services like `ts()` and `Civi::format()`. But the system doesn't fully support `es_US` (eg there is no `l10n/es_US/civicrm.mo`). How will the email render? How will the tokens be processed?
## The Basic Answer
__A: Either switch the locale completely -- or mix-in substitutes from other locales.__
Example (*continued*): If you are rendering an email for `es_US` but lack some resources for `es_US`, then you might switch the request to `en_US`, or you might mix-in elements from `es_MX`.
| | Ideal | Complete Switch | Mixed Locales |
|--|--|--|--|
| tsLocale | es_US | en_US | es_MX |
| dbLocale | es_US | en_US | es_MX |
| Currency | es_US | en_US | en_US |
| Dates | es_US | en_US | es_MX |
## When the question matters (broadly)
I imagine that many deployers don't care -- they pick 1 or 2 well-defined locales and do everything in that locale. But it can matter ifeither...
* ...if you define communication-materials (`Mailing`, `MessageTemplate`) in alternate languages
* ...if your primary audience uses a locale that isn't fully supported (`es_US`, `en_NZ`)
## Mixed signals
At a lower level, the existing code has some inconsistent answers:
* When booting Civi, the `applyLocale()` checks several settings (from Civi+CMS) and decides which locale to activate.
* In the Civi API, there's an option (`setLanguage()` / `option.language`) to set the active locale. It only lets you choose locales that are configured for multilingual.
* In localization unit-tests, some tests call `setLocale()` for locales that aren't enabled.
* In the `CRM_Core_I18n::setLocale()`, it allows you pass *anything* (without validation).
At a higher level, I imagine two different attitudes:
* __You should only process requests in locales that are fully supported.__ If a user performs an action in some other locale, then they will inevitably get quirks (eg mail-tokens that render with alien content). Better to make a clean switch to a supported locale rather than to peck at quirks.
* __You should allow any locale with a best-effort/closest-match.__ Even if we don't have all localization resources for all locales, we have lots of pieces that get pretty close, and admins should be allowed to send messages with any locale they choose. Granted, they _could_ send messages with tokens that don't localize properly; it's up to them to write the message and choose suitable tokens.
## Exploratory branch
There is an [exploratory branch (PR 24174)](https://github.com/civicrm/civicrm-core/pull/24174) which currently answers this way:
* The class `Locale` represents the major decisions/data-points for the locale (eg tsLocale, dbLocale, moneyFormatter).
* The function `Locale::negotiate('xx_XX')` is a focal-point -- it takes a preferred a locale (`xx_XX`), examines the settings+resources, and creates a concrete `Locale` descriptor.
* `Locale::negotiate()` is influenced by a new setting, `partial_locales` (on/off). If enabled, then it will mix locales. If disabled, it will only use complete locales.
A couple things in flux:
* The `negotiate()` looks at a bunch of settings and resources. Which ones matter? How should each be used?
* Some tests were written on the assumption that `setLocale()` has no validation. Some of these can be easily [tweaked so as the make the test-scenario more valid](https://github.com/totten/civicrm-core/commit/bc77245f54923453e59d484a60a944eadfc9c3fc). But there are some (like `testUiLanguages()` and `testI18nEventCopy()`) which have relevant edge-cases. Need to change the test or change `negotiate()`.
* Are there callers in contrib (`setLocale('xx_XX')`) which will barf if the values are negotiated?
(*I may have done a similar sort of braindump on MM a couple weeks ago... but I want something to link back to and add comments on...*)5.54.0https://lab.civicrm.org/dev/translation/-/issues/32Recurring contributions: ThankYou page does not translate the contribution unit2022-11-28T16:59:41ZbgmRecurring contributions: ThankYou page does not translate the contribution unitTo reproduce:
* Configure CiviCRM to non-English (ex: French)
* Setup a recurring contribution page
* Contribute a recurring amount (ex: 5$ every month)
Result:
> Cette contribution périodique sera automatiquement prélevée chaque mont...To reproduce:
* Configure CiviCRM to non-English (ex: French)
* Setup a recurring contribution page
* Contribute a recurring amount (ex: 5$ every month)
Result:
> Cette contribution périodique sera automatiquement prélevée chaque month.
(i.e. the frequency unit is not translated)
From the string:
> This recurring contribution will be automatically processed every %1.
I will ignore for now this string:
> This recurring contribution will be automatically processed every %1 %2s.
(which assumes that all plurals end with an 's', in every language of the world.)5.36.0https://lab.civicrm.org/dev/translation/-/issues/20DB Error: no such table when executing schedule jobs2022-11-07T18:05:35ZYepaDB Error: no such table when executing schedule jobsWe'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
If we prepare a mailing with a language different from the language interface, when we execute the schedule jobs, we have the following error:
```
Feb 14 18:17:32 [info] $Fatal Error Details = Array
(
[callback] => Array
(
[0] => CRM_Core_Error
[1] => handle
)
[code] => -18
[message] => DB Error: no such table
[mode] => 16
[debug_info] => select id, extends, extends_entity_column_value, style from civicrm_custom_group__en_US where is_active = 1 [nativecode=1146 ** Table 'drupal.civicrm_custom_group__en_US' doesn't exist]
[type] => DB_Error
[user_info] => select id, extends, extends_entity_column_value, style from civicrm_custom_group__en_US where is_active = 1 [nativecode=1146 ** Table 'drupal.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, extends, extends_entity_column_value, style from civicrm_custom_group__en_US where is_activ$
)
Feb 14 18:17:32 [info] $backTrace = #0 /var/www/drupal/public_html/sites/all/modules/civicrm/CRM/Core/Error.php(232): CRM_Core_Error::backtrace("backTrace", TRUE)
#1 [internal function](): CRM_Core_Error::handle(Object(DB_Error))
#2 /var/www/drupal/public_html/sites/all/modules/civicrm/packages/PEAR.php(921): call_user_func((Array:2), Object(DB_Error))
#3 /var/www/drupal/public_html/sites/all/modules/civicrm/packages/DB.php(985): PEAR_Error->__construct("DB Error: no such table", -18, 16, (Array:2), "select id, extends, extends_entity_column_value, style from civicrm_custom_gr...")
#4 /var/www/drupal/public_html/sites/all/modules/civicrm/packages/PEAR.php(575): DB_Error->__construct(-18, 16, (Array:2), "select id, extends, extends_entity_column_value, style from civicrm_custom_gr...")
#5 [internal function](): PEAR->_raiseError(Object(DB_mysqli), NULL, -18, NULL, NULL, "select id, extends, extends_entity_column_value, style from civicrm_custom_gr...", "DB_Error", TRUE)
#6 /var/www/drupal/public_html/sites/all/modules/civicrm/packages/PEAR.php(224): call_user_func_array((Array:2), (Array:8))
#7 /var/www/drupal/public_html/sites/all/modules/civicrm/packages/DB/common.php(1907): PEAR->__call("raiseError", (Array:7))
#8 /var/www/drupal/public_html/sites/all/modules/civicrm/packages/DB/common.php(1907): PEAR->raiseError(NULL, -18, NULL, NULL, "select id, extends, extends_entity_column_value, style from civicrm_custom_gr...", "DB_Error", TRUE)
#9 /var/www/drupal/public_html/sites/all/modules/civicrm/packages/DB/mysqli.php(933): DB_common->raiseError(-18, NULL, NULL, NULL, "1146 ** Table 'drupal.civicrm_custom_group__en_US' doesn't exist")
#10 /var/www/drupal/public_html/sites/all/modules/civicrm/packages/DB/mysqli.php(403): DB_mysqli->mysqliRaiseError()
#11 /var/www/drupal/public_html/sites/all/modules/civicrm/packages/DB/common.php(1216): DB_mysqli->simpleQuery("select id, extends, extends_entity_column_value, style from civicrm_custom_gr...")
#12 /var/www/drupal/public_html/sites/all/modules/civicrm/packages/DB/DataObject.php(2415): DB_common->query("select id, extends, extends_entity_column_value, style from civicrm_custom_gr...")
#13 /var/www/drupal/public_html/sites/all/modules/civicrm/packages/DB/DataObject.php(1607): DB_DataObject->_query("select id, extends, extends_entity_column_value, style from civicrm_custom_gr...")
#14 /var/www/drupal/public_html/sites/all/modules/civicrm/CRM/Core/DAO.php(438): DB_DataObject->query("select id, extends, extends_entity_column_value, style from civicrm_custom_gr...")
#15 /var/www/drupal/public_html/sites/all/modules/civicrm/CRM/Core/DAO.php(1411): CRM_Core_DAO->query("select id, extends, extends_entity_column_value, style from civicrm_custom_gr...", TRUE)
#16 /var/www/drupal/public_html/sites/all/modules/civicrm/drupal/modules/views/components/civicrm.core.inc(3119): CRM_Core_DAO::executeQuery("select id, extends, extends_entity_column_value, style from civicrm_custom_gr...")
#17 /var/www/drupal/public_html/sites/all/modules/civicrm/drupal/modules/views/civicrm.views.inc(87): _civicrm_core_data((Array:301), (Array:8))
#18 /var/www/drupal/public_html/sites/all/modules/contrib/views/includes/cache.inc(93): civicrm_views_data_alter((Array:301))
#19 /var/www/drupal/public_html/sites/all/modules/contrib/views/includes/cache.inc(37): _views_fetch_data_build()
#20 /var/www/drupal/public_html/sites/all/modules/contrib/views/views.module(1319): _views_fetch_data("twitter", FALSE, FALSE)
#21 /var/www/drupal/public_html/sites/all/modules/contrib/views/views.module(1655): views_fetch_data("twitter", FALSE)
#22 /var/www/drupal/public_html/sites/all/modules/contrib/views/includes/view.inc(277): views_move_table("twitter")
#23 /var/www/drupal/public_html/sites/all/modules/contrib/views/views.module(1643): view->update()
#24 /var/www/drupal/public_html/sites/all/modules/contrib/views/views.module(762): views_get_view("tweets")
#25 [internal function](): views_block_view("tweets-block")
#26 /var/www/drupal/public_html/includes/module.inc(934): call_user_func_array("views_block_view", (Array:1))
#27 /var/www/drupal/public_html/modules/block/block.module(911): module_invoke("views", "block_view", "tweets-block")
#28 /var/www/drupal/public_html/modules/block/block.module(690): _block_render_blocks((Array:1))
#29 /var/www/drupal/public_html/modules/block/block.module(319): block_list("footer3")
#30 /var/www/drupal/public_html/modules/block/block.module(270): block_get_blocks_by_region("footer3")
#31 /var/www/drupal/public_html/includes/common.inc(5914): block_page_build((Array:11))
#32 /var/www/drupal/public_html/includes/common.inc(2761): drupal_render_page("\n<div id=\"crm-container\" class=\"crm-container\" lang=\"en\" xml:lang=\"en...")
#33 /var/www/drupal/public_html/includes/common.inc(2634): drupal_deliver_html_page("\n<div id=\"crm-container\" class=\"crm-container\" lang=\"en\" xml:lang=\"en...")
#34 /var/www/drupal/public_html/includes/menu.inc(542): drupal_deliver_page("\n<div id=\"crm-container\" class=\"crm-container\" lang=\"en\" xml:lang=\"en...", "")
#35 /var/www/drupal/public_html/index.php(21): menu_execute_active_handler()
#36 {main}
```
The global $dbLocale is equal to '__en_US' because it's not correctly set in the public function setLocale($locale) of i18n.php. The $locale is equal to '_en_US' when the fatal error occurred.
```
/**
* Change the processing language without changing the current user language
*
* @param $locale
* Locale (for example 'en_US', or 'fr_CA').
* True if the domain was changed for an extension.
*/
public function setLocale($locale) {
// Change the language of the CMS as well, for URLs.
CRM_Utils_System::setUFLocale($locale);
// change the gettext ressources
if ($this->_nativegettext) {
$this->setNativeGettextLocale($locale);
}
else {
// phpgettext
$this->setPhpGettextLocale($locale);
}
// for sql queries
global $dbLocale;
$dbLocale = "_{$locale}";
}
```
"inherit locale" option is enabled and no cache error.
Here is the backtrace from setLocale function: [locale_not_well_set_error.txt](/uploads/29d6263e244abc1d0973ff4679463615/locale_not_well_set_error.txt)
I tried without sendgrid extension, the error was the same.https://lab.civicrm.org/dev/translation/-/issues/77Translation of message for multiple registrations missing2022-08-19T15:24:12Zthoni56Translation of message for multiple registrations missingIf you allow multiple registrations to an event, and select a number greater than 1 when you register (from the web view) the following string is displayed:
Fill in your registration information on this page. You will be able to ent...If you allow multiple registrations to an event, and select a number greater than 1 when you register (from the web view) the following string is displayed:
Fill in your registration information on this page. You will be able to enter the registration information for additional people after you complete this page and click "Continue".
This string can not be translated in Transifex (since it does not exist). The string there is (probably):
Fill in your registration information on this page. If you are registering additional people, you will be able to enter their registration information after you complete this page and click "Review your registration".
We are running 5.50.4 on Joomla.https://lab.civicrm.org/dev/translation/-/issues/38Unable to add new custom field set or new fields (to existing field set) afte...2022-05-19T14:22:15Zdarren.woodsUnable to add new custom field set or new fields (to existing field set) after enabling multilingual setting.Reproduced on demo site https://dmaster.demo.civicrm.org/ running 5.24.alpha1 and also 5.21.1
1) Settings - Localization - enable Multilingual setting.
2) Custom Data - Add set of custom fields.
3) Enter "Set Name" and select "Used For"...Reproduced on demo site https://dmaster.demo.civicrm.org/ running 5.24.alpha1 and also 5.21.1
1) Settings - Localization - enable Multilingual setting.
2) Custom Data - Add set of custom fields.
3) Enter "Set Name" and select "Used For", click "Save"
**Error returned:-**
Database Error Code: Field of view 'dmastercivi_g5lis.civicrm_custom_group_en_US' underlying table doesn't have a default value, 1423
Additional Details:
`
Array
(
[callback] => Array
(
[0] => CRM_Core_Error
[1] => handle
)
[code] => -1
[message] => DB Error: unknown error
[mode] => 16
[debug_info] => INSERT INTO `civicrm_custom_group_en_US` (`name` , `title` , `extends` , `extends_entity_column_id` , `extends_entity_column_value` , `style` , `collapse_display` , `help_pre` , `help_post` , `weight` , `is_active` , `is_multiple` , `max_multiple` , `created_id` , `created_date` , `is_public` ) VALUES ('test' , 'test' , 'Contact' , NULL , NULL , 'Inline' , 1 , '' , '' , 6 , 1 , 0 , NULL , 203 , 20200305111654 , 1 ) [nativecode=1423 ** Field of view 'dmastercivi_g5lis.civicrm_custom_group_en_US' underlying table doesn't have a default value]
[type] => DB_Error
[user_info] => INSERT INTO `civicrm_custom_group_en_US` (`name` , `title` , `extends` , `extends_entity_column_id` , `extends_entity_column_value` , `style` , `collapse_display` , `help_pre` , `help_post` , `weight` , `is_active` , `is_multiple` , `max_multiple` , `created_id` , `created_date` , `is_public` ) VALUES ('test' , 'test' , 'Contact' , NULL , NULL , 'Inline' , 1 , '' , '' , 6 , 1 , 0 , NULL , 203 , 20200305111654 , 1 ) [nativecode=1423 ** Field of view 'dmastercivi_g5lis.civicrm_custom_group_en_US' underlying table doesn't have a default value]
[to_string] => [db_error: message="DB Error: unknown error" code=-1 mode=callback callback=CRM_Core_Error::handle prefix="" info="INSERT INTO `civicrm_custom_group_en_US` (`name` , `title` , `extends` , `extends_entity_column_id` , `extends_entity_column_value` , `style` , `collapse_display` , `help_pre` , `help_post` , `weight` , `is_active` , `is_multiple` , `max_multiple` , `created_id` , `created_date` , `is_public` ) VALUES ('test' , 'test' , 'Contact' , NULL , NULL , 'Inline' , 1 , '' , '' , 6 , 1 , 0 , NULL , 203 , 20200305111654 , 1 ) [nativecode=1423 ** Field of view 'dmastercivi_g5lis.civicrm_custom_group_en_US' underlying table doesn't have a default value]"]
)
`
Also unable to add new fields to existing sets.
1) Open exiting field set
2) Click "Add custom field"
3) Enter Label
4) Click "Save"
Error details:-
Database Error Code: Field of view 'dmastercivi_g5lis.civicrm_custom_field_en_US' underlying table doesn't have a default value, 1423
Additional Details:
`Array
(
[callback] => Array
(
[0] => CRM_Core_Error
[1] => handle
)
[code] => -1
[message] => DB Error: unknown error
[mode] => 16
[debug_info] => INSERT INTO `civicrm_custom_field_en_US` (`custom_group_id` , `name` , `label` , `data_type` , `html_type` , `default_value` , `is_required` , `is_searchable` , `is_search_range` , `weight` , `help_pre` , `help_post` , `is_active` , `is_view` , `options_per_line` , `text_length` , `start_date_years` , `end_date_years` , `date_format` , `time_format` , `note_columns` , `note_rows` , `column_name` , `option_group_id` , `filter` , `in_selector` ) VALUES ( 7 , 'test' , 'test' , 'String' , 'Text' , NULL , NULL , NULL , 0 , 2 , NULL , NULL , 1 , NULL , NULL , 255 , NULL , NULL , NULL , NULL , 60 , 4 , 'test' , NULL , NULL , 0 ) [nativecode=1423 ** Field of view 'dmastercivi_g5lis.civicrm_custom_field_en_US' underlying table doesn't have a default value]
[type] => DB_Error
[user_info] => INSERT INTO `civicrm_custom_field_en_US` (`custom_group_id` , `name` , `label` , `data_type` , `html_type` , `default_value` , `is_required` , `is_searchable` , `is_search_range` , `weight` , `help_pre` , `help_post` , `is_active` , `is_view` , `options_per_line` , `text_length` , `start_date_years` , `end_date_years` , `date_format` , `time_format` , `note_columns` , `note_rows` , `column_name` , `option_group_id` , `filter` , `in_selector` ) VALUES ( 7 , 'test' , 'test' , 'String' , 'Text' , NULL , NULL , NULL , 0 , 2 , NULL , NULL , 1 , NULL , NULL , 255 , NULL , NULL , NULL , NULL , 60 , 4 , 'test' , NULL , NULL , 0 ) [nativecode=1423 ** Field of view 'dmastercivi_g5lis.civicrm_custom_field_en_US' underlying table doesn't have a default value]
[to_string] => [db_error: message="DB Error: unknown error" code=-1 mode=callback callback=CRM_Core_Error::handle prefix="" info="INSERT INTO `civicrm_custom_field_en_US` (`custom_group_id` , `name` , `label` , `data_type` , `html_type` , `default_value` , `is_required` , `is_searchable` , `is_search_range` , `weight` , `help_pre` , `help_post` , `is_active` , `is_view` , `options_per_line` , `text_length` , `start_date_years` , `end_date_years` , `date_format` , `time_format` , `note_columns` , `note_rows` , `column_name` , `option_group_id` , `filter` , `in_selector` ) VALUES ( 7 , 'test' , 'test' , 'String' , 'Text' , NULL , NULL , NULL , 0 , 2 , NULL , NULL , 1 , NULL , NULL , 255 , NULL , NULL , NULL , NULL , 60 , 4 , 'test' , NULL , NULL , 0 ) [nativecode=1423 ** Field of view 'dmastercivi_g5lis.civicrm_custom_field_en_US' underlying table doesn't have a default value]"]
)`5.47.0https://lab.civicrm.org/dev/translation/-/issues/30Allow setting a custom L10n/I18n resource directory2022-05-11T15:17:53ZhomotechsualAllow setting a custom L10n/I18n resource directoryCiviCRM Core contains some code which gets the resource directory for i18n files - at the moment this is set as a "static variable" within the [function here](https://github.com/civicrm/civicrm-core/blob/042ca9cb6f9a50aacf057f384d1733ee9...CiviCRM Core contains some code which gets the resource directory for i18n files - at the moment this is set as a "static variable" within the [function here](https://github.com/civicrm/civicrm-core/blob/042ca9cb6f9a50aacf057f384d1733ee9d9e906e/CRM/Core/I18n.php#L300).
It would be beneficial if we could set this properly to a directory of our choosing and would allow proper I18n support on Drupal 8 without having to place the L10n folder inside `/vendor/civicrm/civicrm-core` which complicates composer updates, completely breaks with composer best practices and adds an additional manual step to get going with CiviCRM and Drupal 8.
Allowing a custom setting for this would also allow us to set a sane default ([civicrm.files]/l10n)? which we can then use to "composerify" the inclusion of the L10n tarball (e.g: https://github.com/drupal-composer/drupal-l10n)5.23.0https://lab.civicrm.org/dev/translation/-/issues/73Missing translation of recur_frequency_units2022-02-17T03:46:27ZmasettoMissing translation of recur_frequency_unitssee row 789 of `CRM/Contribute/Form/Contribution/Main.php`:
```
$unit .= "(s)";
$form->assign('frequency_unit', $unit);
```
It uses `value` of `recur_frequency_units` and not its label.
I think you could translate it at row 150 of t...see row 789 of `CRM/Contribute/Form/Contribution/Main.php`:
```
$unit .= "(s)";
$form->assign('frequency_unit', $unit);
```
It uses `value` of `recur_frequency_units` and not its label.
I think you could translate it at row 150 of templates/CRM/Contribute/Form/Contribution/Main.tpl
```
{if $one_frequency_unit}
{ts}{$form.frequency_interval.label}{/ts}
{else}
{ts}{$form.frequency_unit.html}{/ts}
{/if}
```
What do you think?https://lab.civicrm.org/dev/translation/-/issues/10Missing downloadable file translation for CiviSEPA extension (and others?)2022-02-14T16:59:05ZfrancescbassasMissing downloadable file translation for CiviSEPA extension (and others?)I'm not able to find the file translation for CiviSEPA extension, I'm trying to download from https://download.civicrm.org/civicrm-l10n-extensions/mo/sepa/es_ES/sepa.mo without success. I'm missing something? CiviSepa has a Transifex pro...I'm not able to find the file translation for CiviSEPA extension, I'm trying to download from https://download.civicrm.org/civicrm-l10n-extensions/mo/sepa/es_ES/sepa.mo without success. I'm missing something? CiviSepa has a Transifex project but seems that .mo files aren't being generated at https://test.civicrm.org/view/i18n/job/CiviCRM-l10n-mo-build/gcsObjects/.https://lab.civicrm.org/dev/translation/-/issues/71Full Month Names: avoid relying on the operating system's locale for translation2021-09-07T14:23:31ZbgmFull Month Names: avoid relying on the operating system's locale for translationThis kind of question comes up from time to time:
https://civicrm.stackexchange.com/questions/35468/date-in-english-even-when-page-is-set-to-french/40170
> "The date is always uses English month and day names regardless of the interfa...This kind of question comes up from time to time:
https://civicrm.stackexchange.com/questions/35468/date-in-english-even-when-page-is-set-to-french/40170
> "The date is always uses English month and day names regardless of the interface language. How do I fix this?"
The main issue is because currently translating the month name relies on the operating system. The non-English locale must be enabled so that `strftime` outputs the correct month name (ex: "janvier" not "January").
Most people somewhat control their hosting environment, and can enable it once they know how, but since the default CiviCRM date format uses `%B` (full month name), it gives a bad first impression. Considering we already have those strings in Transifex, it would be easy to just hardcode the list of months and translate using 'ts'.5.43.0bgmbgmhttps://lab.civicrm.org/dev/translation/-/issues/70Multi-lingual: Contact Type label is cached regarless of language2021-08-28T04:51:08ZbgmMulti-lingual: Contact Type label is cached regarless of languageTo reproduce:
* Enable multi-lingual
* Add a second language
* View a contact record, switch to the other language, then view the contact record again.
Note that the "Contact Type" will always be the same in both languages.
![contactt...To reproduce:
* Enable multi-lingual
* Add a second language
* View a contact record, switch to the other language, then view the contact record again.
Note that the "Contact Type" will always be the same in both languages.
![contacttype-2021-08-12_15-29](/uploads/d72800debe08abdc071edfd036113a88/contacttype-2021-08-12_15-29.png)
The root of the bug is in `CRM/Contact/Page/View/Summary.php` `getAllContactTypes`, the cache does not take language into account:
```
protected static function getAllContactTypes() {
if (!Civi::cache('contactTypes')->has('all')) {
$contactTypes = (array) ContactType::get(FALSE)
->setSelect(['id', 'name', 'label', 'description', 'is_active', 'is_reserved', 'image_URL', 'parent_id', 'parent_id:name', 'parent_id:label'])
->execute()->indexBy('name');
```
@eileen Would it make sense to add the language to `has('all')`? I'm not too familiar with the cache service, and suspect there will be similar issues in other places.5.42.0https://lab.civicrm.org/dev/translation/-/issues/45Correct line breaks in settings.default.json2021-08-12T19:21:29ZgernerCorrect line breaks in settings.default.jsonThe [example file of settings.default.json](https://lab.civicrm.org/dev/translation/-/blob/master/settings/fr_CA/settings.default.json) has some line breaks, so it breaks the JSON validation, i.e. https://jsonlint.com/, and as a conseque...The [example file of settings.default.json](https://lab.civicrm.org/dev/translation/-/blob/master/settings/fr_CA/settings.default.json) has some line breaks, so it breaks the JSON validation, i.e. https://jsonlint.com/, and as a consequence, the settings.default.json file is not read during CiviCRM install, without any warning or error message.
Correcting the line breaks by adding `\n` where required corrects the issue, see /copy_metadata <!4t>https://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/65Remove legacy php money_format use, switch to brickmoney2021-06-07T01:42:08ZeileenRemove legacy php money_format use, switch to brickmoneyPhp 7.4 deprecated the money_format function and we need to move off it to fully support php 7.4 (which we are priortising now). We chose brickmoney as the replacement library.
The main usage is in the CRM_Utils_Money::format() library ...Php 7.4 deprecated the money_format function and we need to move off it to fully support php 7.4 (which we are priortising now). We chose brickmoney as the replacement library.
The main usage is in the CRM_Utils_Money::format() library - this function has a lot of alternate functions depending on input params and we have been working to use more specific functions
I think in the end the main format function would support 3 parameters
- amount (as a float or number)
- currency (as a string)
- use site separators (bool)
The first 2 are pretty straight forward. The latter is the idea that if you are looking at a table of donations you want consistent thousand & decimal separators, currency independent. But if you are presenting data front end you want the selection of Norwegian Kroner to also trigger a switch to appropriate formatting on the page
Some discrete steps we can take are
1) instead of calling the function with the only number param call the inner function directly
```
if ($onlyNumber) {
$amount = self::formatLocaleNumericRoundedByCurrency($amount, $currency);
return $amount;
}
```
2) do the same for calls that pass $format = '%a' - which has the same impact. (if currency is unknown formatLocaleNumericRoundedByPrecision is an option)
3) fully remove / hard-code the deprecated $moneyValueFormat setting and parameter
```
if (CRM_Core_Config::singleton()->moneyvalueformat !== '%!i') {
CRM_Core_Error::deprecatedWarning('Having a Money Value format other than !%i is deprecated, please report this on GitLab with the relevant moneyValueFormat you use.');
}
```
4) actually replace the call to money_format.....Monish DebMonish Deb