When someone uploads a new file into Pootle we need to know what we do with the new string in the uploaded file.
(This page is based on requirements for pootle. For more on implementation, see merge.)
Our current strategy is as follows:
The current strategy is coservative. Which is good if Pootle is resting on top of other systems. So if Pootle is another options after pure CVS translation, etc. Then we want Pootle to be highly conservative.
However, it is frustrating if you are using Pootle as a file store for your team to have to review each new translation that is uploaded. Especially if you are it :)
We need a system that does the following:
A quick and dirty solution for Pootle 0.9 is as following:
These are the things we should do for each type of inconsitency
Determine the status of files in Pootle:
If EPO and NPO POT date match:
Warn if POT is newer proceed regardless of their relation to POT
If EPO is up to date with POT and NPO is not:
Warn if NPO file is not updated to POT. Do update of NPO to POT on Pootle (considering some of the unique update things we do to it below) Now use this NNPO (New NPO) to update the EPO Allow user to download NNPO (they might want to correct the remaining issues and resubmit)
If NPO is up to date with POT and EPO is not
Warn if EPO file is not updated to POT. Allow user to update EPO if they have rights and redo upload Otherwise abandon upload
If neither all of EPO, NPO and POT are on same date
Do both EPO and NPO not up to date with POT steps
If EPO and NPO don’t match but are newer then POT
Warn about discrepency Update POT file if the user has rights Optional update NPO to EPO (might be older, we assume the PO on Pootle is well managed and the translator is wrong) Otherwise abandon update
Accept all blank messages from an NPO Reason: anything is better than nothing
If location is the same but source text is different then ignore NPO entry
If NPO is fuzzy and EPO is blank accept fuzzy NPO message
If the message in EPO is fuzzy but the message location and source text is the same as an entry in the NPO which is not fuzzy then merge NPO unit into EPO and remove fuzzy marker. Reason: All input stayed the same except the NPO translator did work - assume they must be correct.
If EPO is fuzzy and NPO is fuzzy and they are different then turn them into a suggestions in Pootle. Downloadable PO file should contain a Gettext conflict containing both NPO and EPO text.
This is the hardest issue to handle. The text being overwritten by the uploaded file might in fact be more correct then that that is contained in the uploaded file.
We will have already made sure that both NPO and EPO are based on the same POT file. This will make certain messages fuzzy, etc so any conflicts arrising from that are eliminated.
We have no record in the NPO as to what the previous string was before the transltors corrected/changed it. Without that we cannot inteligently resolve anything.
I think we need a #. (previous) entry for any PO file downloaded from Pootle. It bulks the PO file but we can live with that.
If we have a # (previous) entry:
If EPO and (previous) match and NPO is changed then accept NPO If they don't match then NPO into a suggestion with EPO as the default. NNPO must have a Gettext conflict and be marked fuzzy with EPO as the (previous) Allow review immediately
If we have no (previous) entries (PO not got from Pootle
Turn all entries into suggestions with EPO remaining as the default. User can download NNPO with the suggestions marked fuzzy and shown as Gettext conflicts of course also now with (previous) markings or the translator can review straight after the upload using Pootle.
We won’t have an issue of locations same and text different as we only merge text based on the same POT date.
If updating a Pootle entry that has suggestions. Follow all other rules, keep the other suggestions but if the NPO entry wins make it the default entry. Otherwise don’t add the NPO entry.
With the logic of (previous) we should eliminate a large number of problems with CVS
We need to store the PO file with (previous) and other markings separate from the reference CVS file, so that we can commit directly if needed and not introduce a large amount of cruft to CVS or the CVS files.
This allows us to merge CVS files similarly to an upload.
If there is a CVS conflict then use what is currently the text in CVS and turn it into a suggestion. Needs some though on what caused the conflcit. Its usually POT creation dates that cause the problem.
Also revert to any CVS marking eg fuzzy. Someone might have made it fuzzy for a reason eg some issue with the translation.