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) > > 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. > 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. > > - 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. > > 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? > 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? > 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. ------------------------------------------------------------------------- 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
