[Bf-committers] [Bf-blender-cvs] SVN commit: /data/svn/bf-blender  trunk/blender/bin/.blender/locale/ de/LC_MESSAGES/blender.mo: German translation by lobsterbake at web. de and migius at gmx.de from Blendpolis.de
gsr.b3d at infernal-iceberg.com
Sun May 24 00:51:14 CEST 2009
migius at gmx.net (2009-05-23 at 2337.47 +0200):
> GSR wrote:
> > Time ago I added a test in Makefiles to check the binary .mo generated
> > from the source .po is the same than the binary .mo in SVN (no idea
> > why we have to store them instead of just building as needed). Just a
> > measure to always have working .mo files from updatable .po files (you
> > know, open source and all that jazz).
> > The problem is that the source .po has not been updated, so any future
> > development will be impossible. I commited the .mo again to unbreak
> > the build process.
> but the .po file is/was updated with revision 20358
> then i committed the .mo file with 20359
Argh, the commit msg I wrote is wrong. The .mo in r20367 is the one in
sync with the .po in r20358 as it was manually regerenated from it and
A good practice for version tracking systems is to make commits that
cover topics in full (commit the .mo and .po in one revision) or well
defined steps if they are huge, and not mix different topics (do not
fix more than one bug or change more than one feature per commit).
> > Please Remigiusz, commit the .po (and the .mo generated from it) and
> > never accept .mo files without the corresponding .po file. What
> > matters is the .po, not the .mo.
> i suppose, that msgfmt.py bundled with python 2.5.2 produces binary not identical .mo file, so the check fails.
Current SVN .mo was genarated by msgfmt (GNU gettext-tools) 0.17.
My avaliability of machines types is limited so I can not test, but
based in file cmd output, Sgefant is right, endianess matters and
files are non portable. In such case we should drop the binaries
altogether and properly compile them. No idea why this has been
finally detected now, it should had been more obvious long ago when
"near all is x86" was not so valid. *sigh*
More information about the Bf-committers