On Sun, 2013-04-28 at 11:01 +0200, Federico Bruni wrote: > > 2013/4/26 Richard Shann <[email protected]> > > not a big effort usually > > if the code positions are altered, the strings are marked as > "fuzzy": > > all we have to do is checking if a real change is happened > and mark it > > as translated if the original string has not changed > > > > If you don't do that does the translation get omitted or is > the fuzzy > one accepted as good enough? > > > > I've just updated from pot file: I have 38 fuzzy and 40 new strings. > Yes, the fuzzy one keeps the translated string, even if it's wrong, > like this one: > > > #: src/commands.c:6396 src/commands.c:6399 > #, fuzzy, no-c-format > msgid "Score Version" > msgstr "Titoli della partitura" > > > Sometimes the difference is really tiny, sometimes it's totally > different.
Ah, so deleting orphan code would work ok provided there were no translated strings in that code otherwise the translation could be garbled. It looks we really need to create a release branch and then announce a new pot file to translationproject.org (and, of course, not change the release branch unless something catastrophic is found). Jeremiah - are you able to create the release branch now? Whatever is wrong with the Mac build cannot surely involve the Denemo source code (the earlier version for Mac worked with the lilypond terminating correctly when I had a chance to test it on a Macbook Air three weeks ago... well, unless the new code for directly generating pdf files has perturbed things - can you use your current mac build system on an earlier version in git to see if the trouble with LilyPond not quitting depends on commits in the past three weeks?) Once we have a release branch and a new pot file we can keep it unchanged other than updating the translations. Richard _______________________________________________ Denemo-devel mailing list [email protected] https://lists.gnu.org/mailman/listinfo/denemo-devel
