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/
------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
_______________________________________________
Translate-pootle mailing list
Translate-pootle@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/translate-pootle
