Translation issueshttps://lab.civicrm.org/dev/translation/-/issues2024-03-25T18:55:32Zhttps://lab.civicrm.org/dev/translation/-/issues/85Some strings in core afforms do not translate2024-03-25T18:55:32ZbgmSome strings in core afforms do not translateFor example:
- Enable CiviCampaign
- Go to the CiviCampaign dashboard
![image](/uploads/49a1d30b027b36f57971cbc4fb9d48ff/image.png)
For the tabs, the strings are correctly wrapped with `ts`, and I double-checked that the strings are t...For example:
- Enable CiviCampaign
- Go to the CiviCampaign dashboard
![image](/uploads/49a1d30b027b36f57971cbc4fb9d48ff/image.png)
For the tabs, the strings are correctly wrapped with `ts`, and I double-checked that the strings are translated in my translation file.
For the placeholders on the filter fields, the strings are not correctly wrapped in `ts`, but even if I do wrap them, and I make sure to add the strings to my translation files, they do not translate.
cc @colemanwhttps://lab.civicrm.org/dev/translation/-/issues/84`testLocalizedData()` failing after recent strings update2024-03-13T12:59:26Ztotten`testLocalizedData()` failing after recent strings updateIn CI, the test `testLocalizedData()` has started failing consistently. I've done some hunting and may have an explanation (*but don't know the next step*).
__The Test__: `testLocalizedData()` generates the SQL data-set in two locales. ...In CI, the test `testLocalizedData()` has started failing consistently. I've done some hunting and may have an explanation (*but don't know the next step*).
__The Test__: `testLocalizedData()` generates the SQL data-set in two locales. It spot-checks the data for a common string that should usually be translated. Specifically, `New Organization` is a link in the default menu. It's translated as `Neue Organisation` (`de_DE`) or `Nouvelle organisation` (`fr_FR`).
__Compare__: The test passes on my laptop but not in CI. My laptop has older translation data than the server.
You can manually inspect by running a small script and grepping the output (`cv scr printsql.php | grep Neue`):
```php
function _getSqlLive($locale) {
$schema = new \CRM_Core_CodeGen_Schema(\Civi\Test::codeGen());
$files = $schema->generateLocaleDataSql($locale);
foreach ($files as $file => $content) {
if (preg_match(';^civicrm_data\.;', $file)) {
return $content;
}
}
throw new \Exception("Failed to generate $locale");
}
echo _getSqlLive('de_DE');
```
Both outputs include some translated strings, but the newer doesn't have as many:
```diff
---Local machine, old data
+++Server machine, new data
("Individual,Contact",NULL,"4","0","1","new_individual","Neue Person"),
-("Organization,Contact",NULL,"5","0","1","new_organization","Neue Organisation"),
-("Household,Contact",NULL,"6","0","1","new_household","Neuer Haushalt"),
+("Organization,Contact",NULL,"5","0","1","new_organization","New Organization"),
+("Household,Contact",NULL,"6","0","1","new_household","New Household"),
```
If I inspect the data (`msgunfmt civicrm.mo -o civicrm.po`), I find these in the old data-set:
```
msgid "New Individual"
msgstr "Neue Person"
msgid "New Organization"
msgstr "Neue Organisation"
msgctxt "menu"
msgid "New Individual"
msgstr "Neue Person"
msgctxt "menu"
msgid "New Organization"
msgstr "Neue Organisation"
```
And these in the new data-set:
```
msgid "New Individual"
msgstr "Neue Person"
msgctxt "menu"
msgid "New Individual"
msgstr "Neue Person"
msgctxt "menu"
msgid "New Organization"
msgstr "Neue Organisation"
```
So it's missing `New Organization` in the default context. Additionally, the phrases `Phone Call` and `Meeting` appear in the old data-set but not the new data-set. I see similar omissions in `fr_FR`.
I assume that the SQL translation is evaluating everything in the default context. (It doesn't seem to use the `menu` translations). I don't know if that's good or bad. But regardless, it's probably bad that `Phone Call` and `Meeting` are missing.
In the CI logs for `testTranslatedData()`, the failure starts on roughly Feb 4. (Some places seem to start Feb 5 -- l10n data is cached for a bit.) I'm guessing this is related the new strings released around Feb 4 (https://chat.civicrm.org/civicrm/pl/jyqia56a47dp5dnrouiabnmnuw).
(ping @bgm)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/53Frequency units frequently fail to be translated properly2023-11-23T07:20:57ZStéphane Lussierstephane@symbiotic.coopFrequency units frequently fail to be translated properlyOn numerous occasions, the internal value of frequency units (eg: year, month) are sent for display to a template without being translated first.
One such issue may be found in [CRM/Contribute/Form/Contribution/Main.php](https://lab.ci...On numerous occasions, the internal value of frequency units (eg: year, month) are sent for display to a template without being translated first.
One such issue may be found in [CRM/Contribute/Form/Contribution/Main.php](https://lab.civicrm.org/dev/core/-/blob/master/CRM/Contribute/Form/Contribution/Main.php#L550). In this case, a simple fix would usually suffice:
```patch
--- a/civicrm/CRM/Contribute/Form/Contribution/Main.php
+++ b/civicrm/CRM/Contribute/Form/Contribution/Main.php
@@ -548,7 +548,7 @@ class CRM_Contribute_Form_Contribution_Main extends CRM_Contribute_Form_Contribu
if (!empty($form->_values['is_recur_interval']) || $className == 'CRM_Contribute_Form_Contribution') {
$unit .= "(s)";
}
- $form->assign('frequency_unit', $unit);
+ $form->assign('frequency_unit', ts($unit));
}
else {
$form->assign('one_frequency_unit', FALSE);
```
However, this patch in incomplete. There are multiple cases where a similar fix would need to be applied.
It's also not uncommon to find singular/plural tests in existing templates. The following example comes from [templates/CRM/Contribute/Form/Contribution/ThankYou.tpl](https://lab.civicrm.org/dev/core/-/blob/master/templates/CRM/Contribute/Form/Contribution/ThankYou.tpl#L123):
```smarty
{if $frequency_interval > 1}
<strong>{ts 1=$frequency_interval 2=$frequency_unit}This membership will be renewed automatically every %1 %2(s).{/ts}</strong>
{else}
<strong>{ts 1=$frequency_unit}This membership will be renewed automatically every %1.{/ts}</strong>
{/if}
```
This solution looks a bit strange to me... It assumes that adding an `(s)` to an internal keyword will make it plural. That may work in most situations, but it would prevent the already translated keyword to be altered upon the phrase translation.
Shouldn't the keyword be fully translated _and_ pluralized (if necessary) _before_ being sent to the translation string?
Could the `ts` function take care of translating and pluralizing substrings?
I don't mean to make a huge issue out of a small one, but I wonder: Is there a pattern that we can agree on for these sorts of situations?https://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/83No translation for "sections" in "New <contact>"2023-08-30T12:57:17Zthoni56No translation for "sections" in "New <contact>"When creating a new person/household/organisation there are foldable sections for details, address, communication preferences etc.
When the site has a non-English localization (at least a Swedish one) they are not translated.
![Skärmav...When creating a new person/household/organisation there are foldable sections for details, address, communication preferences etc.
When the site has a non-English localization (at least a Swedish one) they are not translated.
![Skärmavbild_2023-08-11_kl._13.38.33](/uploads/effa60ca9aa352a2d735ddfe89bb8d79/Skärmavbild_2023-08-11_kl._13.38.33.png)
I'm contributing to the Swedish translation so I know that the strings are translated in Transifex ;-). I have `uplang` installed and it seems to update other translations (although I would love a way to explicitly trigger the download, see https://lab.civicrm.org/extensions/uplang/-/issues/2).https://lab.civicrm.org/dev/translation/-/issues/47Investigate javascript currency library2023-06-02T19:33:39ZeileenInvestigate javascript currency libraryI think that we should use an approach for money fields similar to date fields where formatting is at the js layer and the values are always submitted in unrounded US decimal format - ie. always submitted like 4,000.0123 (or preferably 4...I think that we should use an approach for money fields similar to date fields where formatting is at the js layer and the values are always submitted in unrounded US decimal format - ie. always submitted like 4,000.0123 (or preferably 4000.123) and the php can expect just to 'use what it gets'
There are a number of possible js libraries. https://bashooka.com/coding/javascript-libraries-for-formatting-number-currency-time-date/
I feel like the requirements are
1) Format currencies appropriately. If I have a page that accepts donations in EUR it should display as 2.534.234,00 €
2) Format currencies by locale if known. If I 'know' - probably from a drupal url or similar that my page is for French Euro users then I want 2 534 234,00 €
3) Use the site numeric separator on backend screens. If I'm used to using a US decimal format I want all donations displayed with the same 'meaning' of the decimal
4) Format on input.
5) Package is appropriately licenced
The first 3 seem comfortably addressed by https://osrec.github.io/currencyFormatter.js/ which also offers the very nice
```
<div class='money' data-ccy='EUR'> 1234564.58 </div>
<div class='money' data-ccy='GBP'> 8798583.85 </div>
<div class='money' data-ccy='CHF'> 0.9754 </div>
```
syntax - which we could extend for scenarios 2 & 3 if necessary. Is MIT license OK?
The package seems pretty static - and they have not merged a PR to add Romanian which might be not great. I'm just looking at a couple of others as well
I REALLY like the jquery syntax above :-)
See https://lab.civicrm.org/dev/translation/-/issues/47 for same topic but php layer
Also Format on input - http://autonumeric.org/ looks promising - also MIT
Dinero doesn't really seem to do much formatting https://dinerojs.com/module-dinero
http://numbrojs.com/format.html also offers pretty reasonable formatting. I like the 'unformat' function but I wonder if it would work for Euro currencies
Note the screenshot demonstrates where full locale-based formatting would make no sense. The rows all need to use the decimal point the same way
![Screen_Shot_2020-05-18_at_4.35.13_PM](/uploads/58e7cfce6e88ccae2e19ba1b711d9dc4/Screen_Shot_2020-05-18_at_4.35.13_PM.png)
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/79Error in link on upgrade page after update database ready2022-11-30T18:23:15ZHanVError in link on upgrade page after update database readyI have today upgraded to version 5.55.2, on the screen after the database upgrade is an error in the link in the message:
Your Date Format settings have been automatically updated. (CRM/Upgrade/Incremental/php/FiveFiftyThree.php)
In the...I have today upgraded to version 5.55.2, on the screen after the database upgrade is an error in the link in the message:
Your Date Format settings have been automatically updated. (CRM/Upgrade/Incremental/php/FiveFiftyThree.php)
In the open tag it must be: href='%1'
I found the place with transifex.https://lab.civicrm.org/dev/translation/-/issues/81eWAYRecurring/ewayrecurring - Tricky to checkout git repo2022-11-30T08:36:05ZtotteneWAYRecurring/ewayrecurring - Tricky to checkout git repoThere appear to be two l10n data folders for "ewayrecurring", but they have different capitalization:
https://github.com/civicrm/civicrm-l10n-extensions/tree/master/po/eWAYRecurring
https://github.com/civicrm/civicrm-l10n-extensions/tre...There appear to be two l10n data folders for "ewayrecurring", but they have different capitalization:
https://github.com/civicrm/civicrm-l10n-extensions/tree/master/po/eWAYRecurring
https://github.com/civicrm/civicrm-l10n-extensions/tree/master/po/ewayrecurring
If you checkout on a case-insensitive filesystem, then you get weird messages.
Here's what I see with initial checkout:
```
[bknix-min:~/bknix/build/universe/ext/civicrm-l10n-extensions] git status
On branch master
Your branch is up to date with 'origin/master'.
Changes not staged for commit:
(use "git add <file>..." to update what will be committed)
(use "git restore <file>..." to discard changes in working directory)
modified: po/eWAYRecurring/bg_BG/eWAYRecurring.po
modified: po/eWAYRecurring/ca_ES/eWAYRecurring.po
modified: po/eWAYRecurring/cs_CZ/eWAYRecurring.po
modified: po/eWAYRecurring/cy_GB/eWAYRecurring.po
modified: po/eWAYRecurring/de_DE/eWAYRecurring.po
modified: po/eWAYRecurring/en_GB/eWAYRecurring.po
modified: po/eWAYRecurring/es_ES/eWAYRecurring.po
modified: po/eWAYRecurring/fr_CA/eWAYRecurring.po
```
The two names `po/eWAYRecurring/bg_BG/eWAYRecurring.po` and `po/ewayrecurring/bg_BG/ewayrecurring.po` point to the same object in the filesystem, but they have different content, so one or the other gets locally modified.
Because the repo is in this funny state, it's hard to stay up-to-date (`git pull` doesn't run cleanly).https://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/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/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.