Hi,
the following is mainly for developers on windows, since others won't
see any difference.
.pot files are now always created with unix line ends in the latest
2.3-staging branch. This should fix the stray '\r' characters that
appeared in .po files after string remerge on windows. unix line ends in
.pot files are required by gettext.
The question is now what to do with .po files. Here the situation is a
bit more difficult. We can have the following cases:
1) A string remerge is done on a unix machine
2) A string remerge is done on a windows machine
3) A translator sends a .po file with unix line ends
4) A translator sends a .po file with windows line ends
For cases 1) and 3) a commit is OK, for cases 2) and 4) a commit would
produce a huge pseudo diff. Note that for cases 3) and 4) it does not
matter whether the commit happens on a windows or unix machine. The
reason for this behaviour is that we currently ensure unix line ends
manually, and .po files are treated as binary files by git.
To avoid manual fixing work and huge pseudo diffs we need to decide on a
line end convention for .po files. We have two choices: Either use
native line ends (unix line ends on a unix checkout, windows line ends
on a windows checkout), or always unix line ends. I do not know of any
technical reason to prefer one over the other choice. Both are possible
to implement with very little effort. poedit can work with both. I don't
know about other .po editors.
Which choice would be more convenient for windows users?
Georg
