Translation issueshttps://lab.civicrm.org/dev/translation/-/issues2018-10-24T20:56:28Zhttps://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/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/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/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/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/64Using %1%2 in ts() generates confusing output in transifex2021-01-27T21:50:26ZDaveDUsing %1%2 in ts() generates confusing output in transifexhttps://chat.civicrm.org/civicrm/pl/xs88zzbksjn53jyhnprzmaacte
There might be some legitimate uses for such a construct, but it seems like you could always replace:
`ts('Thing to translate with %1%2 as params', array(1 => $foo, 2 => $b...https://chat.civicrm.org/civicrm/pl/xs88zzbksjn53jyhnprzmaacte
There might be some legitimate uses for such a construct, but it seems like you could always replace:
`ts('Thing to translate with %1%2 as params', array(1 => $foo, 2 => $bar))`
with
`ts('Thing to translate with %1 as params', array(1 => $foo . $bar))`
In transifex it looks something like:
![3826](/uploads/8e4cf2c9cdbf987b9308919de08c5865/3826.gif)5.35.0https://lab.civicrm.org/dev/translation/-/issues/54Component Titles are not translated on the Configuration Checklist page2020-10-07T20:02:49ZseamusleeComponent Titles are not translated on the Configuration Checklist pageThe list of component titles down the bottom e.g. CiviContribute etc are not translated at the bottom of this screenThe list of component titles down the bottom e.g. CiviContribute etc are not translated at the bottom of this screen5.31.0seamusleeseamusleehttps://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/48Investigate php currency library ( chose brickmoney)2021-03-24T01:03:08ZeileenInvestigate php currency library ( chose brickmoney)We have a lot of money handling in our code. Our functions are a bit meh. We still seem to hit issues on money calculations that there are libraries to handle....
There seem to be 2 leading contenders
https://github.com/moneyphp/money
a...We have a lot of money handling in our code. Our functions are a bit meh. We still seem to hit issues on money calculations that there are libraries to handle....
There seem to be 2 leading contenders
https://github.com/moneyphp/money
and https://github.com/brick/money (the latter seems slightly nicer based on the docs)
Both seem to rely on php intl extension for formatting currencies - is that a blocker? or is it common, esp on non US sites.
See https://lab.civicrm.org/dev/translation/-/issues/47 for js issue on the same5.34.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/39Installing CiviCRM in another language, with civicrm-setup2020-05-26T00:28:31ZbgmInstalling CiviCRM in another language, with civicrm-setupI have perhaps a bit of a less-common setup, with Aegir, and running into the following situation when installing CiviCRM on Drupal8 with the 'new' civicrm-setup installer:
At first, the installer failed because of:
```
Error: Call to ...I have perhaps a bit of a less-common setup, with Aegir, and running into the following situation when installing CiviCRM on Drupal8 with the 'new' civicrm-setup installer:
At first, the installer failed because of:
```
Error: Call to a member function getPath() on null in CRM_Core_I18n::getResourceDir()
(line 301 of [...]/vendor/civicrm/civicrm-core/CRM/Core/I18n.php
```
So I patched with the following in `civicrm-setup/plugins/installDatabase/InstallSchema.civi-setup.php`:
```
elseif ($seedLanguage) {
global $tsLocale;
$tsLocale = $seedLanguage;
// Added this:
require_once $model->settingsPath;
\Civi\Core\Container::boot(FALSE);
```
but now I'm getting:
```
Exception: No domain in DB
```
since `Civi/Core/Paths.php` initializes CRM_Core_Config::singleton(), which checks for a domain.
trace:
```
civicrm-core/CRM/Core/Config.php line 115
civicrm-core/Civi/Core/Paths.php line 36
civicrm-core/Civi/Core/Paths.php line 145
civicrm-core/Civi/Core/Paths.php line 189
civicrm-core/Civi/Core/Paths.php line 84
civicrm-core/Civi/Core/Paths.php line 145
civicrm-core/Civi/Core/Paths.php line 189
civicrm-core/CRM/Core/I18n.php line 301
```
i.e. it ends up running:
```
->register('civicrm.root', function () {
return \CRM_Core_Config::singleton()->userSystem->getCiviSourceStorage();
})
```
which brings me to a bit of a catch-22, because `civicrm_domain` gets populated by `sql/civicrm_data.fr_CA.mysql`.
I feel like this is a regression caused by the new-ish `[civicrm.l10n]` variable.
If I patch `CRM/Core/I18n.php` to return a hardcoded l10n resourceDir, the installer runs fine.5.27.0https://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/37Ancient switch statement that provides hardcoded translation doesn't do anyth...2020-02-24T16:28:47ZDaveDAncient switch statement that provides hardcoded translation doesn't do anything anymore@bgm FYI since you might find this academically interesting since it's like "Translation Archaeology".
These lines do nothing: https://github.com/civicrm/civicrm-core/blob/5.22.1/CRM/Activity/Selector/Activity.php#L397-L420
Except for ...@bgm FYI since you might find this academically interesting since it's like "Translation Archaeology".
These lines do nothing: https://github.com/civicrm/civicrm-core/blob/5.22.1/CRM/Activity/Selector/Activity.php#L397-L420
Except for a code-format whitespace change, these lines are unchanged from when they were added 13 years ago and predates the concept of option value labels and was likely added when translation capability was first being added. The comment even still says "DRAFTING".
In particular note that $row['activity_type'] here is the `LABEL` for the option value. **So this switch() doesn't do anything.** Here's a table:
| Scenario | Effect of the switch() |
|------------------------------------------------------------------------------------------------------------------------------------------|---------------------------------------------------------------------------------------------------------------------------------------------------------------|
| US English | Does nothing |
| UK English, labels and names are the same | Does nothing |
| UK English, labels and names are different | Almost never does anything (see next scenario) |
| UK English, but for example the label for activity type Meeting has been changed to Email. I don't know why anyone would do that though. | It would translate Email to Email since it's english, so still does nothing. |
| Non-english, and the label is non-english. | Does nothing |
| Non-english, but you've for some reason changed the label for e.g. Email back to english. But why would you do that? | It will translate it, but in this situation that's a bug because you changed the label to english on purpose because you wanted english, for whatever reason. |
Extra
-----
What's also interesting but is a separate TODO that I'm not going to look closer at right now: I'm not 100% sure when this code even runs. You can trigger it by visiting manage case if the client has some non-case activities, but I don't know why it's even retrieving those non-case activities when you're looking at manage case. And the function is NOT called when looking at a contact's activity tab. It does NOT run when showing results for an activity search.
For manage case it's called from Case_Page_Tab which calls Core_Select_Controller(output = SESSION).
Note that getRows isn't returning any case activities, just the non-case ones. The actual rows you see on manage case come from CRM/Case/Form/ActivityTab.tpl via ajax call to civicrm/ajax/activity, which is CRM_Activity_Page_AJAX::getCaseActivity()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/35Getting Started dashlet does not cache per language2020-03-10T19:36:41ZbgmGetting Started dashlet does not cache per languageTo reproduce:
* Go to Localization Settings: https://dmaster.demo.civicrm.org/civicrm/admin/setting/localization?reset=1
* Under "Available languages", add "French (France)"
* Switch languages: https://dmaster.demo.civicrm.org/civicrm?r...To reproduce:
* Go to Localization Settings: https://dmaster.demo.civicrm.org/civicrm/admin/setting/localization?reset=1
* Under "Available languages", add "French (France)"
* Switch languages: https://dmaster.demo.civicrm.org/civicrm?reset=1&lcMessages=fr_FR
* Click "configurer votre tableau de bord" (configure dashboard)
* Add "CiviCRM Resources"
Now notice that the dashlet is available in French.
However, go back to English and refresh the dashboard data, and it will still be in English:
* To switch back: https://dmaster.demo.civicrm.org/civicrm?reset=1&lcMessages=en_US
![Capture_d_écran_de_2020-01-22_17-27-39](/uploads/4a3a40a74edf4741683c55f88973f086/Capture_d_écran_de_2020-01-22_17-27-39.png)
Small print:
* This depends on first fixing the 'evalUrl' function to use the correct tsLocale.5.23.0https://lab.civicrm.org/dev/translation/-/issues/34Incorrect Contact Reference option for Postal Code in civicrm_data.sql2020-04-16T12:04:50ZHanVIncorrect Contact Reference option for Postal Code in civicrm_data.sqlCopy-error in the sql-file civicrm_data for new databases :
In line (5178): (@option_group_id_acConRef, 'Postal Code' , 8, 'country'
The name for this contact_reference_options (in the table option_values) is 'country', but I...Copy-error in the sql-file civicrm_data for new databases :
In line (5178): (@option_group_id_acConRef, 'Postal Code' , 8, 'country'
The name for this contact_reference_options (in the table option_values) is 'country', but I think it must be 'postal_code'.5.23.0https://lab.civicrm.org/dev/translation/-/issues/33Errors in link ReCaptcha and Extension Directory2020-01-26T18:48:06ZHanVErrors in link ReCaptcha and Extension DirectoryAfter registrating this on stackexchange, I got the comment that I must registrated this here:
In version 5.20.0 there are errors in links.
Administer > System Settings > Misc, the first link reCaptcha is with additional quotes around ...After registrating this on stackexchange, I got the comment that I must registrated this here:
In version 5.20.0 there are errors in links.
Administer > System Settings > Misc, the first link reCaptcha is with additional quotes around target. The link is working but opened in the same tab.
Administer > System Settings > Payment Processors, in the Payment Processors Help, the link one for Extension Directory is wrong. The same error for the help WYSIWYG Editor when : Display Preferences.5.23.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/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.0