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. 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 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 - not yet existing: synchronization with other translation sources (offline translation editors, other translation servers (like launchpad), translations-by-mail, ...) 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). 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. > 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 ------------------------------------------------------------------------- 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
