Repository navigation
Use Python versioning in msgfmt.py/pygettext.py #133319
Description
pygettexts/msgfmts versioning system is currently not useful.
cpython/Tools/i18n/pygettext.py
Line 155 in fac41f5
Line 37 in fac41f5
It has not been updated with changes and is of little informational value.
We have three options,
- Leave it as it is
- Remove it
- Replace/Update it to make it useful
1 = nothing changes.
2 Removing it completely would be misleading since pot files without "Generated-By: XXX" in the header are assumed to be generated by xgettext, so we would have to keep "Generated-By: pygettext".
I propose to do 3, as the version number can be useful, since files generated by different versions of the scripts can vary. For reference python-babel does this with their up-to-date version no. To do this I propose to use CPython versioning to make it easier, both for us and for users. This will avoid discussions down the line as to when should we bump the version, and it will make it easier for users to fetch the desired version, i.e. branch 3.15 for pygettext 3.15 and so on.
cc @tomasr8
Activity
sobolevn commentedon May 3, 2025
Is there anything wrong with the current version? Why do we need to change this? What if someone depends on the version number of
gettextis some way?StanFromIreland commentedon May 3, 2025
Not necessarily, but currently it is meaningless. A version number that was last updated 23 years ago does not serve much purpose, it is not helpful in differentiating the actual version of the tool.
It makes it useful, it actually informs the user about what version was used to generate it.
[Note: this issue is about the tools
pygettext.py/msgmt.pyand notLib/gettext.py]I do not see any realistic scenario where there would be a dependency on a version number, reiterating my previous points, it is useless in telling the version.
tomasr8 commentedon May 3, 2025
(answering mainly for pygettext)
I think if we agree that we want to have a version number, it should be informative. pygettext has not been significantly touched in a long time up until recently so the current version number was somewhat accurate, but in 3.14 there will be lots of bug fixes and overall improvements. Keeping the same version seems rather unhelpful to anyone that might care about it.
At the same time, we don't want to keep a versioning scheme separate from the Python version since pygettext (and msgfmt) are distributed with it, so there would be no meaningful distinction.
Alternatively we could remove the version altogether but that puts the burden on the user to keep track of which python version was used to generate the POT file.
encukou commentedon May 28, 2025
So, should the version be 3.14 until there's a similar 3.15-only fix?
Should the fixes be in What's New, so users can read about the meaning behind the numbers?
StanFromIreland commentedon May 28, 2025
It is introduced in 3.15 so let's leave it at 3.15, to prevent further confusion in the future since it is not backported.
The scripts are not in the stdlib (yet) though they will hopefully move under gettext at some point. From my understanding that would exclude them from Whats New though I am not against it.
encukou commentedon May 29, 2025
I think we need to take a step back.
Why would they track that?
If they need the Python version, the proposed change doesn't give it to them.
If they need a release number they can match against a changelog to see if it has some improvement or fix, the proposed change doesn't give it to them.
What problem is this solving that can't be solved by removing the version number, or even keeping it as it is?
StanFromIreland commentedon May 29, 2025
Users might track it because po files generated by different script versions can vary, especially now as new features are added.
I don't know of any reasons, I guess for gettext compatibility, but maybe that's just overkill?
Yes, but I would say that is beyond the scope of this issue, it is the same for the current version number. (Idea: We could keep a separate changelog.txt or something like that. Are there other
/toolsthat have a way to manage this?)IMO we still need some way of tracing what version was used to generate the file, removing the version number would not be of much benefit, then again it itself is not very information since it has not been updated when changes were made.
tomasr8 commentedon May 31, 2025
IIRC, most if not all of the fixes are in the changelog already :)
I'm not sure whether we should keep a version or remove it altogether but as a user, if a version number is provided, I'd expect it to be useful and something I can rely on.
However, starting from 3.14, the current version number will become quite misleading as there were many changes to pygettext during that time.
Perhaps deprecating and removing the version number altogether is ok. The only issue I see is the fact that for pygettext, we write the version number into the PO file. But I haven't come across any examples in practice where a consumer cares about what tool and version generated the PO file.
@serhiy-storchaka what is your preference?
serhiy-storchaka commentedon May 31, 2025
If it was a part of the stdlib, I would say that we should use the running Python version. But since it is in the Tools directory, there is a chance to run these scripts by different Python. Maybe we can ignore this case, I don't know.