Am 06.04.2016 um 00:56 schrieb Uwe Stöhr:
Am 05.04.2016 um 08:46 schrieb Georg Baum:
Which strings? These might require a remerge of the other languages as
well
I remerged all po files yesterday because I noticed that e.g. the
longtable name change was not present in fr.po, de.po etc.
In pt_BR.po I saw that too but after I committed Georger's changes, I
saw that actually nothing was changed because this was already in -
strange.
Concerning the layouttranslations file i cannot see a difference to the
file in today's git. Maybe Georg already included your updates.
I did that indeed, and the .po file was also already submitted. Uwe, at
some time we need to figure out why your .po file submits change the
line endings in some cases.
I don't think that this is me. I receive the different po-files from
different people using different editors. I only add them to my git
tree, check if they are compilable and then commit. In the vast majority
I commit without any change to the files. Up to now I was not aware that
there are problems with scripts. I do this for years now and Richard is
on Linux preparing there the .x releases.
git says that it is you: The broken line endings are always introduced
with a remerge .po file commit from you, the last one was
http://www.lyx.org/trac/changeset/aaf2cc5dbe7321334e34000eacb7edba8755f0f2/lyxgit.
This causes trouble with our python scripts
which parse them, they always have to be in unix form (\n, not \r\n).
Until we found out the reason please look at the diffe before
submitting, and if the .po file has windows line endings please change
them to unix line endings (could be done e. g. by notepad2).
But how could I check if there are the wrong line endings?
With any good text editor. I use notepad2 when I am on windows, IIRC it
has that in the file menu. Also, the diff functionality in your git
client has probably a setting to ignore white space and line ending
differences or not. If you set that to show all whitespace and line
ending differences you'll see these changes befor commit in the diff.
The diff in trac does unfortunately not show them.
Why can the
python scripts not handle both line ending types? Here the scripts can
handle also Unix line endings so it should be possible to have the
opposite on Linux too and obviously it works at least for Richard.
Richard, do you have an idea?
I agree that the python scripts should work with both line endings. It
is simply a bug that they cannot cope with windows iine endings on
windows. Unfortunately up to now nobody had the time to investigate
this. We have four combinations that must work:
windows line endings on windows
windows line endings on unix
unix line endings on windows
unix line endings on unix
The reason for this is that you might be on windows, and receive a .po
file from a unix user that you want to commit, and vice versa. Until the
scripts are fixed please don't do a remerge, since this would create
extra work for others (and a remerge during string freeze is
questionable anyway, since this would mean that something wnet wrong
when the strings were frozen, and this would need discussion).
If you commit .po file updates from translators please ensure that they
have unix line endings. This can be done with any decent editor like I
wrote above. Unfortunately the '\r' characters in the middle of a line
that are created by a remerge cannot be fixed that easily.
Georg
