You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
pygettext: Wrapping to width is not implemented for msgids #130703
changed the title [-]pygettext: `width` is not implemented for msgids[/-][+]pygettext: Wrapping to `width` is not implemented for msgids[/+]on Feb 28, 2025
‘-w number’ ¶
‘--width=number’
Set the output page width. Long strings in the output files will be split across multiple lines in order to ensure that each line’s width (= number of screen columns) is less or equal to the given number.
‘--no-wrap’
Do not break long message lines. Message lines whose width exceeds the output page width will not be split into several lines. Only file reference lines which are wider than the output page width will be split.
but my wrap method is not correct, I cannot simply wrap at x chars.
Normalize needs to be modified to wrap when over width
The xgettext implementation is much much more complex. It uses a complex function splitting long lines from other library (I think it is something between textwrap and PyICU; it is locale-depending). It ensures that format directives are not split (it needs to parse printf-like and format()-like format strings for this). It splits long "words". It takes into account the width of characters.
I do not think pygettext needs this. I am not even sure that it needs more fancy algorithm than simply splitting the string by \n -- in most cases the resulting lines have reasonable size, and terminals are wider today.
I have implemented a modified version of pybabels wrapping implementation, which I can tell you, does not include thoose features, and still behaves like xgettext.
If the much more popular pybabel (than pygettext) uses it, then there must be a reason for it, and it must work, no?
Yes, but since it's in the Tools folder, I think it's easier not to change older versions. Even if it was partially implemented, it's a new feature in some sense.
If the much more popular pybabel (than pygettext) uses it, then there must be a reason for it, and it must work, no?
Not to disparage babel here (it's a great library and I frequently contribute to it) but it does have its own issues so I would advise against blindly copying whatever code babel is using
I am not even sure that it needs more fancy algorithm than simply splitting the string by \n -- in most cases the resulting lines have reasonable size, and terminals are wider today.
I think allowing splitting by whitespace (assuming it can be done safely) would be very useful. From my own experience working on a web-based project, we have lots of long strings without newlines because they get rendered by the browser where you normally don't use explicit \n.
Activity
[-]pygettext: `width` is not implemented for msgids[/-][+]pygettext: Wrapping to `width` is not implemented for msgids[/+]serhiy-storchaka commentedon Feb 28, 2025
Does
xgettextwrap msgids?StanFromIreland commentedon Feb 28, 2025
It wraps everything
but my wrap method is not correct, I cannot simply wrap at x chars.
Normalize needs to be modified to wrap when over width
serhiy-storchaka commentedon Mar 2, 2025
The
xgettextimplementation is much much more complex. It uses a complex function splitting long lines from other library (I think it is something betweentextwrapandPyICU; it is locale-depending). It ensures that format directives are not split (it needs to parse printf-like andformat()-like format strings for this). It splits long "words". It takes into account the width of characters.I do not think
pygettextneeds this. I am not even sure that it needs more fancy algorithm than simply splitting the string by\n-- in most cases the resulting lines have reasonable size, and terminals are wider today.StanFromIreland commentedon Mar 2, 2025
I have implemented a modified version of pybabels wrapping implementation, which I can tell you, does not include thoose features, and still behaves like xgettext.
If the much more popular pybabel (than pygettext) uses it, then there must be a reason for it, and it must work, no?
picnixz commentedon Mar 2, 2025
(I'll mark it as a feature)
StanFromIreland commentedon Mar 2, 2025
@picnixz It was partially implemented a few years ago… so I guess it’s both?
picnixz commentedon Mar 2, 2025
Yes, but since it's in the Tools folder, I think it's easier not to change older versions. Even if it was partially implemented, it's a new feature in some sense.
tomasr8 commentedon Mar 2, 2025
Not to disparage babel here (it's a great library and I frequently contribute to it) but it does have its own issues so I would advise against blindly copying whatever code babel is using
tomasr8 commentedon Mar 2, 2025
I think allowing splitting by whitespace (assuming it can be done safely) would be very useful. From my own experience working on a web-based project, we have lots of long strings without newlines because they get rendered by the browser where you normally don't use explicit
\n.serhiy-storchaka commentedon Mar 2, 2025
Well, it makes sense. But full compatibility with
xgettext(orpybabel) should not be the goal.tomasr8 commentedon Mar 2, 2025
I agree, we shouldn't follow everything, especially if it's not practical to do so.
StanFromIreland commentedon Mar 2, 2025
+1 on not aiming for full compatibility, just the key features, like this one
So, Serhiy, what do you think of my white space splitting approach?