On Fri, 10 Jul 2015 15:34, Axel Braun wrote:
Am Freitag, 10. Juli 2015, 14:11:58 schrieb Michael Matz:
There is no error in the above. The "removing translation" are informative.
Exactly! But my latest comment does not refer to the original message!
Hmm? You have an error message on files generated by pythons msgfmt replacement. Then you have used msgfmt itself on the files and found no error messages. Why do you still think it's not pythons variant that is buggy?
Because the .mo gets removed in both cases - the .mo included in the original tarball, as well as the handcrafted .mo
The error is this from your original log: "<stdin>:81: 'msgid' and 'msgstr' entries do not both end with '\n'" and that means that "msgunfmt $file | msgfmt --statistics -o /dev/null" is breaking, and that means that $file was incorrectly generated when the initial build didn't already complain.
docb@T520:~/tryton/tryton-3.6.1/share/locale/nl_NL/LC_MESSAGES> msgunfmt tryton.mo | msgfmt --statistics -o /dev/nul msgfmt: Eingabedatei fehlt »msgfmt --help« gibt weitere Informationen.
Yeah, well, obviously that's not the correct command to use, I abbreviated, you have to apply a little thinking. the actual command line would be:
and some more bash-knowledge I assume :-)
% msgunfmt tryton.mo | msgfmt --statistics -o /dev/null -
(Use the .mo file generated from the python msgfmt, _not_ the one you generated yourself with msgfmt)
OK, back to start, back to the original tarball with the python-generated .mo file. Here is the output:
docb@T520:~/tryton/tryton-3.6.1/share/locale/nl_NL/LC_MESSAGES> msgunfmt tryton.mo | msgfmt --statistics -o /dev/null - 338 übersetzte Meldungen.
(no error, just the number of translated messages)
So yes, it's the python implementation of msgfmt that's broken.
Probably not. But bottom line is that msgfmt does not issue an error, while %find_lang removed the .mo file....
The .mo files aren't removed because of the error but because they are for non-supported languages. Supported languages are all those that have an entry under /usr/share/locale/ in the 'filesystem' package; all others are not supported. 'nl_NL' is one of those non-supported languages.
I see. Now I understand Yamaban's comment as well - or at least I think I do: Because the openSUSE standard installation does not have a nl_NL entry, the language gets removed during build, did I get that right?
Did a quick check, did the rename nl_BE -> nl_NL (in the build environment), but that did not fix it.
Nooooo! Wrong! (Sorry, I'll drop the drama) Lecture-hat on: "nl_BE" is Netherland speech, Belgian Nation (curency, measurements, etc) "nl_NL", or "nl" for short is Netherland speech, Netherland Nation, Netherlands for short, but there will be outlaws for some languages see "de_CH", "de_AT", and "de" for easy to understand example. IOW: let "nl_BE" be as it is, only touch "nl_NL" dir (mv nl_NL nl) steps for you: - rename the source dir from "nl_NL" to "nl", then run "msgfmt" or the python eqiv. - rename dir before, during or after %install, but before %files and / or %find_lang Does that make sense ot you? - Yamaban.