Hello, and thanks for your contribution!

I'm a bot set up to make sure that the project can legally accept your contribution by verifying you have signed thePSF contributor agreement (CLA).

Our records indicate we have not received your CLA. For legal reasons we need you to sign this before we can look at your contribution. Please followthe steps outlined in the CPython devguide to rectify this issue.

If you have recently signed the CLA, please wait at least one business day
before our records are updated.

You cancheck yourself to see if the CLA has been received.

Thanks again for your contribution, we look forward to reviewing it!

My patches now successfully pass all tests. Is there anything else I should do?

The GNUmsgfmt treats duplicated keys as conflicts. Silently ignoring can lead to bugs.

We touched upon this a bit before:#10875 (comment) We could either fix it now or leave it for a followup PR. Which one would you prefer?

If the solution is non-trivial, it can wait. I'm just worried that it may require rewriting the tests added here.

If the solution is non-trivial, it can wait. I'm just worried that it may require rewriting the tests added here.

It would be rather simple to test if a new msgid already exists and raise an exception. But GNU msgfmt gives more: the exact file and line of the first occurrence and of the second one. That part will require a non trivial work... For the tests part, the only change would be that the current merge should abort (the"" msgid is present in both files), and that we should provide a copy of the second PO file without its header to obtain the current merge.

Ok the tests for the infile/outfile computations are passing.

Back to the duplicate ids question, it should not be that hard:

• add alid variable inprocess to record thelno value when a msgid is found
• pass thatlid along withinfile to theadd method and store tuples(msgstr, infile, lid) in themessages dict
• inadd, test whether a key is present before adding a new record and abort with a message - we now have the file and line number of the previous and current id
• ingenerate replace the 2 occurrences ofmessages[id] withmessages[id][0]

For the tests, the currenttest_both_with_outputfile should fail because the empty msgid is duplicated in the second file. We should just add a new PO file without header to have a passing test.

This would allow a better GNU msgfmt compatibility.

Do you think that this should go into this PR or into a new one?

Started working on that point, and I fell not on technical but behavior questions.msgfmt chokes if more than one file contains a header, but the header is the only place where the encoding of the PO file can be declared. As GNU gettext contains a number of auxiliary programs that can help to manage a set of PO files this behavior is nice, butmsgfmt.py has not them and it would be a serious limitation. My opinion is thatmsgfmt.py should accept a header in every file but only store the first (or the last?) in the resulting MO file. That way users could process PO files with other encodings than UTF-8. But I would love to have other opinions on that...

If you think that this points requires a longer discussion, or that it should be discussed on a different place, then it means that we should handle it in a followup PR. If you think that just making a special case for the header is reasonable, then I could implement it in a couple of days.

There will be a lot of conflicts with my hashing pr… this pr changes quite a lot. What do we want to do?

I was not very happy to reverse to parameters order ofcompile_messages because I thought it could disturb users if they were used to the precedent order. If there are concurrent PR (which I was absolutely not aware), this is clearly a blocking point. IMHO the only possible ways are to sequence the PR if there are only two of them, or to revert the modification ofcompile_messages, and use a different function to compile many PO files. I am sorry if I have made a mistake here. It is my first PR and I really do not know the usages. Anyway are there other sources of conflict?

I guess it is up to@serhiy-storchaka who is the expert for msgfmt if I remember correctly as to what order we want these. (Who will have to deal with the conflicts)

Before proceeding with this issue, we must solve other issues:--exclude-file,--omit-header, use the source file encoding. I think they are important for this issue.

If I correctly understand, I shall just leave this PR as it is now, without even worrying for conflicts, and only come back when the other issues will be fixed. Not really a problem, but do not forget to wake me when it will be the time to fix the conflicts... Anyway it is far from a very important one even for me as I have understood that I had to use a private copy for my own project. I have already been working that way for more that 6 years after all... Stupid me again! If there are conflicts with other changes, it means that those changes have been merged and that the conflicts are to be resolved... I just shall keep on coming here from time to time and fix them when I see them. But unless being advised to act differently I shall not try to handle the duplicate ids question before the PR is merged in its current state to avoid adding other sources of possible conflicts.

All commit authors signed the Contributor License Agreement.