On Wed, 2006-07-19 at 01:21 +0200, Denis Barbier wrote: > On Wed, Jul 19, 2006 at 12:09:18AM +0200, F Wolff wrote: > > On Di, 2006-07-18 at 23:11 +0200, Denis Barbier wrote: > > > On Wed, Jul 12, 2006 at 03:50:45PM +0200, Dwayne Bailey wrote: > > > > Another user of Pootle. And for me another clear reason why it is > > > > important > > > > that we are creating an Open Source online translation tool. It needs > > > > to become > > > > more decentralised just as others have realised in version control > > > > systems. > > > > > > OTOH there are various discussions on kde-i18n-doc, like > > > http://lists.kde.org/?t=115254842800001&r=1&w=2 > > > which show how harmful a decentralised system can be if there is > > > no discussion with upstream translators. > > > > Hmm, this thread concerns me a bit. I don't want to duplicate that > > thread here, but I think we must stay focused on making things easy for > > all stakeholders. Easy to do well, that is. Perhaps people don't realise > > how many of these problems Pootle already solves, or already solves to > > some extent. The admin functions are not easily available in a demo > > somewhere. > > There are always people who want another approach. And if they are > upstream, they have the final word on their project. Consider > http://lists.kde.org/?l=kde-i18n-doc&m=115317550308320&w=2 > for instance; a translation has been imported from rosetta, and upstream > translator is unhappy with it. There have been discussions to have > automatic commits into upstream VCS, so the same situation will also > happen with pootle.
KDE is unique in this situation in that they allow more liberal CVS access then most other projects. But since the coders on Pootle actually run localisation projects we're acutely aware of wanting to maintain quality of our own translations. We also don't want people running roughshod over our work. The commits from Pootle should mirror the rights inherent in the team. > My reading of the thread quoted above is that these upstream translators > want to receive suggestions for changes, ideally from a language team > coordinator (sending all changes individually would be too much traffic, > suggestions have to be gathered logically, usually by component). > Upstream translator then accepts some suggestions and rejects others. > Pootle language team coordinator can either discard these rejected > changes, or keep them if she wants to have them in her product. > Several months later, she sends updated suggestions to upstream > translator, and of course she has to send only new suggestions, not the > ones which have already been rejected. We can already work in a suggestion mode. Sending the suggestions as a batch to the upstream person we don't currently do. Ideally Pootle is running against some version control so getting a diff should be relatively easy. > This is not easy, but feasible (this is exactly how distributors are > behaving with their upstream software authors, or at least how they > should). I did not test pootle yet; if this data flow can be easily > performed, this is great; otherwise I am afraid that a thread similar > to the one quoted above will arise with s/rosetta/pootle/. Mostly it all depends on how deeply upstream adopts Pootle. I actually don't think someone should be running an online translation tool without collaboration with upstream translators. Ideally Pootle is actually run by the upstream translator or their project. Pootle has some inherent advantage for upstream translators. They don't actually have to use the online interface, but people using the suggest mode can easily correct spelling and grammar. Something that doesn't happen now unless your absolutely dedicated. Long term as Pootle gets better at collaboration with the various processes people have created I think this will be less of an issue. Pootle is simply a tool designed to enhance the localisation process, get more people involved and make it easier for people to share collaborate and work across project seamlessly. I think people miss the future benefits. Things like being able to easily task new translators to less important parts of KDE. Set global goals and deadlines. Etc.etc. Pootle is not all about online translation. If Pootle messes with peoples processes then either they change their processes or change Pootle to work within their process. But it is simply a tool. The Rosetta example is unfortunate but I think its a confluence of the way KDE version control access works and the way Rosetta has been structured as a central translation service. Pootle is designed to be decentralised. Lets look at KDE. The project could setup Pootle. Various teams leaders could set the status of submissions to their projects as: view only, suggest or translate. By setting to view only they continue as they did before but have nice stats of their project. A team that set to suggest only can then get corrections from random hackers and integrate those that are important. At all stages the team would not be using Pootle to translate. If they decide to translate with Pootle they can. They can set those rights on a per user basis. They would probably not want commit rights, but they could set one or two people with commit rights. -- Dwayne Bailey Translate.org.za +27-12-460-1095 (w) +27-83-443-7114 (cell) ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ Translate-pootle mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/translate-pootle
