Repository navigation
Implement extraction and translation of static YAML authz metadata (Internationalization) #432
Description
Description
The authz schema contains the display names and descriptions shown for static roles, permissions, and permission categories. Currently, applications contribute these strings via YAML files.
Problem
Because these strings are defined in YAML, standard Python and JavaScript extraction tools cannot find them automatically. This leaves them out of the standard localization workflow.
Proposed Solution
Implement the ADR to bring static authorization metadata into the existing OEP-58 translation process. The goal is to make user-facing text translatable while keeping stable system identifiers intact.
Acceptance Criteria
- Configure an extraction mechanism to parse YAML files and isolate schema fields as independent, translatable messages.
- Route the extracted messages through the
openedx-translationspipeline and Atlas. - Update the API to evaluate the requested language and return the correctly translated strings (display names and descriptions).
- Write tests confirming the API serves the correct language and that stable identifiers remain completely unchanged in all responses.
Proposed ADR: #424
Metadata
Metadata
Assignees
Labels
Type
Projects
- Status
Activity
[-]8. Implement extraction and translation of static YAML authz metadata (Internationalization)[/-][+]Implement extraction and translation of static YAML authz metadata (Internationalization)[/+]efortish commentedon Oct 1, 2026
Opened a PR covering the extraction side of this (acceptance criteria 1-2): #509
A management command (
extract_schema_translations) discovers every schema resource via the already-mergedSchemaDiscoverystep, parses the YAML directly, and generates a Python module with onepgettext()call perdisplay_name/descriptionfield, wired into theextract_translationsMakefile target ahead ofi18n_tool extract.Criteria 3-4 (the API returning translated strings, and tests confirming that) aren't buildable yet: the schema loader/model layer that would read these fields at runtime (#475-478) and the role/permission catalog API itself (#508, still just an ADR) don't exist in main. The extraction command intentionally doesn't depend on any of that unmerged pipeline, it only needs the raw YAML fields, so it's usable and testable independent of when those land.
Will file a follow-up issue for criteria 3-4 once the loader and catalog API are further along, and link it here.