make-messages.py should not touch POT-Creation-Date

[Marc Fargas]

Hi there,
When you run make-messages.py it changes POT-Creation-Date to now and leaves PO-Revision-Date alone.

Shouldn't it be just the opposite? Creation-Date should not be changed, while Revision Date should be set to now

Maybe I got it wrong anyway :)

[Malcolm Tredinnick]

I have a feeling we should just be passing --omit-header to the xgettext invocation (like we do for the javascript case) in make-messages.py. Current behaviour is certainly a small problem.

I'd hold off writing a aptch for this until after #5522 is resolved, though, since Jannis is in the process of moving everything around.

[Jannis Leidel]

Doesn't --omit-header just prevents the creation of " msgid "" " at the top of the file?

[Ramiro Morales]

Patch that preserves the POT-Creation-Date header of a .po file when makemessages applies the msguniq/msmerge process

[Jannis Leidel]

Hm, according to the gettext manual (​http://www.gnu.org/software/gettext/manual/gettext.html#Header-Entry) POT-Creation-Date will be filled out by xgettext and PO-Revision-Date "by the PO file editor when you save the file". In other words: PO-Revision-Date doesn't have anything to do with collection/updating translation strings but with the actual translation by the translators, as in "When was this file revised last time?".

As long as we use the *.po files for the same purpose as *.pot files, POT-Creation-Date is the field that is updated automatically.

I'm changing this to someday/maybe since we shouldn't redefine the meaning of gettext's header fields.

[Claude Paroz]

IMHO this is clearly a wontfix issue, as jezdez stated. It is perfectly legitimate to update POT-Creation-Date each time a po file is updated.

[Mariusz Felisiak]

Daniyal, Can you take this to DevelopersMailingList to reach a wider audience and see what other think? see comment.

​PR

#33056 was a duplicate.

[Daniyal Abbasi]

Sure Mariusz. I've started the discussion on the mailing list!
​Link

[Mariusz Felisiak]

Reopening. Discussion in DevelopersMailingList seems to reached a consensus.

[Ad Timmering]

Hi @Daniyal - would love to see this implemented. I think the last request was to add tests - to which you asked a question (ticket:33056#comment:3) on where to put them. Do you still have time to work on tests, and/or are you still waiting for a reply to that?

Just quoting here in case someone more knowledgeable comes around and can pitch in:
Daniyal wrote ticket:33056:

Thanks for accepting this. I'm not sure where the tests should live. Should the tests go in the BasicExtractorTests or should they be in a separate class in the tests.i18n.test_extraction?
Moreover, I could not find any tests for the write_po_file method of the makemessages Command class. Let me know how I shall proceed!

[Daniyal Abbasi]

Hey
Yes I do have the time to work on this. I'm waiting on some guidance on how I should be incorporating the tests for the same!

[Ad Timmering]

Great. I would probably suggest you pick whatever place you think is best for the tests for now and add them to the PR, so you can remove the "Needs tests" flag - which will then trigger someone coming in for review. (As you will have seen the Django team just pushed 4.0.0 alpha 1 so are probably a bit occupied at the moment).

It looks like the tests in test_extraction are broken out quite granularly over multiple classes, so personally I would probably suggest a separate test class.

[Daniyal Abbasi]

Sure. For now I've added a test in the test_extraction.BasicExtractorTests class itself.

[Mariusz Felisiak <felisiak.mariusz@…>]

In 4bfe8c0:

Fixed #6106 -- Prevented makemessages from changing .po files when up to date.

Co-authored-by: Daniyal Abbasi <abbasi.daniyal98@…>

[אורי]

#34318