Open gamboz opened 1 year ago
Let me add a few more info on this: we use Django, which underneath uses xgettext
; I tried the fix suggested by @gamboz but it didn't work: it is correct that when using --no-wrap
, xgettext
does still wrap "comments" (the original string location), but what worked for us was not to edit wrapwidth > 1
, but rather to hardcode a width of 79
characters in polib.py#L1037:
1037,14c1,11
< if wrapwidth > 0 and len(filestr) + 3 > wrapwidth:
< # textwrap split words that contain hyphen, this is not
< # what we want for filenames, so the dirty hack is to
< # temporally replace hyphens with a char that a file cannot
< # contain, like "*"
< ret += [line.replace('*', '-') for line in textwrap.wrap(
< filestr.replace('-', '*'),
< wrapwidth,
< initial_indent='#: ',
< subsequent_indent='#: ',
< break_long_words=False
< )]
< else:
< ret.append('#: ' + filestr)
---
> # textwrap split words that contain hyphen, this is not
> # what we want for filenames, so the dirty hack is to
> # temporally replace hyphens with a char that a file cannot
> # contain, like "*"
> ret += [line.replace('*', '-') for line in textwrap.wrap(
> filestr.replace('-', '*'),
> width=79,
> initial_indent='#: ',
> subsequent_indent='#: ',
> break_long_words=False
> )]
I'm not sure this works on all use cases, though; with Django it worked.
I think that
xgettext --no-wrap
does not apply to the list of occurrences, so polib and xgettext will format the#:
lines differently.If you have a structure like the following:
where all the files contain the same string to translate, polib with
wrapwidth=0
gives something likewhile
xgettext --no-wrap
something like the following (that was somewhat unexpected for me :)I think this can be changed by editing polib.py l.1037 from
to
I'm not yet opening a PR, because these are my first steps in the "translations" world and I might be making stupid mistakes (so please be patient :slightly_smiling_face: )