T3435 mycompassion child information translations - #2144
Open
danpa32 wants to merge 4 commits into
Open
Conversation
AdvancedTranslatable.get_list() (used for e.g. a child's favorite
subjects/hobbies on the MyCompassion portal) joins the last two values
with a hardcoded code-domain string, _("and") - but the
advanced_translation module shipped zero French/German/Italian
translations at all (only Nordic languages), so non-English users saw
e.g. "Art, Mathématiques and Education physique" - correctly
translated items, English conjunction.
Add fr_CH/de/it.po with just the two code strings this module
actually uses ("and", "Unknown" from the same get_list()/get_date()
pattern) - not attempting to translate the rest of this untouched
module as part of this fix.
…lations ir.advanced.translation.get() fell back to _(src) (the English source) when no translation row existed for the term, but returned a hard "" when a row existed for the language yet the specific requested gender/plural field was left empty - e.g. "Ma mère travaille comme ." on the MyCompassion portal, where a French row existed with male_singular filled in but female_singular blank. Fall back to _(src) in that case too, matching the no-row behavior, so an incomplete translation degrades to English instead of silently disappearing. The underlying missing French text itself is a data gap in that table, not something this code change can supply.
CompassionProject._get_materials() (backing typical_wall/roof/floor_ material, shown on the MyCompassion portal's "My center" tab) had 15 hardcoded English labels never wrapped in _(), so they were never extractable as translatable strings - e.g. "Construction typique des maisons: Brick, block and cement" always showed the English label regardless of the viewer's language. Wrap the labels with _() and add the French/German/Italian translations to the module's existing i18n files, inserted by hand at their correct alphabetical position rather than through a full po_build.py rebuild - the module currently has ~230+ pre-existing untranslated strings per language and a handful of stale entries unrelated to this change; a full rebuild would have entangled this narrow fix with that unrelated, much larger pre-existing gap.
…load
sbc_compassion's _render_qweb_pdf override merges scanned correspondence
letters via _merge_pdfs() without a handle_error callback, so a single
unreadable/corrupted sponsor_letter_scan attachment (or one with an
unrecognized mimetype, or one that fails image-to-PDF conversion)
raised UserError("Odoo is unable to merge the generated PDFs.") -
surfaced to the portal as a 400 Bad Request, blocking the download of
every other letter in the batch too.
Guard the per-attachment conversion and pass a tolerant handle_error
to _merge_pdfs() that logs and skips the bad stream instead, so the
customer still gets every other letter that could be produced.
Confidence Score: 4/5The correspondence-report change can return an empty document for a normal recovery scenario, so it needs correction before merge. A focused runtime harness exercised both unrecognized and exception-throwing scan conversions, compared them with the normal no-scan fallback, and reproduced the omission reliably. Files Needing Attention: sbc_compassion/models/ir_actions_report.py, especially the fallback-ID calculation after skipped scan conversions.
 T-Rex LogsWhat T-Rex did
|
![greptile-apps[bot]](https://avatars.githubusercontent.com/in/867647?s=60&v=4){kind=small}
| continue | ||
| streams.append(stream) | ||
|
|
||
| without_scan_ids = set(res_ids) - {att.res_id for att in attachments} |
There was a problem hiding this comment.
without_scan_ids is calculated from every matching attachment, including attachments skipped because to_pdf_stream() returned None or raised an exception. When every selected letter has an unreadable or unsupported scan, no IDs are sent to the QWeb fallback and _merge_pdfs() receives no usable streams, returning a successful zero-page PDF. Track only IDs whose scans converted successfully, then render all remaining selected letters through QWeb.
Artifacts
Focused correspondence PDF failure harness source
- Minimal Odoo stand-ins import the unchanged production method and exercise the no-attachment baseline plus all-failed attachment conversions, establishing the compared execution scope.
Baseline QWeb fallback execution log without scan attachments
- The baseline command selected IDs 101 and 102 with no scan attachments and recorded `FALLBACK_CALLS [[101, 102]]`, showing the requested letters would normally be rendered.
Failed scan conversion execution log returning a zero-page PDF
- The failure command made all selected scan conversions return `None` or raise and recorded no fallback, an empty merge input, and a successful PDF with `/Count 0`, confirming the defect.
Captured focused harness source output
- The captured source-display command records the exact authored harness used for the baseline and failure executions, providing reproducible test evidence.
Member
There was a problem hiding this comment.
This is a valid comment that needs to be fixed.
ecino
requested changes
Sep 2, 2026
| continue | ||
| streams.append(stream) | ||
|
|
||
| without_scan_ids = set(res_ids) - {att.res_id for att in attachments} |
Member
There was a problem hiding this comment.
This is a valid comment that needs to be fixed.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
T3435 — MyCompassion: child information page translation issues + letters download error
Related PR
Original report
Quality test failure on the MyCompassion portal's "Child information" page: several pieces of information have errors in some languages, especially french.
Known separate/open issue — not fixed
ir.advanced.translation.get()fell back to_(src)(English) when no translation row existed for a term, but returned a hard""when a row did exist for the language but the specific requested gender/plural field (e.g.female_singular) was left empty — exactly the "Ma mère travaille comme ." case, where a French row existed withmale_singularfilled in butfemale_singularblank. Fixed to fall back to_(src)in that case too, so an incomplete translation degrades to English instead of disappearing. Note: the actual missing French text for this specific occupation is a data gap in that table, not something this code fix can supply — someone needs to fill in the actualfemale_singularvalue for whichever source string this is which bring the known separate issue. This fix only prevents the blank symptom for its own scenario (translation row exists, specific field blank) going forward; the actual French text for whatever specific occupation values are missing is still absent from their.advanced.translationtable and needs a data fix, not a code fix.How to test manually
advanced_translation,child_compassion,sbc_compassionwith-u ... --i18n-overwrite.