Pootle Issue List

From Apache OpenOffice Wiki
Jump to: navigation, search

This page lists all raised issues and requests regarding Pootle.

Pootle Issues

Overload with uploading file

1. Description
When a user try to upload files with merge option, it takes long time using full hardware resource and Pootle doesn't response to other requests until the merge job is done. For other users, their requests are timed out, thus it seems that Pootle server is down.

2. Cause

  • Merge process itself takes longer time and more resource than overwrite option.
  • The PO files for OpenOffice.org project are huge, and it take much longer time for large PO files.

3. Considered Solutions/Workarounds

  • Split a large file to several small files

This could help if people upload single files, but uploading a ZIP file with several files, will always take long, as it is going through all of them.

  • Upgrade cpu (add one more)

Pootle currently doesn't work in multiple threads, so adding a cpu won't really help now.

  • Upload with overwrite option

After finishing all the necessary work(i.e. translation,review and merge), translation lead uploads the files with overwrite option. Currently, most of translation teams work in this way.
Refer to suggested work-flow. Before uploading with overwrite, user has to make sure the files are valid.

I suggest adding a last-edited time/date next to each file, so we know if it's safe to overwrite.

However, in the long-term we do need the merge capability, so Pootle will need to accommodate heavier loads.

Pootle Feature Requests

Download Translatable Strings (issue id: 397)

1. Description
User can extract translatable -fuzzy and untranslated- strings from a downloaded file with pofilter. However it'd be helpful if it's also possible to directly download only translatable strings from Pootle.

2. Consideration
This might be interesting to work on, although it seems that it is mostly just the limitations of OmegaT that makes this an interesting feature. Translation of text without the surrounding context isn't ideal, and most other translation programs provide a way to find the untranslated elements (as far as I know). Still, this might be worthwhile.

Off-line Review (issue id: 398)

1. Description
Currently, review work only can be executed one by one on-line. If there are many suggested strings, it'll be less efficient. If there is an option to handle bunch of suggestions at one time, it'll be helpful. And also, making enable to download suggestions will be good for off-line review.

2. Consideration
The PO format doesn't allow for suggestions to be stored inside the file. So doing this with PO files might be really not worth it.
Currently the suggestions from Pootle will be stored in alt-trans tags in the XLIFF file. Not sure how easily offline translation editors will be able to make such an offline review phase with the information stored like this.

Pootle 1.2 Feedback

These are feedbacks during Pootle 1.2 testing cycle. (Nov. 2008)


  • Searching in comments is a great help (e.g as we used to mention par-IDs in our help issues)
  • Not much improvement with speed (File upload is still very slow)
  • Sometimes, not able to access the file by clicking on it because the search function was still active and can't reset it to blank.

Work with XLIFF files

  • Not able to open the files downloaded from Pootle in OLT v1.2.7
    • This is due to some incompatibilities of OTE's and pootle's xliff implementations. Hacked version of OTE is available.(You need a OTE 1.2.7 installation and replace TransEditor.jar file.)
  • KBabael failed (silently) to work on some of the xliff files. Seems, as there were some problems with the XML structure,so that changes were not saved by KBabel but no error message was given about this.
  • Offline comments are saved (and can be searched) but are not displayed.
  • Examining a suggestion, and accepting it, I have no access to the comment area
  • Pootle does not support status for segments at all. It seems, as the status which has been set by an external editor will be kpet - but this will result in wrong statistics given by pootle.

Alternative source language

  • Direct support for additional language is a great help (but could be improved)
  • It seems as if pootle is a little slower while editing segments online (loading of a segment for editing is slower).
  • Pootle seems to provide some automatic translation if the current segment is not yet translated in the alternative language. So you can end up with a wrong suggestion without knowing this. The problem hereis, that the string actually is just a suggestion but you don't know where it comes from. I would expect only suggestions from exactly the same segment but pootle suggests also fuzzy matches without giving a notice.
    • Talked to Friedel about this - there might be a fix/enhancement in a later version.

Working with xliff based projects in pootle

Feedback from the german l10n tema, using xliff-based pootle project for translating OOo 3.1. Process was:

  • merge new strings from OOo source to pootle using translate toolkit
  • download all strings from pootle (as zip)
  • filter new and updated strings using translate toolkit
  • distribute new / updted segments to translators and do translation using OTE
  • collect translations and review using OTE
  • merge translated strings back using translate toolkit

merging new strings to pootle

  • xliff meta-info get lost
  • Error: new segments get the status approved=yes (should be approved=no) locamotion bug report 743
  • Error: updated segments keep the status approved=yes (should be approved=no)
  • Error/Wish: for updated segments, the old translation is moved to an alt-trans node and target content is removed from the trans-unit. Instead Old translation should be kept in the target, the transunit should be market as approved="no" and state="needs-review" (translate toolkit's xliff storage class actually supports this, but it is not used)
this can be considered as error, all statistics generated by translate toolkit / pootle will fail to report a correct number of fuzzy strings - also triggers the next error
behaviour is not really clear maybe caused by the previous error that all segments in the template are "approved=yes" - need to ask Aijin for actual comand line to merge existing translations
  • Error / Wish: alt-trans nodes are not merged. Normally alt-trans node keep information about old translations of changed segments. At the moment there is no way to keep this information during several rounds of translation updates. If a changed segment is not translated and approved, the old translation will get lost with the next merge operation.
  • Error: if there is a .po file in parallel to a .xlf file, the translations from the .po file will be merged - merging the xliff-file will be skipped without giving any notice. If the .po file is older than .xlf translations will get lost. (We actually lost about 100 segments due to this) An warning or error shoould be reported in this case an all (non-conflicting) translations should be merged.
  • Wish: source file name and keyid (or par-id's) should be written to a context-group element (this is actually done when converting po-files to xliff)

filter new / changed segments

  • Wish: there should be an option in the filter tools, so that no comment gets added to the segments. Actually all those automatic comments need to be removed by our translators, to be able to use own comments.

merging translated strings to pootle

  • Error: notes on segments get lost during merge (even fails if --mergecomments=yes is set on merge)
  • Wish: Option to remove the "alt-trans" units (originally contained in the template) from the merged file. As translation was already reviewed we don't need the alt-trans units anymore. Only way I know is to remove them manually in pootle.
Personal tools