Translation issueshttps://lab.civicrm.org/dev/translation/-/issues2023-11-09T18:52:41Zhttps://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/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.