Allow comments at the end.
Although comments seem to be valid at the end of lines in layouts, few of the
regexps take this into account. However, OutlinerName was the only one where
there were actual lines with comments at the end. Not touching the others as
there is no one-size-fits-all solution with these regexps.
Thanks Kornel for reporting the issue.
Factored out the sequence into one cmake-script.
Previously it could happen that the python script failed, but the following
command was successfull and so the error was hidden.
Actually, POFILES already contains the relative path to the po files,
so that the old code was only working by chance when the source and
build directories were at same level.
cmake sorts the input files for lyx_pot.py internally, but autotools use a
shell pattern like *.ui on the command line, so the order may be different
on different machines. It is more robust not to require any sorting from the
caller, so lyx_pot.py sorts now internally.
This was done with
python ../lyx-2.3-staging/development/tools/mergepo.py -n -t po ../lyx-2.1/po
It should have been part of a26cdcb4ba, but the mergepo script did not overwrite
fuzzy translations with non-fuzzy ones at that time. Now 2.2 will not be missing
translations that are in 2.1 (but of course it might contain changed translations).
Jari-Matti provided an updated fi.po in bug 10084, but unfortunately I did not
see that before remerging the strings. Therefore, I did not take the updated
file directly, but downloaded it to /tmp/fi.po and merged the updates with
python ../lyx-2.3-staging/development/tools/mergepo.py -o -l fi -t po /tmp/
The two header changes were done manually. This way, the updated translations
are not hidden in lots of sorting changes. I had to use mergepo.py from 2.3
because the one in master does not treat fuzzy translations correctly.
This is a complete remerge of strings (done with cmake) except for fr.po and
sv.po. Those files had already been remerged after the last string changes,
but they use a different sorting, so I did not want to produce an unneeded
diff.
The differences in the comment lines are a well known problem we have: The
last remerge was done on windows, mine was done on linux.
This was discussed in the thread "Translations of Math environments in LyX
output for LyX 2.2" at http://www.mail-archive.com/lyx-docs@lists.lyx.org/msg08633.html
and has been reviewed. The problem was that in 2.1, the portuguese translation
was correct in lib/layouttranslations but different in po/pt_PT.po. In fact,
the translation is the same for all three languages spanish, portuguese and
brazilian portuguese.
After some discussion between Georger, Pedro, Pavel and me Georger came to the
conclusion that Mapa is not the correct translation of Chart in this context.
Originally he proposed Gráfico, but since that would be identical to the
translation of Graph we decided that Diagram is better. It is a bit more
general than Gráfico, but it is also used in pt_PT, and the german translation
uses the german equivalent, which is more general as well. Those who need a
Gráfico can still use Graph.
Unfortunately Geoger based the new .po file on the remerged one at
259196e1a6, so we have now the situation that pt_BR is remerged, but the
other languages are not.
These strings were translated manually in lib/layouttranslations, but not in
zh_TW.po. If this is the correct translation for document output, then it is
certainly also correct for the user interface.
This string was translated manually in lib/layouttranslations, but not in
ar.po. If this is the correct translation for document output, then it is
certainly also correct for the user interface.
lib/layouttranslations contains translations for all strings from layout files
that can appear in document output. These translations are read from .po files
by po/lyx_pot.py (using python polib), so up to date po files are needed.
Now it produces the same output if running under python3 (tested with 3.4.2)
or python2 (tested with 2.7.9). python3 always uses unicode strings
internally, so we have to specify the file encoding on opening a file, such
that strings can be converted from and to the file encoding on reading and
writing. Using the io module for file io ensures that the behaviour is the
same for python2 and python3. For python2 we also have to mark string literals
as unicode strings by using the u prefix (which is a noop in python3).
Many thanks to José for review and pointing out all the details.
