[Openstack-i18n] Collecting requirements to translation tools

Dwayne Bailey dwayne at translate.org.za
Wed Oct 30 18:48:25 UTC 2013

Hi There,

I was pointed to this discussion while on #pootle.  Let me give some
feedback on the items listed on your Google Doc adding info as needed and
correcting any errors that I see.


   *Cross-project translation teams*

   - Not 100% sure of the exact needs here.  Pootle has a user centric
      permissions model, users can have permissions for languages, projects and
      translation project (i.e. a project in a given language).

   *Cross-project translation memory*

   - Yes served from Amagama our global TM server.  Amagama is a publicly
      hosted server loaded with translations for FOSS projects, optimised for
      high speed Levenshtein distance measurement.
      - We're landing local TM in Pootle in the next few weeks.
   - *Strong Crowdsource community*
      - Does this mean the development team or the translators on a shared
      hosted platform, seems to indicate the later based on the
current analysis.
      - Simple management interface for project resources
      - Would someone mind elaborating on what the main benefits or use
      case for resources are for openstack?
   - Good in-browser management of resource priorities
      - Would someone mind elaborating on what the main benefits or use
      case for resources are for openstack?
      - While we don't have resource priorities Pootle does allow you to
      place files into goals.  These goals can be prioritised to ensure that
      translators focus on the most important aspects of translation first.

   *Proven success with large projects*

   - LibreOffice, Apache OpenOffice, Mozilla - Firefox, Thunderbird,
      Firefox OS and website localisations, Evernote.

   *API to gather statistics about translators*

   - Data is there, the API framework is in place but no active users so no
      finalised, published or stable API

   *Easily see the translating context, i.g. the paragraph or section
that contains the translation string.*

   - Yes. Have a look at
      - Surrounding translations even when moving through the editors in a
         filtered way.  You can expand and contract this context as
needed and it is
         hidden when stepping through all translations to remove clutter.
         - You will see location information e.g. file location as well as
         line number if that is the only context you have
         - msgctxt and notes are shown if present.  We don't show anything
         that doesn't exists, which might explain the current comment on the
         spreadsheet. Pootle UI approach is that we only show what is
available i.e.
         no comment then we won't show you a missing comment.

   *Cross-project glossary and dictionary*

   - Yes.  Cross-project, you can load any terminology resource into any
      language's Terminology project
      - A project specific terminology file can also be used.
      - We don't have any specific dictionary integration but use
      Weblookups for e.g. Wikipedia to make it easy to research source texts
      without leaving Pootle UI.

   - *Code maturity (age of the code)*
      - Pootle was officially released in Dec 2004, about the same time as
      - So almost 9 years of history in Pootle.  The Translate Toolkit is
      somewhat older.  Virtaal, our desktop translation tool, is younger.
      - Query by filename (eg to assign particular xml files for
   translation within a resource, as in Japanese ops guide translation)
      - Does that mean you have a repo but only want to see certain files?
         - Pootle can ignore files, so the opposite of that
         - Merging of uploaded PO files, so that only translations that
   changed in the PO file are changed in the project. Avoids overwriting when
   multiple translators work offline.
      - Yes, when uploading you have 3 choices, overwrite (if you have
      permission), turn conflicts into suggestion or make everything a
      - We err on making things a suggestion if we can't resolve the
      change.  So does mean you might need to review the suggestions for your
   - Performance of translation memory matching for non-latin languages
      - We use Levenshtein matching.  So we're not doing anything special
      for non-Latin languages.
   - Training available? (devs, users, none)
      - Not sure what the needs or wants are here exactly
      - We've trained localisers across Africa, in India and other places
      - Written localisation guides for FOSS
      - Run Translateathons
      - etc
   - Roadmap
      - We haven't published a public roadmap but will be doing that once
      we get 2.5.1 out the door.  Scheduled to go into beta this week.
   - Technical Support
      - Translate provides commercial support and development, primarily
      - There is an active community that assist on the mailing list and
      IRC channels.


+27 12 460 1095 (work)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-i18n/attachments/20131030/e0f2104c/attachment.html>

More information about the Openstack-i18n mailing list