>> > Your example shows, that it is necessary to "update" before "commit". The
>> > same issue is valid for subversion and probably also for the other VCS.
>> >
>> > Maybe we should change pootle's code to do an update before commit by
>> > default?
>> >
>> >
>> > Did I get your point now?
>>
>> Hey, you really wanted to say another thing, didn't you? If Pootle
>> does as you say all the last work will be lost!!
>
> I guess, we misunderstand each other here. See below.
Yes, you are right. My apologies.
>> IMHO the things are that way:
>>
>> Suppose you have the version 59 of the file translation.po. The
>> translation.po changes in the vcs, and before you update the local
>> copy with the newest 60 version (created after synchronize the
>> translation.po with a new .pot file), Pootle makes changes to the
>> local 59 copy, so for Pootle this is the new 60 version that it is not
>> the same as the vcs one.
>>
>> So when Pootle tries to commit (in git is pull, isn't it?) ...
>
> from my understanding, you mean "push".
Sorry. I also change "pull" and "push".
>> ... the translation.po it fails, because the two files (vcs one and Pootle
>> one) have the same version number, the 60.
>
> correct.
> That's why I proposed, that the update should happen before commit/pull.
> Otherwise any VCS will refuse to commit an outdated local copy.
Here is the problem. I understand that with update you were talking
about the vcs action, and not about "updating from POT" (I usually
call this "merging with POT"). My fault.
>> And of course, before a local update (syncronize with the vcs version), you
>> have to do a commit to save into the vcs the latest changes made in Pootle.
>
> as I stated before, an "update" (in the way it is currently implemented in the
> translate toolkit) will do this:
> 1) store the current state of the file in memory
> 2) revert local changes of the file
> 3) update the file from the repository
> 4) merge the previously stored content of the original local file with the new
> file, that came from the repository
> This procedure allows us to do the merging with regard to translation units
> instead of trusting the line-based merging of the respective VCS.
> See Pootle/projects.py (line 542) and Pootle/pootlefile.py (line 646) for
> details.
>
> I do not see the data loss here, that you mentioned in the beginning.
> Could you elaborate, please?
As I said above I misunderstand you because of the word "update".
Sorry. But I have to point that keeping the local file with changes in
the memory could be a bad idea if the computer or server that hosts
Pootle unexpectedly loss the energy supply.
>> If you have a .pot file, there is no problem. If first you make a
>> backup of the local modified translation.po (local 60 version bis),
>> and then you update the local copy downloading the newest .pot file
>> from the vcs, and also the version 60 of translation.po replacing the
>> local 60 version (this should be a way of forcing doing this, but I
>> only know a few commands of svn). Then you could move the backup
>> (local 60 version bis) replacing the downloaded translation.po, making
>> it the new 61 version of translation.po, and finally you locally merge
>> it with your latest .pot file (the vcs one). Finally you only have to
>> do a commit to save the changes in the vcs.
>
> po files and pot files are currently updated separately.
> Assuming, that both the po and pot file in the repository are in sync, this
> should not cause problems.
> Could you provide a specific recipe to reproduce a potential problem, please?
I don't understand this question. I think I have considered all the
potential problems here.
>> But sometimes you don't have any .pot file, so we have a great problem
>> here. The only solution in this case is to use a Translation memory,
>> that saves all the translations made by the Pootle users. Then when
>> updating, if the file is updated (forcing the update, because the two
>> files are 60 version) with a newest version from the vcs, Pootle
>> should run an automatic translation with exact matching using the
>> translations saved in the database in order to try to maintain the
>> translation level of the file. Just after that Pootle should make a
>> commit (or a pull in git), to save the changes in the vcs.
>
> I think, this basically matches the current implementation, that I described
> above as step 1 to 4.
> Or am I wrong?
No, you are right, except for maintaining the local file with changes in memory.
>> I think this is the only way. I hope this will be helpful.
>>
>> Ah. And of course, this things should be automated to avoid human
>> intervention.
>
> Yes, I agree, that Pootle should always do an update before commit to avoid
> the problem, that you described in the beginning of this mail (caused by the
> outdated local file).
Yes.
>> Another thing, is there any way to making translation memories in
>> Pootle, and importing and exporting them as TMX files??
>
> This is b
