Development issueshttps://lab.civicrm.org/groups/dev/-/issues2023-08-17T14:24:07Zhttps://lab.civicrm.org/dev/core/-/issues/4505Localisation: Report contribution_details doesn't respect date format settings2023-08-17T14:24:07ZDetlev SieberLocalisation: Report contribution_details doesn't respect date format settings## Overview
_see_ #4503 for similar issue
## Reproduction steps
1. Set localization settings **date format** to "%d.%m.%Y %H:%M" / "%d.%m.%Y"
2. Click on **Reports -\> Contribution Detail**
3. Click on "Refresh results" and/or downloa...## Overview
_see_ #4503 for similar issue
## Reproduction steps
1. Set localization settings **date format** to "%d.%m.%Y %H:%M" / "%d.%m.%Y"
2. Click on **Reports -\> Contribution Detail**
3. Click on "Refresh results" and/or download pdf
## Current behaviour
For the header, the localisation settings are interpreted correctly.
For the report lines, the date format don't respect the localisation settings.
See screenshot:
![contribution details date format.png](/uploads/453ea5f2249edac6e89ff322862c7a8d/contribution_details_date_format.png)
## Expected behaviour
All dates should be displayed in the selected localisation format.
##https://lab.civicrm.org/dev/core/-/issues/4503Localization: Report contribution_details doesn't respect money settings for ...2023-08-17T14:22:38ZDetlev SieberLocalization: Report contribution_details doesn't respect money settings for additional fields## Reproduction steps
1. Set localization settings: **decimal separator** to `,` and **thousand separator** to `.`
2. Click on **Reports -\> Contribution Detail**
3. Select Non-deductible Amount, Fee Amount, Net Amount, Soft Credit Amou...## Reproduction steps
1. Set localization settings: **decimal separator** to `,` and **thousand separator** to `.`
2. Click on **Reports -\> Contribution Detail**
3. Select Non-deductible Amount, Fee Amount, Net Amount, Soft Credit Amount
4. Click on "Refresh results"
## Current behaviour
For the contribution amount, the localisation settings are interpreted correctly.
The other amounts don't respect the localisation settings.
See screenshot:
![2023-08-16_21-13.png](/uploads/ea63065ddba5bb00ce85c2cd77074cae/2023-08-16_21-13.png)
## Expected behaviour
All amounts should be displayed in the selected localisation format.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/core/-/issues/4071Multiple language support: translations are not available in "Contribution A...2023-11-23T07:47:00ZmasettoMultiple language support: translations are not available in "Contribution Amounts Label" (`amount_label` field) in the Contribution pageOverview
----------------------------------------
On tab "Amounts" of Contribution page there is no possibility to make translations of "Contribution Amounts Label".
Reproduction steps
----------------------------------------
1. Click ...Overview
----------------------------------------
On tab "Amounts" of Contribution page there is no possibility to make translations of "Contribution Amounts Label".
Reproduction steps
----------------------------------------
1. Click on **Administer -> Localisation -> Languages, Currency, Locations**.
1. Check on ****Enable Multiple Languages**.
1. Click on **Contribution -> New Contribution Page**.
1. On tab "Amounts", "Contribution Amounts Label" there is no possibility to make translations.
Environment information
----------------------------------------
* __CiviCRM:__ 5.54.0
* __PHP:__ _7.4
* __CMS:__ _WordPress 6.1_https://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/core/-/issues/3613System Workflow Messages - Improve localization experience2024-01-14T14:55:57ZtottenSystem Workflow Messages - Improve localization experience## Background
Several CiviCRM components - such as CiviContribute, CiviCase, and CiviEvent - send automated email notifications. Many organizations find it useful to customize/tune these emails, and the emails may be administered in the...## Background
Several CiviCRM components - such as CiviContribute, CiviCase, and CiviEvent - send automated email notifications. Many organizations find it useful to customize/tune these emails, and the emails may be administered in the web UI ("Administer: Message Templates: System Workflow Messages").
In principle, this is a powerful tool in which an administrator may use Smarty templating to produce highly tuned messages -- and it requires only the ability to understand template notations (e.g. `{$contact.first_name}` or `{$event.start_date}`). However, in practice, this is often difficult -- real-world templates are long and complex, and they may be used with data of varying quality/character, and the workflow to test a template can be tedious.
## Goals
This epic (*overarching issue*) aims to improve the experience of maintaining system workflow templates. We are specifically funded to work on it from the following perspective: You have an organization which maintains multiple templates for use in multiple countries/locales -- periodically, as campaigns/operations are revised, you may need to engage with a few people to update+retest a few templates. We have three main themes to improve upon:
* __Drafting/Workflow__: Currently, Civi has exactly one variant/revision of a template, and it is always live. There is no way to develop a draft (new revisions) or to keep a record of past revisions.
* __~~Translation~~ Localization__: For any given message, you may need to compose different versions for different locales.
* __Previews/Samples__: Many templates are sensitive to fine-grained details. This is true in multiple ways, e.g. (1) the template adjusts based on *available data* ("Do we have a mailing address for this person? Do we have a full-name, or just an email? Is this one-off contribution or a recurring contribution?"), and (2) the template includes *precise codes* that must be well-formed (e.g. matching tags, matching quotes, using an email-friendly dialect of HTML/CSS).
## Related work
* https://lab.civicrm.org/extensions/msgtpltools
* https://lab.civicrm.org/community/feature-request/-/issues/26
* https://github.com/eileenmcnaughton/civi-data-translate
* https://lab.civicrm.org/extensions/l10nx
## Subtopics / Brainstorming
(Some of the descriptions here are terse - but they may get more explanation in the wireframe.)
* __Sample data presentation__: While composing a message, how do you show a preview based on sample data? Some ideas:
* __Edit-Preview Split-Panes__
* __Pro__: very amenable to live-update
* __Con__: needs wide screen (prob dialog). agreeable with O(10) sample records - but disagreeable with O(1000) records
* __Edit-Preview Accordion__
* __Pro__: fairly amenable to live-update. full width.
* __Con__: agreeable with O(10) sample records - but disagreeable with O(1000) records
* __Explore-Preview Panes in dialog__
* __Pro__: agreeable with O(1000) records
* __Con__: requires more navigating.
* __Comment__: live-update might be possible with separate popup - but more difficult
* __Comment__: might mitigate navigation work with a hotkey
* __Sample data source__: When viewing a preview based on some example record(s), where does the example come from?
* __Basic/prepackaged__: Define some JSON files, which are linked to the workflows.
* __Comment__: Requires metadata to say, "workflows $a+$b can use sample data $c+$d"
* __Pro__: Some templates have very nuanced purposes and may have special vars. This allows you to mock data that's attuned to edge-cases, and you can use these samples in any environment (dev-site/public-demo-site/live-site). No mixing-up real records and sample records. Can simulate complex data (e.g. "tpl for use-case with 2 contribution records")
* __Con__: More upfront work in making sample data. User cannot test against real data.
* __Comment__: Should have unit-test to ensure sample-data-structure stays in sync with real-data-structure
* __Data search__: Search for a live record (eg `Contribution` or `Membership`) to use as a sample.
* __Comment__: Requires metadata to say, "workflows $a+$b need data from entity $c"
* __Pro__: You can use real data, which can be subjectively attuned.
* __Con__: You have to find real data that's *useful*. May be awkward if you're trying to test edge-cases, unless you're willing to add mock/synthetic records to the DB. All mail-merge data must be selectable from one record (eg "Contribution #123"; eg no other inputs besides DB content).
* __Variants__: The UI for this can take on a few variations, eg
* In "Edit Msg Tpl", show a searchable tree. Filter by contact name and select the target record.
* In "Edit Msg Tpl", ask the user to enter a numeric ID.
* In "View Contact", add links/actions for generating previews.
* __Flagged records__: As an adminsitrator, find real records and save them in a list (e.g. "Record #$x is a sample for use in workflows $a, $b")
* __Comment__: Requires somewhere to store the list (e.g. custom-field or new-field or new-table)
* __Pro__: You can use real data, which can be subjectively attuned. The list of samples is curated/abbreviated.
* __Con__: The individual composing the template may not know how to flag/unflag sample records. Requires configuration (and extant samples) before you can use email preview.
* __Grain of ~~translation~~ localization__
* __Record level__: For each `(locale,workflow)`, create another `civicrm_msg_template` record.
* __Field level__: Each `(workflow)` only has one `civicrm_msg_template` record. Attached to that record are multiple translations (ex: `field=subject,locale=fr_FR,text="Bonjour"`).
* __String level__: Each `(workflow)` only has one `civicrm_msg_template` record, and that record has one `body_text`. However, the `body_text` uses translatable strings (ex: 'body_text={cts id=greeting}Greetings,{/cts}`)
* Trade-off
| Record-level | Field-level | String-level |
| -- | -- | -- |
| Each translation goes through a separate, well-delineated drafting workflow. | Translation workflow is batched (per template). All translations must be ready to activate together. | Orthogonal workflows for templates vs strings. |
| Message structure (paras/sections) is localized. | Message structure (paras/sections) is localized. | Message structure is uniform across locales. (Realistic? What abouts `<table>` LTR/RTL? |
| Cannot re-use translated snippets. | Cannot re-use translated snippets. | Re-use translated snippets. |
## Wireframes
There are a few different ways to approach this. To get a sense for the usability and work, we can post a few alternative wireframes. (*This section may be updated as more are added.*)
* __(0) Status quo__: [_0__Sys_Wf_Msgs](/uploads/ad96003d71133d298f95ce79902a7583/_0__Sys_Wf_Msgs.png), [_0__Edit_Msg_Tpl](/uploads/81bc234651182b65993bc28c8052b68b/_0__Edit_Msg_Tpl.png)
* __(1) Record-level translations w/previews and drafting workflow__: [_1Rec__Sys_Wf_Msgs](/uploads/532b842406c17c31be5ae9195ceb6aa8/_1Rec__Sys_Wf_Msgs.png), [_1Rec__Edit_Msg_Tpl](/uploads/13a1f717e829e3de480750c4893969a7/_1Rec__Edit_Msg_Tpl.png) (*Note: The blue-arcs indicate a couple variations on how to include the preview/sample functionality. This tracks close to status-quo, and incremental changes are highlighted with yellow-dots.*)
* __(2) Field-level translations__: [_2Fld__Sys_Wf_Msgs](/uploads/7e1f46e722d8afc706a92c56e295c55e/_2Fld__Sys_Wf_Msgs.png), [_2Fld__Edit_Msg_Tpl](/uploads/4bc932b7bb3f304853b0c107b98d41b5/_2Fld__Edit_Msg_Tpl.png) (*Note: This tracks close to status-quo, and incremental changes are highlighted with yellow-dots.*)
* __(3) String-level translations__: [_3Subfld__Sys_Wf_Msgs](/uploads/f52ffbb764917954790fbbd3ed807acf/_3Subfld__Sys_Wf_Msgs.png), [_3Subfld__Edit_Msg_Tpl](/uploads/b20bc83d302d55a485d975aff6ca70e1/_3Subfld__Edit_Msg_Tpl.png) (*Note: This tracks close to status-quo, and incremental changes are highlighted with yellow-dots.*)
* __(4) Record-level translations w/browse-edit tree + accordion-preview__: [_4Tree__Browse-Edit](/uploads/8cc47238a9d597f80950c1d98c0ea43a/_4Tree__Browse-Edit.png)
* __(5) Field-level translations w/browse-edit tree + accordion-preview__ [_5Tree__Browse-Edit](/uploads/aab231199d0b4217a2f44f9ad45aecb1/_5Tree__Browse-Edit.png)
* __(6) Field-level translations w/matrix, preview-dialog, and drafting workflow__: [_6Mat__Sys_Wf_Msgs](/uploads/3a32390f36f50d8e158e1155dc586969/_6Mat__Sys_Wf_Msgs.png), [_6Mat__Edit_Msg_Tpl](/uploads/353f97846fd9d2b1e037ec92e60101fc/_6Mat__Edit_Msg_Tpl.png) (*Note: This assumes that there is a separate string-storage service like [civi-data-translate](https://github.com/eileenmcnaughton/civi-data-translate), and it assumes that the `String` record has some workflow property like like `is_draft` or `revision`. So each string might have the properties `entity`,`entity_id`,`field`,`locale`,`text`,`is_draft`.*)
* __(7) As with 6, but with various refinements__: [_7Mat__Sys_Wf_Msgs](/uploads/73d37acab4307054b4fe4f3291ae7dcd/_7Mat__Sys_Wf_Msgs.png),
[_7Mat__Edit_Msg_Tpl](/uploads/4807652bd20bfb5bf0912bf24f05d444/_7Mat__Edit_Msg_Tpl.png)https://lab.civicrm.org/dev/translation/-/issues/75Translatable fields within Extension table2022-04-21T20:39:46ZseamusleeTranslatable fields within Extension tableAt present the CiviCRM i18n widget code and also the i10n schema code depend on the functions in the schema structure file returning an array of fields or html widgets. The Schema Structure file does not contain any information about tab...At present the CiviCRM i18n widget code and also the i10n schema code depend on the functions in the schema structure file returning an array of fields or html widgets. The Schema Structure file does not contain any information about tables other than core tables so for example in the JMA Grant Applications extension if we wanted to make the title or the introductory text field translatable we would have to hack the schema structure file.
I would like to propose that we create 3 new Events or similar to handle altering the fields, indices and widgets functions in the schema structure file.https://lab.civicrm.org/dev/translation/-/issues/74ts() - Allow symbolic placeholders2022-01-27T13:24:34Ztottents() - Allow symbolic placeholdersOverview
---------
When writing translatable strings, placeholders must be numeric.
This leads to some quirky strings - eg if you're outputting a title and subtitle ("Some Chapter: Some Section"), the only way to encode that is `ts('%1...Overview
---------
When writing translatable strings, placeholders must be numeric.
This leads to some quirky strings - eg if you're outputting a title and subtitle ("Some Chapter: Some Section"), the only way to encode that is `ts('%1: %2')`. This string should be translatable because the layout is language dependent (eg LTR/RTL; eg punctuation-preferences), but the exported string will become meaningless when presented in Transifex (or similar). And it may be confused with other/similar strings.
Current behavior
-----------------
The function `ts(string $str, array $params)` accepts the following `$params`:
* Functional params (`count`, `plural`, `context`, `domain`, `escape`, `skip_translation`)
* Substitution params (numeric keys; `0`, `1`, `2`, ...)
As in:
```php
echo ts('Hello, %1!', [
1 => $name,
]);
echo '<li>' . ts('%1: %2', [
1 => $title,
2 => $subtitle,
]) . '</li>';
echo ts('The directory %1 is not writable. Please check your file permissions.', [
'plural' => 'The following directories are not writable: %1. Please check your file permissions.',
'count' => count($notWritableDirs),
1 => implode(', ', $notWritableDirs),
]),
```
```smarty
{ts 1=Bob}Hello %1!{/ts}
<li>{ts 1="Title" 2="Subtitle"}%1: %2{/ts}</li>
```
~~Proposed behavior (draft 1; symbol-prefix)~~
-----------------
Any `$params` which begin with a symbol (`%`, `_`, `{`, `@`, etc) will be used for variable substitution.
The earlier examples remain valid. Additionally, these examples are also valid:
```php
echo ts('Hello, %name!', [
'%name' => $name,
]);
echo '<li>' . ts('%title: %subtitle', [
'%title' => $title,
'%subtitle' => $subtitle],
) . '</li>';
echo ts('The directory %dir is not writable. Please check your file permissions.', [
'plural' => 'The following directories are not writable: %dir. Please check your file permissions.',
'count' => count($notWritableDirs),
'%dir' => implode(', ', $notWritableDirs),
]),
```
```smarty
{ts _NAME_=Bob}Hello _NAME_!{/ts}
<li>{ts _title_="Foo" _subtitle_="Bar"}_title_: _subtitle_{/ts}</li>
```
Proposed behavior (draft 2; capitalization-based)
-----------------
Any `$params` which begin with a capital letter (`[A-Z]`) will be used for variable substitution.
```php
echo ts('Hello, %NAME!', [
'NAME' => $name,
]);
echo '<li>' . ts('%TITLE: %SUBTITLE', [
'TITLE' => $title,
'SUBTITLE' => $subtitle],
) . '</li>';
echo ts('The directory %DIR is not writable. Please check your file permissions.', [
'plural' => 'The following directories are not writable: %DIR. Please check your file permissions.',
'count' => count($notWritableDirs),
'DIR' => implode(', ', $notWritableDirs),
]),
```
```smarty
{ts NAME=Bob}Hello %NAME!{/ts}
<li>{ts TITLE="Foo" SUBTITLE="Bar"}%TITLE: %SUBTITLE{/ts}</li>
```
Comments
---------
Either draft (using symbol-prefix or using uppercase) should avoid conflicts with existing strings+params. (Existing params do not begin with symbols and they are not uppercase.)
A couple factors in choosing a symbol:
* Using `%` is most consistent with current `ts()` style.
* `ts()` is used in multiple programming languages. Each has different compatibility/constraints.
* Pure PHP and pure JS are fairly flexible (`%FOO`, `{{FOO}}`, `_FOO_`, etc)
* Smarty-HTML (`{ts KEY=VALUE}...{/ts}`) is pretty limited. The bottleneck is how it parses the `KEY`.
* Angular-HTML (`{{ts('...')}}`) is in the middle. It's OK for `{{ts('%FOO')}}`, `{{ts('_FOO_')}}`, but I wouldn't count on `{{ts('{{FOO}}')}}`.
* If you want one symbol that works everywhere, `_` is probably it.
* Being flexible about symbol may be good for compatibility in the most contexts.
I suppose that the uppercase approach constrains style a bit, but maybe that's a good thing - ie you get more consistency in how `ts()` looks across environments.
Questions
---------
Are there any constraints in other layers -- eg Transifex, civistrings -- which would prevent this?
As far as I know, the only constraints which require using numeric-keys are baked into `ts()` itself.https://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/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/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/user-interface/-/issues/28Norway has changed the names of its counties2020-10-14T00:40:05ZsudomanNorway has changed the names of its countiesNorway recently updated the names of its counties, which Civi refers to as "states". Could you please update this list of counties? Thanks! : )
Norwegian government (Norwegian)
https://www.regjeringen.no/no/tema/kommuner-og-regioner/reg...Norway recently updated the names of its counties, which Civi refers to as "states". Could you please update this list of counties? Thanks! : )
Norwegian government (Norwegian)
https://www.regjeringen.no/no/tema/kommuner-og-regioner/regionreform/regionreform/nye-fylker/id2548426/
Wikipedia (English)
https://en.wikipedia.org/wiki/Counties_of_Norwayhttps://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/44When you have multiple available languages using the language switcher on an ...2020-04-14T14:46:25ZDaveDWhen you have multiple available languages using the language switcher on an angular page gives page not foundI thought I'd seen this reported already but can't find it. Maybe I was thinking of https://lab.civicrm.org/dev/translation/-/issues/23 which is maybe related but seems a bit different. The issue here is the resulting url.
1. On the loc...I thought I'd seen this reported already but can't find it. Maybe I was thinking of https://lab.civicrm.org/dev/translation/-/issues/23 which is maybe related but seems a bit different. The issue here is the resulting url.
1. On the localization page add another language in the "Available languages" field.
1. Visit an angular page like Admin - CiviCase - Case Types.
1. Using the language switcher (on drupal 7 it's in the left sidebar), change the language.
1. It will change the language, but you get a page that just says "Unknown path".https://lab.civicrm.org/dev/translation/-/issues/42Document guidelines for situations where trivial technical changes do more ha...2020-04-02T13:28:24ZDaveDDocument guidelines for situations where trivial technical changes do more harm than goodMoved to gitlab from https://github.com/civicrm/civicrm-dev-docs/pull/754
The [end-to-end process](https://lab.civicrm.org/dev/translation/-/wikis/Pushing-new-strings-to-transifex) from the time you make a change in the code to when the...Moved to gitlab from https://github.com/civicrm/civicrm-dev-docs/pull/754
The [end-to-end process](https://lab.civicrm.org/dev/translation/-/wikis/Pushing-new-strings-to-transifex) from the time you make a change in the code to when the translation of it ends up in the tarball of a release is lengthy, depends on human translators' time, and currently includes a [manual tedious step](https://lab.civicrm.org/infra/ops/-/issues/931) for administrators (which means it doesn't even get to transifex to be made available to translators for a few months). In the meantime the string you just changed has now potentially become untranslated immediately in all languages in both master and likely still untranslated when it becomes a release candidate. And possibly for several releases/months after.
So if the wording is not preventing users from completing tasks and the technical functionality is working, then is having it be EXACTLY right worth invalidating an existing translation and generating another end-to-end cycle of the translation process *if that is the only change being made*. It seems like it is possible to write out some guidelines and examples.
The PR proposed these as a starting point:
#### Don't change
```smarty
{ts 1="https://www.example.org"}This is a block of text where the wording is fine and the link works but the <a href="%1" target="_blank">link attributes</a> should be a parameter to the ts. But it's not preventing anyone completing their work tasks and isn't confusing to users.{/ts}
```
#### Do change
* If it would normally break translation but the new string is already used somewhere else, and so it's already translated.
* Spelling mistakes. While not preventing a user from completing a task, the positives outweigh the negatives, and this is visible to the user, as compared to the above "don't change" example where the user doesn't see a problem.https://lab.civicrm.org/dev/core/-/issues/719can't delete profile pre- post- field help on multilinguage sites2022-08-26T00:20:44ZJoeMurraycan't delete profile pre- post- field help on multilinguage sitesIf you add field pre and post help to profiles on a single language site, you can then delete it and save successfully. On a site with more than 1 language, trying to delete the help leads to it being resaved (I believe from the alternat...If you add field pre and post help to profiles on a single language site, you can then delete it and save successfully. On a site with more than 1 language, trying to delete the help leads to it being resaved (I believe from the alternative language's copy of the help).
Verified on dmaster 5.12.alpha1.Monish DebMonish Debhttps://lab.civicrm.org/dev/translation/-/issues/1Distribution and management of l10n/xx_YY/settings.default.json files2020-08-11T11:18:57ZbgmDistribution and management of l10n/xx_YY/settings.default.json filesNow that CRM-16395 has been merged, we can provide localised setting files for supported languages.
Now we need to:
* [x] decide where to store (in the 'l10n' git repo) the settings files
* [x] bundle those json files in civicrm-5.x.xx...Now that CRM-16395 has been merged, we can provide localised setting files for supported languages.
Now we need to:
* [x] decide where to store (in the 'l10n' git repo) the settings files
* [x] bundle those json files in civicrm-5.x.xx-l10n.tar.gz
* [x] document the process by which people can send/update setting files
* [ ] update the documentation about non-English installation?
Example:
https://github.com/civicrm/civicrm-core/files/305643/settings.default.json.txt