[sane-devel] Line wrapping in po/*.po files (was Re: [janitorial] Feature freeze for 1.0.29 and call for translation updates)
paddy-hack at member.fsf.org
Tue Jan 14 13:01:41 GMT 2020
Yuri Chornoivan writes:
> понеділок, 13 січня 2020 р. 21:53:43 EET Ulf Zibis написано:
>> Am 13.01.20 um 20:26 schrieb Ralph Little:
>> > On Mon, Jan 13, 2020, 11:17 Ulf Zibis, <Ulf.Zibis at gmx.de
>> > <mailto:Ulf.Zibis at gmx.de>> wrote:
>> > Am 13.01.20 um 19:58 schrieb Ralph Little:
>> >> On Mon, Jan 13, 2020 at 9:58 AM Ulf Zibis <Ulf.Zibis at gmx.de
>> >> <mailto:Ulf.Zibis at gmx.de>> wrote:
>> >> Here came some surprise. With diff, I could see, that many lines were
>> >> changed, even there was no semantic change. This was caused by poedit
>> >> from automatic line break. It breaks lines after 83 chars, regardless if
>> >> I e.g. set it to 70 (with "keep format of existing files"), the default
>> >> was 79.
>> >> So I like to suggest, to first "reformat" the de.po file for a stable
>> >> format, make a merge request and after do the semantic changes, so
>> >> reviewers would have less work.
>> >> I tend to agree!
>> >> I prefer to formatting changes separated from functional updates.
Agreed on separating file formatting changes from the translation
updates. But please read on.
>> > Great!
>> > I personally would prefer NO line breaks, as comparing the diffs after
>> > would be much easier (otherwise a little change at the beginning of a
>> > long text changes all line breaks for several following lines, which
>> > makes it error-prone to observe changes at the end of the long text)
>> > If you disagree and want automatic line breaks, which width do you
>> > want?
>> > -Ulf
>> > I personally don't have a view.
>> > However I see that the default setting in poedit is 79 and that seems
>> > reasonable to me. In the version I have has a setting of "Preserve
>> > formatting of existing files" so I don't know why it would be making
>> > other changes. :(
If your tool has such an option, please use it. If not, check if it has
a word-wrap setting and set it to 75 for the sane-backends.
>> Maybe this setting scans for the longest line in the input file an takes
>> its width instead the determined 79.
>> Is there any opposition from someone against disabling the automatic
>> line break, as today's screens are huge and modern edit and visual diff
>> tools are anyway capable to visually wrap lines according the window
>> width. This would dramatically serve visual diff tools to highlight tiny
>> differences in long logical strings.
Many visual diff tools are also capable of highlighting differences
within the lines that changed. I find that a whole lot more useful
and convenient for finding tiny differences, even in short strings.
# As for huge screens, I can fit about 260 9pt characters on a single
# screen line before it wraps on one of my machines. And, no, I don't
# find that convenient. I prefer to have three <80 char text panes open
# next to each other. On my laptop it's only two such panes but still
# beats overly long lines hands down.
> Olaf proposed to use 75 chars.
Small correction. I didn't propose. It's what our build machinery
uses, see po/Makevars. Whenever the po/*.po files are sync'd with
the source files (listed in po/POTFILES.in), it applies this width of 75
characters to the files that are generated.
> Personally, I have configured my Lokalize project to use this width.
The value of 75 itself dates back traces back to a commit made on
2007-12-08 (see d4a6f33c383c5368fb9102242fafe7ef4818e25d), adding
Esperanto translations. Seeing where it came from, I guess it snuck in
unintentionally, but we've been using this for a looong time.
Whatever value we end up using (after 1.0.29!), we need to make sure all
the various gettext utilities use the *same* value. If they don't do
so, our CI will fail (see 2ea6e8eaaa214da7a551070763ef8e4f370018db).
FWIW and not that I'm in favour of this, there is a `--no-wrap` option
that we can use instead of the `--width=75` option we use now.
Hope this helps,
Olaf Meeuwissen, LPIC-2 FSF Associate Member since 2004-01-27
GnuPG key: F84A2DD9/B3C0 2F47 EA19 64F4 9F13 F43E B8A4 A88A F84A 2DD9
Support Free Software https://my.fsf.org/donate
Join the Free Software Foundation https://my.fsf.org/join
More information about the sane-devel