Hi Clytie, Thanks for being the gobetween :)
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 fr 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/ ------------------------------------------------------------------------------ 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 [email protected] https://lists.sourceforge.net/lists/listinfo/translate-pootle
