Translation issueshttps://lab.civicrm.org/dev/translation/-/issues2020-08-11T11:18:57Zhttps://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.txthttps://lab.civicrm.org/dev/translation/-/issues/8Multilingual installation with logging enabled gives error when custom field ...2020-07-14T14:56:53ZtbuytaerMultilingual installation with logging enabled gives error when custom field is changedLogging of custom fields on a multilingual installation does not work, which makes it impossible to view changes if one of the changes is a custom field.
Steps to reproduce:
1. install a fresh CiviCRM installation: 5.0 (the issue also ...Logging of custom fields on a multilingual installation does not work, which makes it impossible to view changes if one of the changes is a custom field.
Steps to reproduce:
1. install a fresh CiviCRM installation: 5.0 (the issue also existed in versions before)
2. enable **Multiple Languages Support** on http://example.org/civicrm/admin/setting/localization?reset=1
3. enable **logging** on http://example.org/civicrm/admin/setting/misc?reset=1
4. change a custom field of a contact
5. view the changelog of that contact and click on the change
This results in follwing Database error:
> Database Error Code: Table 'databasename.log_civicrm_custom_group_en_US' doesn't exist, 1146
> Additional Details:
> Array
> (
> [callback] => Array
> (
> [0] => CRM_Core_Error
> [1] => handle
> )
>
> [code] => -18
> [message] => DB Error: no such table
> [mode] => 16
> [debug_info] => SELECT id, title FROM `databasename`.log_civicrm_custom_group_en_US WHERE log_date <= '2018-04-09 17:40:29' AND table_name = 'civicrm_value_constituent_information_1' ORDER BY log_date DESC LIMIT 1 [nativecode=1146 ** Table 'databasename.log_civicrm_custom_group_en_US' doesn't exist]
> [type] => DB_Error
> [user_info] => SELECT id, title FROM `databasename`.log_civicrm_custom_group_en_US WHERE log_date <= '2018-04-09 17:40:29' AND table_name = 'civicrm_value_constituent_information_1' ORDER BY log_date DESC LIMIT 1 [nativecode=1146 ** Table 'databasename.log_civicrm_custom_group_en_US' doesn't exist]
> [to_string] => [db_error: message="DB Error: no such table" code=-18 mode=callback callback=CRM_Core_Error::handle prefix="" info="SELECT id, title FROM `databasename`.log_civicrm_custom_group_en_US WHERE log_date <= '2018-04-09 17:40:29' AND table_name = 'civicrm_value_constituent_information_1' ORDER BY log_date DESC LIMIT 1 [nativecode=1146 ** Table 'databasename.log_civicrm_custom_group_en_US' doesn't exist]"]
> )
*I replaced the actual database name with 'databasename' in the error message above*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/46Proposal - languages from urls2020-05-26T20:15:41ZeileenProposal - languages from urlsI want to propose an addition to our basic edit forms
1) in CRM_Core_Form -add a property language and in generic preProcess look for this property in the url & set it on the form
2) in any APIv4 calls at the form layer use this value t...I want to propose an addition to our basic edit forms
1) in CRM_Core_Form -add a property language and in generic preProcess look for this property in the url & set it on the form
2) in any APIv4 calls at the form layer use this value to setLanguage, if exists, on the api call (this is mostly a principle of intent at this stage)
What does this achieve? Basically it allows me to take action in an extension. Currently the MessageTemplate form uses apiv4 to retrieve and save message templates. I can listen to these calls in civi_data_translate_civicrm_apiWrappers and intervene - retrieving the values relevant to the specific language, if appropriate. This is a pretty tough intervention to do without any core support, and fairly simple with a small change to core + an agreement as to how we prefer to use the api going forwards
https://github.com/eileenmcnaughton/civi-data-translate/blob/master/civi_data_translate.php#L187
Next steps - I would look to convert the EntityFormTrait to use apiv4 to create a generic template / model for how this should be done. (I would need to set api version as a parameter on the form as I realise extensions may use this trait for entities with no v4 api as yet.)
@bgm @colemanw @seamuslee @tottenhttps://lab.civicrm.org/dev/translation/-/issues/31civicrm_mailing_component name is limited to 64 charaters, missing label2020-05-18T00:29:46Zbgmcivicrm_mailing_component name is limited to 64 charaters, missing labelThe `civicrm_mailing_component` has a `name` column limited to varchar(64). This name column is exposed to users, and extracted for translation.
However, in some languages the translation for some of the strings, such as "resubscribe me...The `civicrm_mailing_component` has a `name` column limited to varchar(64). This name column is exposed to users, and extracted for translation.
However, in some languages the translation for some of the strings, such as "resubscribe message" can be over 64 characters, causing the CiviCRM installer to fail.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/translation/-/issues/24On New Event, allow translations to be entered before first save2019-03-08T17:14:15ZJoeMurrayOn New Event, allow translations to be entered before first saveCurrently, on multilingual sites, it is only possible to enter text for the current language on the first form presented for Events > New Event (civicrm/event/add?reset=1&action=add). After that form is saved, translations can be entered...Currently, on multilingual sites, it is only possible to enter text for the current language on the first form presented for Events > New Event (civicrm/event/add?reset=1&action=add). After that form is saved, translations can be entered for any translatable field on any tab.
Proposed enhancement: allow translations to be entered for the text fields on the first form as well, prior to first save.
This enhancement idea is currently unfunded.https://lab.civicrm.org/dev/translation/-/issues/7Update Localizing Documentation (Drupal configurations)2019-01-14T15:52:50ZshaneonabikeUpdate Localizing Documentation (Drupal configurations)There is some special mapping configurations for multilingual Drupal sites to map the proper languages between Drupal and CiviCRM. Is there a way I could update the existing documentation?
https://docs.civicrm.org/user/en/latest/the-civ...There is some special mapping configurations for multilingual Drupal sites to map the proper languages between Drupal and CiviCRM. Is there a way I could update the existing documentation?
https://docs.civicrm.org/user/en/latest/the-civicrm-community/localising-civicrm/
`"Inherit CMS language" and regional translations (ex: fr_CA)
If you have a multi-lingual site and you are using the "inherit CMS language" configuration option, but wish to, for example, use fr_CA instead of the default fr_FR (for French), you can define a constant in your "civicrm.settings.php" to override the default behavior.
See CRM-9558 for more information.
define('CIVICRM_LANGUAGE_MAPPING_FR', 'fr_CA');
`
From https://wiki.civicrm.org/confluence/display/CRMDOC/i18n+Administrator%27s+Guide%3A+Using+CiviCRM+in+your+own+languagehttps://lab.civicrm.org/dev/translation/-/issues/17RTL issue: form label should be at right, and their input fields, at the left.2018-10-22T18:50:53ZcalbasiRTL issue: form label should be at right, and their input fields, at the left.I'm not sure if I should create this issue here or at civicrm core repository. Doing here, as first step to make a Merge Request at Github repository.
I'm attaching an screenshot of the wrong output. It's wrong, at least, in Arabic, but...I'm not sure if I should create this issue here or at civicrm core repository. Doing here, as first step to make a Merge Request at Github repository.
I'm attaching an screenshot of the wrong output. It's wrong, at least, in Arabic, but I suppose it's wrong for all other RTL languages. It's, too, a basic feature, because forms are used everywhere...
This issue happens at custom profile but also at system/default profiles.![Captura_2018-09-13_17-20-29](/uploads/3bdba1980909fd4fb5a0ea96979bd24d/Captura_2018-09-13_17-20-29.png)
![Captura_2018-09-13_17-17-19](/uploads/e6b36a362c68005b37c0a74e0d106194/Captura_2018-09-13_17-17-19.png)