Daniel Egger wrote:
> > Also, one important drawback of keeping all translations in one file in
> > CVS, and forcing translators to edit this file, is that it gets almost
> > impossible to verify the integrity of translations. As a translator and
> > creator and maintainer of the translation, I feel that it is important
> > that errors in my translation are my errors alone, and that I'm the only
> > one responsible for them. Translation errors introduced by other people
> > without permission are, well, "annoying" to say the least.
> It's quite tricky to introduce any errors in XML files and easy at the
> same time to fix them.

I think you misunderstood what I meant. I wasn't referring to
syntactical errors, I was referring to pure language errors. There's no
tool in the world other than manual inspection that can help me fully
verify those, and I'd rather have to do this tedious work as rarely as
possible, as opposed to at every cvs commit of another translator, just
to catch an unwanted change of my translation.

> CVS guarantees a certain amount of integrity
> so having conflicting changes is not a problem.

How does this solve the "I committed a newer file with my translation
updated, but accidentally/intentionally messed with yours" problem? I
don't see how.

> AND: XML can be easily
> verified to be correct when there's a schema file, even remotely, and
> in theory the GNOME CVS server could be teached to only allow checkin
> of valid XML files.

Yes, you can check syntax, but you completely missed my point.

> > With a whole bunch of different people committing to the same file,
> > verifying the integrity of individual translations becomes almost
> > impossible.
> It's not more of a problem then with several people working on
> other files concurrently; that's what CVS is for.

It's different. First of all, for every source file it is only a small
number of trusted people that should be able to commit, namely the
developers of that project. I think there are not many projects where
more than 20 developers are expected to commit directly to the same
source file. You're free to correct me if I'm wrong.

But in the GTP we have 40 language teams alone, most of them with at
least one person with GIMP cvs access. Even if we only make the
assumption "one language team = one translator" (which in many cases
will be very wrong) there's 40 translators that will commit to the same
single file.
I can tell you that the number of translators that I know (and hence
trust) is significantly lower than 40. So this is a real problem, and
for the amount of people it affects alone a different problem than for
source files in a project.

> I admit that more people on the same file are likely to have more conflicts
> but that's only a theoretical problem or how often do translations change?

I update translations daily. Not all of them, mind you. :-)
For most translations, I tend to revisit them once a month on average
while doing my daily round of updates, I believe (if they have changed).
But I know that this isn't entirely uncommon, and a dozen of translators
that do the same and/or add new translations and I have a whole bunch of
cvs commits in the mean time that I have to cvs diff to inspect when I
revisit. I'd rather not have to do that.

> > Such a file will easily become one of the most committed
> > files in gimp CVS,
> Okay, the most changed file is definitely the ChangeLog; who often
> do you think there were conflicts? I had a couple (4 or 5) including
> my more active time but Sven and Mitch can surely tell you how
> often it occured to them in the last few months - just to give you
> an idea how likely problems here are.

Yes, but that's the very nature of the ChangeLog. It is *supposed* to be
edited with every commit.
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.

> > and the danger of someone accidentally or
> > intentionally messing with someone elses translation without permission
> > becomes much more imminent.
> Don't think so. It's about as easy to touch an .po file.

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?

> > much (and thus removing another translation) when for example cutting
> Yes, mistakes happen, but also in other sources.

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.

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.

And this is all aside that the number of translators are usually many
more than developers, and that this is simply a logistical problem for
that fact alone.

> > and pasting, and there's always the danger of someone wanting to
> > "improve" another translation, without seeing the need to ask first.
> You fear competition?

Not at all. However, I reserve the right to maintain my own
translations. That doesn't mean that I'm reluctant to any other
contributions to my translations, it's just that I want changes
discussed openly, and I reserve the right to have the final say on what
goes in.

Every new translation I do (and most bigger updates) I send out for
review by other translators and other interested people on a mailing
list, and I'm usually very open-minded about changes (archives are here:
http://www.softwolves.pp.se/misc/arkiv/sv/8/date.html , although Swedish
translation discussions are unfortunately only in Swedish). Also, I
usually do honor all suggestions I get from users of the application.

That doesn't mean that I like cvs-commit races and "gratitious changes"
by someone not willing to openly discuss a change, but rather just wants
to (cowardly) silently commit a change to have it "his" way, usually
ignoring all well-founded (and reviewed) reasons it is the way it is,
and that others, including the maintainer of the translation, might be
of a different opinion. Open discussion and maintainership are the key
issues here.

> Well, I pissed off some evolution people while
> fixing their DocBook->HTML converter once and they didn't want to have
> it fixed for some reason (heck, they even wrote a contributors
> killerscript because of that) so I left it alone and let them fix their
> own crap and decided not to use realtime translation for gimp-help.
> What's the lesson? Some people have no sense of cooperation so better
> let them alone.

I don't blame the Evolution maintainers. If a change went in without
approval, they had all rights in the world to back it out and even ban
you from committing to their module. That's how maintainership works.
Some are welcoming other people's silent commits, others wants to review
and discuss it first before it (eventually) goes in. And that policy is
up to the maintainer to decide.

> It's the same with translations; some people don't
> want contributors for their files and others don't mind when people
> have something to contribute but that's not really a matter of the
> fileformat.

I don't mind if people want to contribute, not at all. It's just that I
want to have a fair chance of discussing linguistic changes before they
go in, and if I and the person suggesting the change in the end should
disagree even after discussions, I want the final say on what goes in,
as I maintain the translation. That usually doesn't happen, but that's
the policy we have with translations, and it's very similar to how it
works for CVS modules.

> > With a single file, the only way of verifying the integrity of my own
> > translations is basically having to resort to 'cvs diff' after every
> > single commit to this file in CVS, which will hardly be practical.
> > With separate po files, commits to "my" file are much more rare, and I
> > basically only have to ensure that the last committer was me (easily
> > doable by putting in a CVS "$Id$" tag in the file) to be sure that the
> > translation hasn't been changed by someone else without permission.
> Ayee, reading this lines really annoys me. GIMP grew to such a beautiful
> project because of cooperation. Egoism and arrogance are definitely
> wrong here; if you don't want your sources to be touched then keep them
> closed source.

Umm, I think you are seriously misunderstanding the roles of free
software and maintainership here. Free software doesn't give you the
right to directly change my work. It gives you the right to fork it and
do all the changes you like to your copy, but you have no right to
impose your changes on my version without approval.
If we really should disagree about changes even after lenghty
discussions and you have an alternative translation that you want to see
used in the module, then we have to bring this up with the module
maintainer and let him/them make the decision.

Also, you make this sound like this would be a common scenario with
people wanting to fork translations. It is not. Suggestions for changes
are usually accepted, so I don't see your problem with me wanting to
have control over my work, even from this point.

> Competition is good and the fittest translation will
> survive and that's not something fixed one person can decide, in doubt
> people will need to discuss about it.

Cooperation is usually in many cases better than competition, especially
when there are limited resources like in the free software world.
Especially translation resources are usually limited. If someone should
be unsatisfied with my decision regarding a proposed change (which is
uncommon, in almost all cases I accept changes, and where that isn't
true we discuss it some more, listen to other people's opinions, and
usually agree in the end), and has the time and motivation to provide
and maintain an alternative translation, he or she is free to do so.
Trying to silently sneak in changes without any open discussion or
approval still isn't the way to go.

Gimp-developer mailing list

Reply via email to