On Sa, 2007-06-23 at 04:53 +0200, lars wrote: > Hi, > > > > > * After moving to the toolkit, would it be meaningful to split this > > > > into separate files? Perhaps even a dedicated directory under > > > > storage/versioncontrol? > > > yes, this would improve the structure. > > > But I am not really sure, if version control in general should be > > > integrated in this file base way, as it is now. I think, that a item based > > > approach would be more reasonable and should better fit to the (maybe) > > > future database storage backend > > > (http://translate.sourceforge.net/wiki/pootle/metadata). As long as the > > > current code is only part of pootle, it is quite easy to change its > > > interface. As a part of the translate toolkit, it would be much harder to > > > change it, I guess. But maybe the 'metadata' document is outdated anyway? > > > In short: yes - it should be splitted. > > > > That metatdata document is quite old, yes. I don't think I understand > > what you mean with an item based approach. Can you expand a bit on that, > > please? > > 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. > > 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. Some notes are here: http://translate.sourceforge.net/wiki/pootle/version_control 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. > B) keep RCS translation; throw away the local translation > C) keep the local translation; turn the RCS translation into a suggestion > D) keep the local translation; throw away the RCS translation > > I would think, that similar conflicts do/will also arise in other situations > as well: > - two translators submitting a translation via the web interface within a > short > timeframe - for now the one who submits later is the "winner" and will never > know about the translation, that was done before This is not yet handled. > - not yet existing: synchronization with other translation sources (offline > translation editors, other translation servers (like launchpad), > translations-by-mail, ...) > You forgot one: file upload. 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. Since 0.11 users with the relevant right can choose to rather follow overwrite mode, where the file is replaced in its entirety. > I do not have a real plan yet, how this should be implemented. But I would be > happy to work on it after some discussions (just in case, this is perceived as > a to-be-solved problem by the developers). > I'm sure there are more improvements that can be worked on, so we'll be very happy to have more people interested in these functionalities. > 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.) > > The only major shortcoming I currently see in the version > > control functionality of Pootle is the ability to commit / update entire > > directories/projects at a time. I don't know to what extent we would > > have to extend the versioncontrol.py for that. > the current code interface should be sufficient for that: I will do this in > the > first week of July. But I am not sure where to integrate this into the web > interface. > > Lars 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? 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. Then again, currently it is possible to have different version control systems for different languages in a project, for example, which is not bad :-) Just some notes. Thanks for your contributions. Friedel ------------------------------------------------------------------------- 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
