l10n: Automate License Headers and Metadata in generate_po_files.py

[pareshjoshij]

Is your feature request related to a problem? Please describe.
Yes. Currently, when running scripts/l10n/generate_po_files.py, the generated .pot and .po files are incomplete in two frustrating ways:

1. Missing License Header: The files are created without the standard # holidays license block. This causes the check-license-headers pre-commit hook to fail immediately, requiring manual copy-pasting to fix.
2. Incomplete Metadata: The header metadata is bare-bones. Fields like Language, Last-Translator, Language-Team, and MIME-Version are missing

Describe the solution you'd like
I am thinking we could update the generate_po_files.py script to automate this fully. The script could:

1. Read the License dynamically: detailed in docs/file_header.txt and inject it into the header of every generated file.
2. Add Translator Placeholder: Automatically set the Last-Translator field to a placeholder (e.g., YOUR NAME ) or populate it from git config if appropriate.
3. Standardize Metadata: Automatically populate fields like Language (detected from the folder path) and Last-Translator so the files are "commit-ready" immediately after generation.

Describe alternatives you've considered

• Manual Editing: The current workflow requires opening every new .po file and pasting the header from an existing file, which is error-prone.
• Auto-filling from Git Config: I considered pulling the name/email from git config, but a placeholder might be better to ensure contributors consciously opt-in to sharing their details.

Additional context

[pareshjoshij]

@KJhellico , I have updated the script to fully automate the license headers and metadata. It now produces "commit-ready" files that pass the pre-commit hooks.

One thing to note: I switched the script to derive the country name from the filename instead of the Python class. This ensures the script runs reliably on all operating systems without encoding issues.

This results in slight changes to the header comments for a few countries:

• Cocos (Keeling) Islands... → # Cocos Islands...

• Hong Kong... → Hongkong...

• Timor-Leste... → Timor Leste...

Since these are just comments, I assumed the stability improvement was worth it, but I wanted to confirm this is acceptable.

[PPsyrius]

Hmm, you might want to add exception for those ones as they're written that way in the ISO records Hong Kong, Coco (Keeling) Islands, Timor-Leste

[pareshjoshij]

Hmm, you might want to add exception for those ones as they're written that way in the ISO records Hong Kong, Coco (Keeling) Islands, Timor-Leste

@PPsyrius You are absolutely right about the ISO names—they should be accurate.

I looked through the changes, and it turns out there are quite a few more than just those three (e.g., "Chinese" vs "China", "United States of America", and names with accents like "Curaçao").

I Tried using AST parsing to solve this automatically, but it turns out that won't work either. For example, china.py sets country = "CN", not "Chinese". So even with static analysis, we wouldn't get the correct legacy headers like
#Chinese holidays..

[KJhellico]

I don't quite understand which country names you are referring to?

[pareshjoshij]

@KJhellico Sorry for the confusion. I am referring to the generated comments in the .po files.

I switched the script to derive the country name from the filename.

This works for most, but I am "stuck" on a few legacy names where the filename doesn't match the old header exactly:

• china.py → generates #China holidays en_US localization. instead of Chinese

same for

• curacao.py → generates # Curacao instead of # Curaçao

• united_states.py → generates # United States instead of # United States of America

And many more

[KJhellico]

For this, I would recommend using text from docstring (look at l10n_helper.py).