Daniel Egger wrote: > > Yes, but that's the very nature of the ChangeLog. It is *supposed* to be > > edited with every commit. > > Why does that make a difference? > Rather the fact that every entry has to be added at the top of the file > to keep the chronological order makes it much more conflict prone then > any other file.
Sure, but conflicts in ChangeLogs are easy to spot (since changes go at the top) and almost always easy to spot. Furthermore, you completely missed the point in that I wasn't talking about conflicts, but about the dangers of changes other people do to my translation and the change going completely undetected due to the heavy commit traffic a single translation file would have, and the chance of detecting those changes going from close to 1 with po files to close to 0 with a single edited translation file, without having to spend hours of extra work investigating changes to see which ones are appropriate and which ones are not (the ones affecting my translations that I didn't know about). > > Also, ChangeLogs are mostly for developers. Not many people don't cry or > > flame if there is a typo or a tab or dot is missing. However, if > > something is wrong in a translation, which usually is immediately > > visible to a large number of end users, that's another matter. > > Hah, you've never seen me getting mad when syngin or bex messed up the > structure of gimp-help's ChangeLog.... :) I have also cleaned up some ChangeLogs in the past with respect to tabs, spaces and 80-character line width, but this remains to be only cosmetical changes. A change in a translation can easily be more devastating and visible than so. > > But in that case I can at least easily spot it! I thought I had already > > explained that it is the easy and early detection of other people's > > grateful unannounced changes to my translations I want to keep. Why do > > you think I use an $Id$ tag in all my po files? > > Dunno, because you want to piss of other people? Please explain why you assume maintainership and keeping track of commits automatically makes a person wanting to "piss off" other people. > > Surely, but the problem is worse with translations. If you accidentally > > remove a line too much in the source, chances are big that you will > > notice that when compiling to test your changes. > > If other people edit a .desktop or XML file directly and accidentally > > cut away the line with my translation, it will not get detected > > syntactically (that languages' translation is simply gone and it is > > still valid syntactically), the only one developer noticing that it is > > missing will be me and I will have little chance of detecting it myself > > until I revisit the translation and carefully inspect it manually. > > Missing lines are probably much easier to detect then misspelled ones. Yep. I couldn't have said it better myself. Lingustic changes are far worse, and also almost impossible to detect in such a file without actually verifying the translation. > > Someone else doing a cvs diff for that commit could also notice the > > change by accident, but he or she might not know that this was was an > > unwanted change, and the chances of he or she notifying me, or knowing > > that I should be notified, are probably even smaller. > > You're carying to much about theoretical problems. They are not theoretical, no matter how much I wish they were. I've experienced this again and again with .desktop files in CVS before we started to use intltool. A typical scenario: 1) Translator A,B,C,D,E adds their translations to the file 2) Translator F does the same, but accidentally saves and commits the file in his native encoding, effectively ruining many existing translations 3) Translators G,H,I,J add their translations to the file 4) Translator B revisits the file and finds out that his translation is broken, and has to dig in cvs history to find out why 5) After "why" the next step is to ask all translators to verify that their respective translation is still correct and that they make any necessary changes. It's not a matter of a simple revert since other changes have been added in the mean time 6) Translators A,B,C,D,E,F,G,H,I,J verify their translations And repeat the process, until the same mistake happens again... This is a highly prominent problem of "all translation in the same file" schemes, and it is by no means new or theoretical only, these are cold hard experience from these things happening in cvs in reality. > We've have been there > before at university: 40 people hacking on XML files together. After > some days of chaos I gave an CVS crashcourse and after that we had no > problems at all, that were several hundreds XML files consisting of > a few thousand lines each. I think this is hardly comparable to translations. Translations are completely separetely maintained enteties that have no correlation to each other whatsoever other than that they are derived from the same source, and thus from this fact alone it does not make any sense to force them to be edited together. Furthermore, in your example you most likely had the benefit of getting everyone's attention, while in a distributed project that is much harder to do. Moreover, you had the benefit of a limited set of people all working over the same limited period of time. In a distributed free software project, translators come and go over a period time that usually is many years. This unfortunately has the drawback of every possible accident that can happen is bound to happen many times as new people arrive and are unexperienced. Information and textual guidelines never eliminate these accidents. The only real solution is to minimize the dangers, and this includes designing translation schemes so that a single unexperienced translator's accidental error doesn't ruin everybody elses work, for example by not (unnecessarily) force translation edits to all be on the same file. Christian _______________________________________________ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer