Nuno Lopes wrote: >> This is important, because usual CVS users will still do >> translations. Also it is important for this system to handle >> colissions. It is not at all sure that the cronjob will be able to >> commit the changes, if one CVS user changes the file between the >> moment someone edits it in the online app, and the cron runs. >> Therefore I would vote for immediate commits. Also if this app would >> use cron, then it should handle the problem of multiple change >> requests regarding the same file in the scope of the application >> itself. Imagine that it commits the first change, then it will not >> be possible to committ the second change, because it does not >> contain the previous change (it is not updated). So it seems to me >> that everything stands behind immediate commits. >> >> Goba > > Lets try with imediate commits. The cron job will only be used to > checkout and update the db. > > One more thing: I was thinking in not translating the whole file at > once. I'll explain: The script would parse the file and return a > couple of senteces, only. The user would translate them and then they > would go to the db. Then he would receive a couple of more sentences. > I think this way is better, because you may translate only half file > a day and the user wouldn't need to scroll up and down to translate. > What do you think about this? > > Nuno
In a old old old system for web translating, I idealized a structure like this: /source The main checkout and updated version of originals and translations (with a read-only user) /wips/wip1 /wips/wip2 ... One directory per file traslation. Would be a ~common but partial~ directory checkout of file translated (or new) file and respective CVS/Root, CVS/Repository and CVS/Entities (partial). When a translation is done, the commit can be simple and the wipX directory is erased. []s André Æ
