[FM Discuss] Fwd: [translate-pootle] how do you use translate.fm?

Clytie Siddall clytie at riverland.net.au
Fri Apr 16 06:38:42 PDT 2010


This is from the Pootle dev. list (sorry I couldn't forward it earlier).

Begin forwarded message:

> From: Dwayne Bailey <dwayne at translate.org.za>
> Date: 13 April 2010 9:42:59 PM ACST
> To: translate-pootle at lists.sourceforge.net
> Subject: Re: [translate-pootle] [FM Discuss] how do you use translate.fm?
> 
> Hi Clytie,
> 
> Thanks for being the go-between :)
> 
> On Thu, 2010-04-08 at 17:15 +0930, Clytie Siddall wrote:
>> To: FLOSS Manuals list
>> Cc: OLPC Localization and Pootle lists (reply to list and I'll copy it here) re. doc. translation workflow throughout i18n
>> 
>> Intro: FLOSS Manuals [A] is a collaborative docs interface, which is also used unmodified for translation. Booki [B] is the next evolution of this interface, and is currently in development. Ideas and feedback are sought, as well as testing and bug-reporting.
>> 
>> On 08/04/2010, at 12:46 AM, adam hyde wrote (in conclusion):
>> 
>>> if you have translated material using the translate.flossmanuals.net
>>> site can you tell us :
>>> * a little about your process (how you do it) and...
>>> * your thoughts on the current interface for translations (ie. the split
>>> window in translate.flossmanuals.net - is it good or are their better
>>> ways to do it...)
>> 
>> I've been using the split-screen approach. I've found that handy for dragging images from the original to the translated version, but as I say further down, that's not necessary. Translators don't need a split-screen.
>> 
>> FM is not a bad editing interface, but it's not a translation interface.
>> 
>> Even as an editing interface, I would like to be able to download _the whole manual_ and work on it offline. I found it really fussy and slow, inserting images into the Mifos manual using the FM server. I couldn't search for the INSERT tags globally: I had to open each and every chapter to find them. Each time I needed to insert an image, I had to wait for the insert-image window to open (which it always does at 4cm-square in the top LHS of my screen!). So, to insert an image (I had to do this _many_ times):
> 
> I tried the URL but doesn't seem like the interface is up there for
> review.
> 
> While split screen would be good to review the translation, as you say
> its a good editing interface. I must agree with you I don't think its
> the right approach to translation.
> 
> But if translated books are to be wide departures from the original then
> its not that bad. Although that wouldn't be where I'd start.
> 
>> 1. select the insert placeholder
>> 2. click on the Insert Image button
>> 3. manually enlarge the insert-image window
>> 4. wait for it to load (slow!)
>> 5. manually choose the /mifos/ directory (it always defaults to / : surely we could have a checkbox pref to say "remember directory")
>> 6. look for the requested image (slow and tedious, picking through the images)
>> 7. upload the image if it's not there
>> 8. find it (again) in the icon-view list
>> 9. manually fill in the settings (I had to fill in border-size=1, border-colour=black _every time_)
>> 10. insert the image
>> 
>> It would have been much easier and quicker for me to download the whole manual in its native format, insert the images manually from the supplied URLs, do any other edits, and upload the result (merge, not overwrite). We do this for translation editing all the time on Pootle [1], excluding images at this time.
> 
> Well it could be pretty easily achieved using Pootle if they where
> willing to help extend Pootle.  I don't think anyone should have to do
> anything with pictures as a starting point.  But you probably do want to
> upload pictures that are localised at the end of the translation, and
> you probably want to ensure that your translated text matches the text
> on screenshots.
> 
> But that could be achieved by making sure that a picture is displayed
> inline as another type of unit.  You can upload a new screenshot.
> 
> Since flossmanuals lyout is pretty restrictive I wouldn't see that as a
> major problem.
> 
>> For small, quick changes and editathons or translateathons, a web interface works well. For large or multi-chapter changes, offline editing works better. We need:
>> 
>> (a) global search within a manual (options for case-sensitivity and regex)
>> (b) download whole manual (compressed) for editing
>> (c) upload whole edited manual (merge): conflicts should show up in the manual chapter list (see (g)), and be shown in the interface so they can be resolved
>> (d) do we even have upload/download at the chapter level?
>> (e) an image-insert function which loads fast, displays a complete window, and has persistent options for filename-list (icon list is tedious with many images), remember directory and remember settings
>> (f) for tables, a default setting with e.g. "cellpadding=10". The default table has zero cellpadding and looks ugly, more difficult to read
>> (g) better status info in the chapter list, e.g. columns for images (status: reviewed and statisfactory, no images yet, needs review: green OK, red N, yellow R), conflicts (number), placeholders (number), review (reviewed, not reviewed or needs review: green OK, red N, yellow R))
>> (h) access restrictions (view, suggest, edit, upload image, upload file) to protect work done and quality of work input
>> (i) in html view, syntax highlighting!
>> (j) the ability to leave comments which are displayed in a separate frame, e.g. "Unsure if this is the right image: got it from X" in the original language, or "Should I translate A as B or C?" in a translator's language. Comments are distinct from placeholders, and can also be used to leave contextual info for the editor or translator, e.g. "You need to connect this up with Chapter X" or "'Write' is the name of a program: please don't translate it".
>> (k) UTF-8 _everywhere_; good Unicode font support on the server [2], including RTL input and display (assuming manuals written originally in different languages)
> 
> You have a lots of points here.  Its mostly frustrating for me that much
> of the important localisation technology is already in Pootle :( its
> just about adapting it.  If we got the ability download a whole manual
> done, it wouldn't be impossible to ensure that Virtaal as an offline
> tools can allow you to translate and change other resources like
> pictures.
> 
>> As for a translation interface, please see the info on Pootle [1]. A translation interface, whether for docs or program strings, needs (in addition to the above):
>> 
>> (l) translation memory support
>> 	just a file with the key vocab for that manual:
>> 	you translate that first, then if any of this vocab appears in the string (sentence or para) you're translating,
>> 	part of the interface shows the standard translations of that vocab.
>> 	On Pootle, you can click on an item in the vocab frame, and it will appear at cursor position in your translation.
>> 	Download-and-reupload means we can use our per-string translation memory offline
>> 	(huge time-saver for translators).
>> (m) string-by-string translation: this means segmenting the chapter into sentences or paragraphs;
>> 	do away with the split screen, have a single frame with the original text and original images
>> 	(to be approved or edited by the translator), and have the editing field focussed on the string being edited,
>> 	so you can still see the whole manual page (scrollable) and your translation results as you go
>> (n) per-string status: reviewed and confirmed, not yet translated, needs review (Y, N and R as above),
>> 	which means you can show stats for the translation in the chapter list:
>> 	numbers of Translated, Fuzzy (needs review) and Untranslated strings under T, F and N:
>> 	the translator hits a button in the string-editing field to change the status of a string
>> (o) in addition to (g) above: strings (Translated, Fuzzy, Untranslated: number)
> 
> You forgot terminology support.  And you forgot standard support like PO
> and XLIFF.
> 
> I've actually used FM to help write a book and I loved its approach and
> simplicity.  But I'm always frustrated when new approach lose all the
> valuable assets that are built into existing translation tools.
> 
> I'd rather see Pootle enhanced and improved to deliver good document
> translation.
> 
>> In the FM interface, I particularly like the chapter-list-view link "Conventions for writing this manual", the global embedded IRC chat and the live tracking of who's logged in, who's been active today and who's recently registered (Pootle devs take note. ;) )
>> 
>> Booki's development is especially important to FLOSS internationalization, because we don't yet have an effective workflow for docs translation. Currently, we use packages like po4a [3] and the Translate Toolkit [4] to convert [5] doc files to PO format or XLIFF format, then edit them in our current feature-rich program-strings translation editors. There are issues with update (how does the translator know which doc strings need updating and when?) and project integration. Please see this thread [6] on the OLPC Localization list. (It brought me here. :) )
> 
> -- 
> Dwayne Bailey
> Associate             Research Director        +27 12 460 1095 (w)
> Translate.org.za      ANLoc                    +27 83 443 7114 (c)
> 
> Recent blog posts:
> * Translate Toolkit - a powerful localisation toolkit
> http://www.translate.org.za/blogs/dwayne/en/content/translate-toolkit-powerful-localisation-toolkit
> * The sky's the limit for new Zulu spell checker
> * Everyone has the power to champion their language
> 
> Firefox web browser in Afrikaans - http://af.www.mozilla.com/af/
> African Network for Localisation (ANLoc) - http://africanlocalisation.net/



More information about the Discuss mailing list