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/4425Standalone: language change does not stick2023-12-02T12:21:46ZbgmStandalone: language change does not stickTo reproduce:
- Administer > System Settings > Extensions: Enable the [update language](https://civicrm.org/extensions/update-language-files) extension, saves time, if you haven't already downloaded the translation files
- Administer > ...To reproduce:
- Administer > System Settings > Extensions: Enable the [update language](https://civicrm.org/extensions/update-language-files) extension, saves time, if you haven't already downloaded the translation files
- Administer > Localization > Languages: Enable two languages (no need for multilingual, just enable a second language)
You should then be able to display pages in different languages, using the `lcMessages=xx_YY` parameter. Ex:
- https://crm.example.org/civicrm?lcMessages=en_US
- https://crm.example.org/civicrm?lcMessages=fr_CA (adapt to the locale you enabled)
This works for a single page. However, CiviCRM should normally save the language in the `$session` object. See `CRM_Core_BAO_ConfigSetting::applyLocale`. It does not seem to be happening.
(I'll try to circle back, just wanted to log my findings so far)5.69.0https://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/core/-/issues/4012Contribution Page credit card expiry months are incorrectly offset when the t...2022-12-17T23:11:48ZbgmContribution Page credit card expiry months are incorrectly offset when the timezone is WhitehorseFound an interesting bug that only happens with users who have chose the America/Whitehorse timezone (-0700). It does not happen if we chose another similar timezone (America/Vancouver, America/Yellowknife, etc).
To reproduce on dmaster...Found an interesting bug that only happens with users who have chose the America/Whitehorse timezone (-0700). It does not happen if we chose another similar timezone (America/Vancouver, America/Yellowknife, etc).
To reproduce on dmaster / drupal7:
- login as the demo user
- change the user's timezone to America/Whitehorse
Then go to a contribution page:
https://dmaster.demo.civicrm.org/civicrm/contribute/transact?reset=1&id=2
![image](/uploads/ea61f948003f258501391a3c90e2a6e3/image.png)5.58.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/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/77Translation of message for multiple registrations missing2022-08-19T15:24:12Zthoni56Translation of message for multiple registrations missingIf you allow multiple registrations to an event, and select a number greater than 1 when you register (from the web view) the following string is displayed:
Fill in your registration information on this page. You will be able to ent...If you allow multiple registrations to an event, and select a number greater than 1 when you register (from the web view) the following string is displayed:
Fill in your registration information on this page. You will be able to enter the registration information for additional people after you complete this page and click "Continue".
This string can not be translated in Transifex (since it does not exist). The string there is (probably):
Fill in your registration information on this page. If you are registering additional people, you will be able to enter their registration information after you complete this page and click "Review your registration".
We are running 5.50.4 on Joomla.https://lab.civicrm.org/dev/core/-/issues/3508Translation for Search Kit 5.502023-01-28T19:10:08ZGuillaumeSorelTranslation for Search Kit 5.50It seems that 3 chains are not being translated in CiviCRM 5.50.1 when they actually are in Transifex. Following @bgm recommendation I exported and compiled the .mo file, named it search_kit.mo and uploaded it in the dedicated folder, h...It seems that 3 chains are not being translated in CiviCRM 5.50.1 when they actually are in Transifex. Following @bgm recommendation I exported and compiled the .mo file, named it search_kit.mo and uploaded it in the dedicated folder, here following WP structure.
2 of them also seem to be translatable in code ([https://lab.civicrm.org/dev/core/-/blob/master/ext/search_kit/Civi/Api4/Action/SearchDisplay/GetSearchTasks.php](https://lab.civicrm.org/dev/core/-/blob/master/ext/search_kit/Civi/Api4/Action/SearchDisplay/GetSearchTasks.php)):
line 72 `'title' => E::ts('Tag - Add/Remove Tags'),`
line 102 `$task['title'] = E::ts('Profile Update');`
But I couldn't find Update Contacts in Transifex. Could it be added?![Image_collée_à_2022-6-10_12-42](/uploads/eaec662c5d2365315c1ae27c9e9c70bf/Image_collée_à_2022-6-10_12-42.png)
![Capture_d_écran_2022-06-10_à_12.40.29](/uploads/e19a91c0ba801c505b79a98b236a8a2d/Capture_d_écran_2022-06-10_à_12.40.29.png)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/core/-/issues/3436Multivalue custom field as "tab with table" does not show values2022-05-25T08:20:07ZjmargrafMultivalue custom field as "tab with table" does not show valuesMultivalue custom field as "tab with table" does not show the tab content
Create a custom field group and set it to be multivalue with style Tab with Table.
Add a field.
Visit a contact record and click on the new tab.
C...Multivalue custom field as "tab with table" does not show the tab content
Create a custom field group and set it to be multivalue with style Tab with Table.
Add a field.
Visit a contact record and click on the new tab.
Create a new entry. The entry will not be showed in the table
I can see the following error message in the browser console:
```
Uncaught SyntaxError: unexpected token: identifier
jQuery 7
globalEval
globalEval
Ga
append
html
X
html
refresh https://crmtest.sci-d.de/sites/all/modules/civicrm/js/crm.ajax.js?rb98g8:310
jQuery 4
jquery.min.js:3:67
jQuery 7
refresh https://crmtest.sci-d.de/sites/all/modules/civicrm/js/crm.ajax.js?rb98g8:310
jQuery 4
```
CiviCRM Version: 5.46.35.50.0https://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/core/-/issues/3156Proposal: include translations in installation tar/zip2023-12-10T05:03:30ZalainbProposal: include translations in installation tar/zipOverview
----------------------------------------
The default language of CiviCRM is en_US. Other languages are not included in the standard installation package.
Looking at the countries and languages on stats.civicrm.org, we can see t...Overview
----------------------------------------
The default language of CiviCRM is en_US. Other languages are not included in the standard installation package.
Looking at the countries and languages on stats.civicrm.org, we can see that a big part of the community is using another language than en_US.
It would be more inclusive and respectful to include all languages in the standard installation package.
We should practice what we preach in our [code of conduct](https://civicrm.org/code-of-conduct): "_Communities mirror the societies in which they exist and positive action is essential to counteract the many forms of inequality and abuses of power that exist in society._"
Current behaviour
----------------------------------------
If you want to install CiviCRM in another language than en_US, you need to manually download the l10n file, and unpack it in the appropriate folder. This is an extra (technical) step for non en_US speakers.
Proposed behaviour
----------------------------------------
Include all languages in the standard installation package, or dynamically load the requested language during installation and upgrades.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/core/-/issues/3007Use of translation functions in menu logic is... odd.2023-11-07T00:43:20ZBradley TaylorUse of translation functions in menu logic is... odd.See this screenshot of the CiviCRM nav menu with the site locale set to Spanish:
![Screenshot_2021-12-24_at_15.10.04](/uploads/869b3e37c228d258c61ee6fe40867771/Screenshot_2021-12-24_at_15.10.04.png)
The bulk of the labels are translate...See this screenshot of the CiviCRM nav menu with the site locale set to Spanish:
![Screenshot_2021-12-24_at_15.10.04](/uploads/869b3e37c228d258c61ee6fe40867771/Screenshot_2021-12-24_at_15.10.04.png)
The bulk of the labels are translated, except for the middle "Hide menu". My first thought was that this was just down to a lack of translation, but it turns out things are not that simple.
The home menu items themselves are defined as hardcoded strings in `app/public/wp-content/plugins/civicrm/civicrm/CRM/Core/BAO/Navigation.php` (`CRM_Core_BAO_Navigation::buildHomeMenu`):
```
$item['child'] = [
[
'attributes' => [
'label' => 'CiviCRM Home',
'name' => 'CiviCRM Home',
'url' => 'civicrm/dashboard?reset=1',
'weight' => 1,
],
],
[
'attributes' => [
'label' => 'Hide Menu',
'name' => 'Hide Menu',
'url' => '#hidemenu',
'weight' => 2,
],
],
[
'attributes' => [
'label' => 'Log out',
'name' => 'Log out',
'url' => 'civicrm/logout?reset=1',
'weight' => 3,
],
],
];
```
Later in `CRM_Admin_Page_AJAX::formatMenuItems` the labels are passed through the `ts()` function:
```
if (!empty($props['label'])) {
$item['label'] = ts($props['label'], ['context' => 'menu']);
}
```
Some of the strings are used elsewhere (e.g. 'CiviCRM Home') and so are caught by the translation string extraction, and therefore get translated when passed into `ts()` as a variable `$props['label']`. This isn't the case for the string 'Hide Menu' however.
I suggest that `CRM_Core_BAO_Navigation::buildHomeMenu` is updated so that each label is passed through `ts()`. I'm not sure if this should include `['context' => 'menu']` to match `CRM_Admin_Page_AJAX::formatMenuItems`.
Best practice says that variables should not be passed as the first argument to `ts()`. However, `CRM_Admin_Page_AJAX::formatMenuItems` already works in this way, so it could be seen as a break to backwards compatiability to change this. If we don't change this, then there is the edge-case where a string would be double-translated, which could lead to unexpected results when combined with word replacement. So I'm not sure if this method should be updated or not.https://lab.civicrm.org/dev/core/-/issues/2917Replace "Oops" with more appropriate language2021-10-18T17:27:35ZhaystackReplace "Oops" with more appropriate languageOverview
----------------------------------------
The word "Oops" appears throughout CiviCRM. I suggest changing the strings in which it appears to be more appropriate to their context.
Example changes...
#### Already registered for a...Overview
----------------------------------------
The word "Oops" appears throughout CiviCRM. I suggest changing the strings in which it appears to be more appropriate to their context.
Example changes...
#### Already registered for an Event:
* "Oops. It looks like you are already registered for this event. [...]"
* "It looks like you are already registered for this event. [...]"
The "Oops" is jarring. It's not a mistake when I revisit the form to register someone else.
#### Event full:
* "Oops, it looks like there are currently no available spaces for [...]"
* "Unfortunately there are currently no available spaces for [...]"
It's not a mistake that "there are currently no available spaces". "Oops" suggests that it is.
Etc etc.5.44.0haystackhaystackhttps://lab.civicrm.org/dev/core/-/issues/2909Repair "Norwegian Bokmål"2021-11-04T17:48:03ZhaystackRepair "Norwegian Bokmål"Overview
----------------------------------------
"Norwegian Bokmål" is corrupted in [this file](https://github.com/civicrm/civicrm-core/blob/5db0bc3c1f54eaca4307f103a73bda596ae914d6/install/langs.php#L32) and [this one](https://github.c...Overview
----------------------------------------
"Norwegian Bokmål" is corrupted in [this file](https://github.com/civicrm/civicrm-core/blob/5db0bc3c1f54eaca4307f103a73bda596ae914d6/install/langs.php#L32) and [this one](https://github.com/civicrm/civicrm-core/blob/5db0bc3c1f54eaca4307f103a73bda596ae914d6/xml/templates/languages.tpl#L136).
Current behaviour
----------------------------------------
"Norwegian Bokmål" renders as "Norwegian BokmÃ¥l"
Expected behaviour
----------------------------------------
"Norwegian Bokmål" FTW.5.44.0haystackhaystackhttps://lab.civicrm.org/dev/core/-/issues/2880No meaningful translation possible for "Cancel "2021-10-02T05:28:27ZDetlev SieberNo meaningful translation possible for "Cancel "Overview
----------------------------------------
civicrm/CRM/Event/Form/SelfSvcUpdate.php contains a selection of "transfer" and "cancel" for an event participation. However, "cancel" is a very common word which cannot be translated in ...Overview
----------------------------------------
civicrm/CRM/Event/Form/SelfSvcUpdate.php contains a selection of "transfer" and "cancel" for an event participation. However, "cancel" is a very common word which cannot be translated in a meaningful way in this context (at least for many languages, e.g. german).
"cancel registration" remains meaningful in english, but works better in other languages.
This string already exists in CRM/Event/Form/Registration/ParticipantConfirm.php, so most probably transifex already has the translation available for most languages.
Changing the string from "Cancel" to "Cancel Registration" will help - especially since this string already exists in the code and is already5.43.0https://lab.civicrm.org/dev/translation/-/issues/71Full Month Names: avoid relying on the operating system's locale for translation2021-09-07T14:23:31ZbgmFull Month Names: avoid relying on the operating system's locale for translationThis kind of question comes up from time to time:
https://civicrm.stackexchange.com/questions/35468/date-in-english-even-when-page-is-set-to-french/40170
> "The date is always uses English month and day names regardless of the interfa...This kind of question comes up from time to time:
https://civicrm.stackexchange.com/questions/35468/date-in-english-even-when-page-is-set-to-french/40170
> "The date is always uses English month and day names regardless of the interface language. How do I fix this?"
The main issue is because currently translating the month name relies on the operating system. The non-English locale must be enabled so that `strftime` outputs the correct month name (ex: "janvier" not "January").
Most people somewhat control their hosting environment, and can enable it once they know how, but since the default CiviCRM date format uses `%B` (full month name), it gives a bad first impression. Considering we already have those strings in Transifex, it would be easy to just hardcode the list of months and translate using 'ts'.5.43.0bgmbgm