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

Reply via email to