Problem/Motivation

Both L10nExporter classes (l10n_community and l10n_packager) take the newest translation changed timestamp from the export query result and pass it to date() for the PO-Revision-Date header. The database returns the column as a string, and the exporters declare strict types, so any export with at least one translation throws:date(): Argument #2 ($timestamp) must be of type ?int, string given

This breaks the download of translations from the UI and stops the packager on the first language it packages. Before #3621196 the exporters read a column that does not exist, so the value was always empty and the header kept its placeholder; since the real timestamp is used, every export with translations fails.

Steps to reproduce

Proposed resolution

Cast the timestamp to int in both exporters.

The packager kernel test added in #3621247: Only one language can be packaged per release exports a file with translations and fails with this error before the change.

Remaining tasks

User interface changes

API changes

Data model changes

LLM disclosure

LLM was used to find, diagnose explain and fix this issue. With human review.

Comments

gábor hojtsy created an issue. See original summary.

gábor hojtsy’s picture

Issue summary: View changes
Status: Active » Fixed

Fix markup.

Now that this issue is closed, review the contribution record.

As a contributor, attribute any organization that helped you, or if you volunteered your own time.

Maintainers, credit people who helped resolve this issue.

  • 480f2a52 committed on 3.0.x
    fix #3621248: Exporting a .po file fails with a TypeError on the PO-...

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.