Europass import: skill headings follow the interface language, not the language the file says the CV is in #641

New issue

Closed

opened 2026-10-01 10:48:35 +00:00 by tiagoagueda · 0 comments

tiagoagueda commented

2026-10-01 10:48:35 +00:00

Owner

Found on 2026-09-29 in a read-only review of postulo at 95348908d, reading how the Europass readers name what they create and running them with the plugin's own catalogues compiled into a scratch folder.

The skill groups an import creates (Digital, Organisational, Communication, Job-related, Other, Management and leadership) are headings on the person's CV. The readers resolve them with str(label), which gives the language of the request. The file states its own language; the reader stores it as record.locale, the import writes it to record_language, and the Candidate reader already names languages in it. So one import mixes two languages whenever the person reads Postulo in a language other than the one their CV is written in.

Related to #235 (closed), which reported "fixed English words (…) even for a Portuguese record". Its fix made the headings translatable, but tied them to the reader's language, not to the record's: a Portuguese record imported by somebody whose interface is English still gets "Job-related".

Checked again on 2026-10-01 against main at 0a5cad587: still present, at plugins/europass/reader.py:468 and :738 and plugins/europass/candidate.py:574, :586 and :600.

Where:
- plugins/europass/reader.py:592 and :862: record.skill_groups.append({"name": str(label), …}), with the labels in SKILL_HEADINGS (:93-106), whose comment says the name "is a heading on somebody's CV".
- plugins/europass/candidate.py:573, :585 and :599: str(DIGITAL), str(label), str(JOB_RELATED).
- Compare plugins/europass/candidate.py:331-334 (_language_name): with translation.override(cv_language): return str(info["name_translated"]).
What happens: with the interface in English and a file whose locale is pt, the old-format reader returns the headings Digital and Job-related, and the Candidate reader returns Digital and Organisational beside a language named Inglês. The career is saved with record_language pt and prints English section headings on a Portuguese CV. With the interface in Portuguese and the same file, the headings are Digitais and Relacionadas com a profissão. The reverse case, a Portuguese interface and an English CV, puts Portuguese headings on an English CV.
Why it matters: the person has to rename each group by hand after importing, which is the work #235 set out to remove, and nothing on the review page tells them the headings are in the wrong language.
Fix: one helper in the package, used by all five call sites and by _language_name: resolve the label under translation.override(<language>), where the language is the offered language closest to record.locale (resume.translating.best_match over settings.LANGUAGES, so that pt finds pt-pt), and the active language when the file states none or none matches.
Tests: test_a_skill_heading_is_written_in_the_language_being_read (tests/test_europass.py:663) only checks that the labels are lazy and the result is a str, because the suite runs without .mo files; it cannot tell which language was used.

Done when

A test in tests/test_europass.py and one in tests/test_europass_candidate.py read a file whose locale is pt while English is active, with the plugin's catalogue available to the test (compiled in a fixture, or the helper's language choice asserted directly), and find the Portuguese heading. Both fail today.
The same tests read a file with no locale and find the heading in the active language.

Found on 2026-09-29 in a read-only review of postulo at 95348908d, reading how the Europass readers name what they create and running them with the plugin's own catalogues compiled into a scratch folder. The skill groups an import creates (Digital, Organisational, Communication, Job-related, Other, Management and leadership) are headings on the person's CV. The readers resolve them with `str(label)`, which gives the language of the request. The file states its own language; the reader stores it as `record.locale`, the import writes it to `record_language`, and the Candidate reader already names languages in it. So one import mixes two languages whenever the person reads Postulo in a language other than the one their CV is written in. Related to #235 (closed), which reported "fixed English words (…) even for a Portuguese record". Its fix made the headings translatable, but tied them to the reader's language, not to the record's: a Portuguese record imported by somebody whose interface is English still gets "Job-related". Checked again on 2026-10-01 against `main` at `0a5cad587`: still present, at `plugins/europass/reader.py:468` and `:738` and `plugins/europass/candidate.py:574`, `:586` and `:600`. - **Where:** - `plugins/europass/reader.py:592` and `:862`: `record.skill_groups.append({"name": str(label), …})`, with the labels in `SKILL_HEADINGS` (`:93-106`), whose comment says the name "is a **heading on somebody's CV**". - `plugins/europass/candidate.py:573`, `:585` and `:599`: `str(DIGITAL)`, `str(label)`, `str(JOB_RELATED)`. - Compare `plugins/europass/candidate.py:331-334` (`_language_name`): `with translation.override(cv_language): return str(info["name_translated"])`. - **What happens:** with the interface in English and a file whose locale is `pt`, the old-format reader returns the headings `Digital` and `Job-related`, and the Candidate reader returns `Digital` and `Organisational` beside a language named `Inglês`. The career is saved with `record_language` `pt` and prints English section headings on a Portuguese CV. With the interface in Portuguese and the same file, the headings are `Digitais` and `Relacionadas com a profissão`. The reverse case, a Portuguese interface and an English CV, puts Portuguese headings on an English CV. - **Why it matters:** the person has to rename each group by hand after importing, which is the work #235 set out to remove, and nothing on the review page tells them the headings are in the wrong language. - **Fix:** one helper in the package, used by all five call sites and by `_language_name`: resolve the label under `translation.override(<language>)`, where the language is the offered language closest to `record.locale` (`resume.translating.best_match` over `settings.LANGUAGES`, so that `pt` finds `pt-pt`), and the active language when the file states none or none matches. - **Tests:** `test_a_skill_heading_is_written_in_the_language_being_read` (`tests/test_europass.py:663`) only checks that the labels are lazy and the result is a `str`, because the suite runs without `.mo` files; it cannot tell which language was used. ## Done when - A test in `tests/test_europass.py` and one in `tests/test_europass_candidate.py` read a file whose locale is `pt` while English is active, with the plugin's catalogue available to the test (compiled in a fixture, or the helper's language choice asserted directly), and find the Portuguese heading. Both fail today. - The same tests read a file with no locale and find the heading in the active language.

tiagoagueda added this to the 0.6.0 milestone

2026-10-01 10:48:35 +00:00

tiagoagueda added the

bug

tier

internationalisation

labels

2026-10-01 10:48:35 +00:00

tiagoagueda referenced this issue

2026-10-03 01:59:02 +00:00

Your career: spoken languages chosen by code, with every language's name built in for every document language #689

tiagoagueda referenced this issue from a commit