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
Comment #2
gábor hojtsyFix markup.