Hi list, Yuri Chornoivan writes:
> понеділок, 13 січня 2020 р. 21:53:43 EET Ulf Zibis написано: >> Hi, >> >> Am 13.01.20 um 20:26 schrieb Ralph Little: >> > On Mon, Jan 13, 2020, 11:17 Ulf Zibis, <ulf.zi...@gmx.de >> > >> > <mailto:ulf.zi...@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.zi...@gmx.de >> >> >> >> <mailto:ulf.zi...@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. > Hi, > > Olaf proposed to use 75 chars. Small correction. I didn't propose. It's what our build machinery uses, see po/Makevars[1]. 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. [1]: https://gitlab.com/sane-project/backends/blob/master/po/Makevars#L32-45 > https://gitlab.com/sane-project/backends/merge_requests/305 > > 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. Thanks! 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