[Localization] [FM Discuss] how do you use translate.fm?

Thu Apr 8 03:45:10 EDT 2010

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):

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.

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)

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)

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. :) )

from Clytie 

Vietnamese Free Software Translation Team

[1] http://translate.sourceforge.net/wiki/pootle/index
Talk to the admins/devs on #pootle on freenode

[2] http://wiki.freedesktop.org/wiki/Software_2fFonts
Dejavu is probably the best pan-Unicode font (GPL)

[3] http://po4a.alioth.debian.org/features.php

[4] http://translate.sourceforge.net/wiki/toolkit/index

[5] http://translate.sourceforge.net/wiki/guide/nonpo

[6] http://lists.laptop.org/pipermail/localization/2010-March/002527.html

[A] http://translate.flossmanuals.net/write

[B] http://www.booki.cc/