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. Christian
