Translation issueshttps://lab.civicrm.org/dev/translation/-/issues2021-02-24T18:47:17Zhttps://lab.civicrm.org/dev/translation/-/issues/66Should the colon of field labels be inside or outside ts()?2021-02-24T18:47:17ZcolemanwShould the colon of field labels be inside or outside ts()?I'm working on an Angular UI where labels for checkboxes do not end with a `:` (because with checkboxes, labels are on the right) but labels for text inputs end with a `:` (because with text fields, labels are on the left). In one sectio...I'm working on an Angular UI where labels for checkboxes do not end with a `:` (because with checkboxes, labels are on the right) but labels for text inputs end with a `:` (because with text fields, labels are on the left). In one section of the UI, the colon _conditionally_ appears if you check the box (because other options appear to the right).
![image](/uploads/7928c1c765f0cecb8c158e5f93b9d7cb/image.png)
As you can see in the screenshot, checking the box adds a colon to the labels "Link:" "Tooltip:" and "Rewrite:" because visually they now represent more than just the checkbox, but everything to their right as well.
Here's my question. Currently the code for these labels looks like this:
````js
{{ isChecked ? ts('Label:') : ts('Label') }}
````
This will work fine in other languages if the translation is done thoroughly, however if the two strings get translated differently (or one gets translated and the other does not) then it will cause a bizarre jump as the entire string changes!
That sounds bad, so I'm wondering if the lesser of two evils would be to only put the word inside `ts()` and conditionally add the literal `:` character. Would that be terrible in some languages?https://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 Debhttps://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/63Italian translation of Household Member relationship doesn't specify which si...2021-01-29T10:58:50ZDaveDItalian translation of Household Member relationship doesn't specify which side the relationship is onIn english it's "Household Member of" to mean the individual is a member of a household (A to B), and "Household Member is" to mean the household has the individual as a member (B to A).
In italian it's "Membro del nucleo familiare" on ...In english it's "Household Member of" to mean the individual is a member of a household (A to B), and "Household Member is" to mean the household has the individual as a member (B to A).
In italian it's "Membro del nucleo familiare" on both sides, so it's not clear which way is which.
https://lab.civicrm.org/dev/translation/-/blob/14722d7fbae68eaea4214aa0f6966d635c1f4d91/po/it_IT/common-base.po#L25802-25808
Came up while looking at other stuff. I don't know what the right translation should be.https://lab.civicrm.org/dev/translation/-/issues/62Updated State list for Taiwan2021-01-15T15:42:56ZsudomanUpdated State list for TaiwanOne of our site users would like to recommend updating the "State list" of "Country: Taiwan". Below is the recommended list from the Office of the President (<https://english.president.gov.tw/Page/106>). Our user says that it's ok to put...One of our site users would like to recommend updating the "State list" of "Country: Taiwan". Below is the recommended list from the Office of the President (<https://english.president.gov.tw/Page/106>). Our user says that it's ok to put the list under "State", even though they actually only call them city or county.
```
Taipei City
New Taipei City
Keelung City
Taoyuan City
Hsinchu City
Hsinchu County
Miaoli County
Taichung City
Changhua County
Nantou County
Yunlin County
Chiayi City
Chiayi County
Tainan City
Kaohsiung City
Pingtung County
Yilan County
Hualien County
Taitung County
Penghu County
Kinmen County
Lienchiang County
```
Thanks : )https://lab.civicrm.org/dev/translation/-/issues/61docURL and ts, or how ConfigTaskList.tpl has odd translation strings2021-05-10T20:51:53ZbgmdocURL and ts, or how ConfigTaskList.tpl has odd translation stringsWhen running the string extraction, these strings end up in the .pot files:
```
#: templates/CRM/Admin/Page/ConfigTaskList.tpl
msgid "$componentTitles.CiviContribute"
msgstr ""
#: templates/CRM/Admin/Page/ConfigTaskList.tpl
msgid ...When running the string extraction, these strings end up in the .pot files:
```
#: templates/CRM/Admin/Page/ConfigTaskList.tpl
msgid "$componentTitles.CiviContribute"
msgstr ""
#: templates/CRM/Admin/Page/ConfigTaskList.tpl
msgid "$componentTitles.CiviPledge"
msgstr ""
#: templates/CRM/Admin/Page/ConfigTaskList.tpl
msgid "$componentTitles.CiviEvent"
msgstr ""
#: templates/CRM/Admin/Page/ConfigTaskList.tpl
msgid "$componentTitles.CiviMember"
msgstr ""
#: templates/CRM/Admin/Page/ConfigTaskList.tpl
msgid "$componentTitles.CiviMail"
msgstr ""
#: templates/CRM/Admin/Page/ConfigTaskList.tpl
msgid "$componentTitles.CiviCampaign"
msgstr ""
#: templates/CRM/Admin/Page/ConfigTaskList.tpl
msgid "$componentTitles.CiviCase"
msgstr ""
#: templates/CRM/Admin/Page/ConfigTaskList.tpl
msgid "$componentTitles.CiviGrant"
msgstr ""
```
To test:
```
civistrings templates/CRM/Admin/Page/ConfigTaskList.tpl
```
Is it because of an incorrect use of `ts`, or is it because civistrings should ignore crmURL?
Code:
```
<tr class="even">
<td class="tasklist nowrap" style="width: 10%;">{docURL page="user/contributions/what-is-civicontribute" text=$componentTitles.CiviContribute}</td>
<td>{ts}Online fundraising and donor management, as well as offline contribution processing and tracking.{/ts}</td>
</tr>
```
Example of docURL strings that should be extracted:
```
templates/CRM/Contribute/Form/ContributionPage/Custom.hlp:{capture assign=docLinkCustom}{docURL page="user/organising-your-data/custom-fields" text="custom fields"}{/capture}
templates/CRM/Contribute/Form/ContributionPage/Custom.hlp:{capture assign=docLinkProfile}{docURL page="user/organising-your-data/profiles" text="profiles"}{/capture}
templates/CRM/Case/Page/ConfigureError.tpl:{capture assign=docLink}{docURL page="user/case-management/set-up" text="CiviCase Setup documentation"}{/capture}
templates/CRM/Contact/Form/OnBehalfOf.tpl: {ts}Latitude and longitude may be automatically populated by enabling a Mapping Provider.{/ts} {docURL page="user/initial-set-up/installation-and-basic-set-up" text="(Refer to the Mapping and Geocoding section in the Installation and Basic Setup Chapter)"}</span>
```
I feel like we should instead use 'ts' in the docURL call, instead of assuming it. There are 22 instances where it would need fixing.
```
grep -r docURL templates/ | grep text | grep -v componentTitle
```
@totten @seamuslee Any thoughts?https://lab.civicrm.org/dev/translation/-/issues/60Add created_date column to the civicrm_note table2020-12-10T16:42:40ZjasonmAdd created_date column to the civicrm_note tableAfter merging contacts, we noticed that when viewing the notes of the merged contact, the notes merged from the duplicated contact display the timestamp of when the merge happened. It would be helpful for note records to store both the c...After merging contacts, we noticed that when viewing the notes of the merged contact, the notes merged from the duplicated contact display the timestamp of when the merge happened. It would be helpful for note records to store both the created date and the last modified date and to display both dates in the notes list view at /civicrm/contact/view?reset=1&cid=xxxxxx![screenshot-a](/uploads/02cf8a02bae6cf03df9764d7203355db/screenshot-a.png)
![screenshot-b](/uploads/08a903e82015e10103afbf5003b24961/screenshot-b.png)
![screenshot-c](/uploads/bd09d47c2cfe945b1a5beb048fbcbe02/screenshot-c.png)https://lab.civicrm.org/dev/translation/-/issues/59Broken link and mistranslation in Italian for ACL roles page2021-03-19T15:14:05ZDaveDBroken link and mistranslation in Italian for ACL roles pageIt's just a help text link, but maybe 2 problems:
1. The use of `{docURL}` requires text you pass in to be translated already.
1. Somebody probably noticed it wasn't working and tried to adjust by putting the link into transifex, but it...It's just a help text link, but maybe 2 problems:
1. The use of `{docURL}` requires text you pass in to be translated already.
1. Somebody probably noticed it wasn't working and tried to adjust by putting the link into transifex, but it leads to a broken link: https://lab.civicrm.org/dev/translation/-/blob/9d4c4d9db3535f3816969b541c9bbe00345569a4/po/it_IT/common-base.po#L18128
This is the code:
https://github.com/civicrm/civicrm-core/blob/d1eed91c218f4c285a535275e36732f68463824b/templates/CRM/ACL/Header.tpl#L10-L14
```smarty
{capture assign=docLink}{docURL page='user/initial-set-up/permissions-and-access-control/' text='Access Control Documentation'}{/capture}
<div class="help">
<p>{ts 1=$docLink}ACLs allow you to control access to CiviCRM data. An ACL consists of an <strong>Operation</strong> (e.g. 'View' or 'Edit'), a <strong>set of data</strong> that the operation can be performed on (e.g. a group of contacts), and a <strong>Role</strong> that has permission to do this operation. Refer to the %1 for more info.{/ts}</p>
</div>
```https://lab.civicrm.org/dev/translation/-/issues/58Cannot create proper `Group`s on multilingual with MySQL 5.6 and Civi 5.31-rc2021-03-18T00:43:45ZtottenCannot create proper `Group`s on multilingual with MySQL 5.6 and Civi 5.31-rcThe unit-test `CRM_Mailing_MailingSystemTest::testGitLabIssue1108()` sets up a multilingual configuration and creates two groups. The test is failing, which reveals a problem with `Group`s on multilingual.
Steps to reproduce
-----------...The unit-test `CRM_Mailing_MailingSystemTest::testGitLabIssue1108()` sets up a multilingual configuration and creates two groups. The test is failing, which reveals a problem with `Group`s on multilingual.
Steps to reproduce
-------------------
Use an environment like `bknix-min` (e.g. MySQL 5.6 + PHP 7.1). Create a site on 5.31. Then either:
* Run the unit-test
* Use the live site -- [Enable multi-lingual](https://gist.github.com/totten/e1244d9a98c9d9fd1ebc899f5e780252) and [create two groups](https://gist.github.com/totten/b405a10cd82f35d125d64c792786d6f1). (Note: You get the same problem if you create the groups in the web UI.)
Discussion
----------
I bisected to find that the failure originates [with a schema update for civicrm_group](https://github.com/civicrm/civicrm-core/pull/18599/files#diff-9f8f69e770bcc926a5831339a92183bbb70aad496a16dee07beaf9c6ff7b42d9L34). Specifically, the `title` column now has `<required>true</required>`.
The problem shows some environmental variation
| Runtime | Base-branch | Group schema | Outcome |
|----|----|----|----|
| bknix-min (mysql 5.6.47, php 7.1.33) | 5.31 (rc) | `civicrm_group.title` required | Failing |
| bknix-min (mysql 5.6.47, php 7.1.33) | 5.31 (rc) | `civicrm_group.title` not required | Passing |
| bknix-max (mysql 5.7.27, php 7.3.10) | 5.31 (rc) | `civicrm_group.title` required | Passing |
To see the problem, it helps to inspect what happens after creating the first group. Compare the outcome in different environments:
1. __Failing case__
By default, when you create the first `Group`, it throws an exception:
```
INSERT INTO `civicrm_group_en_US` (`name` , `title` , `description` , `is_active` , `visibility` , `group_type` , `parents` , `is_reserved` , `created_id` )
VALUES ('First_tmp' , 'First' , NULL , 1 , 'User and User Admin Only' , '' , '' , 0 , 202 )
-- [nativecode=1423 ** Field of view 'dmastercivi_ssc8b.civicrm_group_en_US' underlying table doesn't have a default value]
```
This is partially because I'm using a dev-build which has `STRICT_TRANS_TABLES`. If I hack `CRM_Core_DAO::init()` to omit `STRICT_TRANS_TABLES`, then appears to be more forgiving. It creates the `Group`:
```
mysql> select id, title_en_US, title_fr_FR from civicrm_group;
+----+---------------------------+---------------------------+
| id | title_en_US | title_fr_FR |
+----+---------------------------+---------------------------+
| 1 | Administrators | Administrators |
| 2 | Newsletter Subscribers | Newsletter Subscribers |
| 3 | Summer Program Volunteers | Summer Program Volunteers |
| 4 | Advisory Board | Advisory Board |
| 5 | Case Resources | Case Resources |
| 6 | First | |
+----+---------------------------+---------------------------+
```
However, the empty value of `title_fr_FR` is a problem. As soon as you create a *second* `Group`, it will violate the uniqueness constraint (`UI_title_fr_FR`).
2. __Passing__
In the two passing cases, the first `Group` is created without a problem:
```
mysql> select id, title_en_US, title_fr_FR from civicrm_group;
+----+---------------------------+---------------------------+
| id | title_en_US | title_fr_FR |
+----+---------------------------+---------------------------+
| 1 | Administrators | Administrators |
| 2 | Newsletter Subscribers | Newsletter Subscribers |
| 3 | Summer Program Volunteers | Summer Program Volunteers |
| 4 | Advisory Board | Advisory Board |
| 5 | Case Resources | Case Resources |
| 6 | First | First |
+----+---------------------------+---------------------------+
```
Note the synchronized title.https://lab.civicrm.org/dev/translation/-/issues/57Mixed up translation for a few case role-related strings in nl_BE2020-10-23T15:08:34ZDaveDMixed up translation for a few case role-related strings in nl_BEThere are a couple lines in the nl_BE po file that are a bit mixed up. This came up before and it got fixed for nl_NL but didn't get updated for nl_BE. I think this needs to be updated in transifex.
https://lab.civicrm.org/dev/translati...There are a couple lines in the nl_BE po file that are a bit mixed up. This came up before and it got fixed for nl_NL but didn't get updated for nl_BE. I think this needs to be updated in transifex.
https://lab.civicrm.org/dev/translation/-/blob/41c36bc0532e3dd5e96e3481d6212f0c36e84686/po/nl_BE/case.po#L787-797
The nl_NL ones are correct so the corresponding lines above just need to match these:
https://lab.civicrm.org/dev/translation/-/blob/41c36bc0532e3dd5e96e3481d6212f0c36e84686/po/nl_NL/case.po#L771-781https://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/55nl_BE not in l10n download?2020-10-21T20:34:17ZDaveDnl_BE not in l10n download?Did we miss a step somewhere when we added it recently?Did we miss a step somewhere when we added it recently?https://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/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/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/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/50Locale-aware recaptcha2020-12-14T04:07:55Zmattwiremjw@mjwconsult.co.ukLocale-aware recaptchaThe library in use by CiviCRM is a *very* old version and is not locale-aware. See https://civicrm.stackexchange.com/questions/11533/recaptcha-update-language/37503 for more info.
We should update the library and make recaptcha in CiviC...The library in use by CiviCRM is a *very* old version and is not locale-aware. See https://civicrm.stackexchange.com/questions/11533/recaptcha-update-language/37503 for more info.
We should update the library and make recaptcha in CiviCRM respect the locale of the form.https://lab.civicrm.org/dev/translation/-/issues/49Multi-record Custom Data Money Field is not formatted2020-06-12T14:24:00ZbgmMulti-record Custom Data Money Field is not formattedSteps to re-create:
* Create a new Custom Field Group, for Contacts, with multi-record enabled.
* Add a money field (text) in that group.
Then go to a contact record, and create a record with a money amount.
Result:
![civicrm-custom-...Steps to re-create:
* Create a new Custom Field Group, for Contacts, with multi-record enabled.
* Add a money field (text) in that group.
Then go to a contact record, and create a record with a money amount.
Result:
![civicrm-custom-value-formatting](/uploads/6f44d0c3eecfbf7ce0471ed87b2eb49b/civicrm-custom-value-formatting.png)
Expected result: $123.44
When we view the record, it displays correctly:
![Capture_d_écran_de_2020-06-10_12-52-10](/uploads/6cefeae38392e7681effe4c298064db9/Capture_d_écran_de_2020-06-10_12-52-10.png)
I narrowed it down to `CRM_Profile_Page_MultipleRecordFieldsListing::browse()`, but it feels like a mine field.https://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/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)