On Sa, 2007-06-23 at 11:28 +0200, lars wrote: > Hi, > > > > For me, an "item" would be a single translated string (and possible meta > > > data). Right now the revision control interface does not care for indivual > > > items, but can only handle complete files. Thus any changes made through > > > the web interface are thrown away during an update from the version > > > control > > > repository. The same goes for the other direction: intermediate changes in > > > the version control repository are (theoretically) ignored and overwritten > > > by the changes made through the web interface when committing. > > > > There is already code to handle these situations. A version control > > conflict could cause an unparsable file, so we have to handle it for the > > users. > > the current code does the following for different situations for conflicting > files (both local changes and changes in the RCS): > A) for commit: refuse to commit, since the local working copy is outdated > (at least Subversion will handle it that way - I am not sure about the > others) > B) for update: revert (throw away) the local change and retrieve the changes > from RCS > (valid for subversion/cvs/darcs)
Are you sure the changes were not converted to suggestions? They can seem gone if there were really big changes in the PO file (if #: location comments also change as they can do in traditional gettext based projects). Unfortunately we use those comments to identify suggestions for PO based projects. > > > > > In the end, this boils down to resolving conflicts, I guess. > > > > > > I could imagine, that the web interface should offer the following options > > > for any conflicting item during revision control synchronization (update > > > or > > > commit): A) keep RCS (revision control system) translation; turn the local > > > translation into a suggestion > > > > This is the current behaviour. We always consider version control to be > > the authority. > > not really - for now the "turn the local translation into a suggestion" > behaviour is only a feature request. In reality all local changes are lost. > Did you check the code in projects.py::updatepofile()? Check where it calls pootlefile.py::mergeitem() > > > We might want to look at the detail to ensure that it is exactly what we > > want, but I know people are already using this feature. The darcs > > support comes from the people at Frugalware and their progress can be > > viewed here: > > http://cia.vc/stats/author/[EMAIL PROTECTED] > > > > I don't know if they allow third parties access to commit to version > > control, but perhaps VMiklos can comment. > > I guess, we (http://cryptobox.org) are maybe using it in a similar way: most > translations are done through the web interface and sometimes "third > parties" (developers creating translations locally) submit their changes via > svn. For now we did not run into problems, as there are only few translators > and developers. > The svn changes are updated hourly on the pootle server (by a simple custom > cron > script), Without this script there is (from my point of view) currently no > way to use both pootle and subversion as sources of translations. > We have not used it extensively ourselves, but I'm quite sure that it works. Perhaps if there is a real case that doesn't work, we should put it in bugzilla and look at fixing it. > > > > - not yet existing: synchronization with other translation sources > > > (offline > > > translation editors, other translation servers (like launchpad), > > > translations-by-mail, ...) > > > > > > > You forgot one: file upload. > > oh - yes - that is quite important, too > > > > This we do similarly: In the default upload mode (merge) only untranslated > > entries receive the translations from the uploaded file. In other cases the > > uploaded translation becomes a suggestion that needs to be reviewed. > > great! I will take a look at the code soon. > >From my point of view, this merging code maybe should be used for all > >sources of > translations - including revision control system. The problem to be solved is > always the same - just the source of a translated string differs. I agree, it has been on my todo list for more than 6 months now. I would really like something that merges this code as well as pomerge and pot2po in the toolkit. They all have something in common. I'm just not sure that it will be worthwhile or easy enough to really abstract something useful out of all of them. Any improvement is good, though. The code is a bit hard to read through. > > > > > Anyway, I will move versioncontrol.py to a seperate directory and split it > > > into different files for different revision control systems. Then it > > > should > > > be easy to move it to the toolkit, if necessary. > > > > > Ok, I will commit the intermediate work anyway which might make it > > easier in future to track the changes. (I might only get to it on > > Monday, but I'll try to make it sooner in case it is important to > > somebody.) > > perfectly fine for me, as I will not start working on it before next Sunday. > > > > I didn't realise that we'll handle directories as well, but I see that > > now. I'm just wondering now: is it ideal that we are recreating objects > > all the time? > > you mean, creating instances of the classes SVN, CVS and DARCS? > Does this create problems? Not really. I just want to keep a check on the number of objects created. > > > > I'm sure you implemented it with the functions to make the > > diff in other files smaller (which I appreciate a lot :-) but I guess > > in future we might want to look at storing a version control object in > > the project. > > ah! - you mean: storing the type of version control system as a property of > each > project? > Yes, but the issue below is what would make me hesitant. > > > Then again, currently it is possible to have different version control > > systems for different languages in a project, for example, which is not > > bad :-) > > another advantage (if I understand you right) would be, that no other piece of > code needs to know about the different supported revision control systems. > Thus > I think it is inevitable to have something similar to the current generic > wrapper functions. > Yes, the rest of the code should not care about that. Let us see where we are after the initial refactoring and see where we want to go from there. F ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ _______________________________________________ Translate-pootle mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/translate-pootle
