Translate Toolkit & Pootle

Tools to help you make your software local

User Tools

Spec: Upload and Download merging

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:

  • If the message on Pootle is untranslated then add the translation
  • If the message on Pootle is translated then make the new translation a suggestion

Problems with current strategy

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:

  • Doesn't require tedious acceptance of review items when you upload a file
  • Doesn't mess with changes that might have been made upstream in CVS, ie doesn't overwrite them

Quick Solution

A quick and dirty solution for Pootle 0.9 is as following:

  • Add an option during upload to overright existing translations
  • Otherwise turn all non-blank changes into suggestions

Long term solution

These are the things we should do for each type of inconsitency


Determine the status of files in Pootle:

  • Date
    • POT file
    • Existing PO file (EPO)
    • Uploaded PO file (NPO)
  • Status
    • Existing PO up to date?
    • Uploaded PO up to date?

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

EPO Blank Message Updates

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

EPO Fuzzy Message Updates

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.

EPO translated and not fuzzy

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.

Pootle Suggestions

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.

CVS merging

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. FIXME 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.