Friedel's ideas on the Translate Toolkit list: Begin forwarded message:
> From: F Wolff <frie...@translate.org.za> > Date: 27 March 2010 1:31:11 AM ACDT > To: translate-de...@lists.sourceforge.net > Subject: Re: [Translate-devel] Translating the manuals? > ... > > I only have a few loose thoughts. > > >> I'd be interested to see suggestions from translators, coordinators >> and the Pootle/Translate-Toolkit devs on what we really need to make >> doc translations effective and sustainable. Can we simplify or build >> on the po4a/Translate-Toolkit/Pootle process? Can we integrate other >> existing XLIFF tools? What works for you? What would work better? > > I haven't personally done a lot of translation of documents for FOSS > projects - it simply hasn't been my priority yet for almost any project > I contribute to while GUI translations are usually far behind. I often > translate what I use, and I honestly don't use the docs of most software > a lot. > > I think there are a few easy (and obvious) answers, but with several > aspects outstanding that will have to continue thinking about. > > A big issue for me is access. You mention version control and Pootle as > means of exposing document translation. If people don't find it easily, > they will probably translate something else which they can find easily. > Some websites that I have translated were those where there is a single > PO file easily available. > > Secondly file formats, which for me is partly an issue of access. If I > can't use my preferred translation tool, I'll probably just translate > something else. I agree with Chris that gettext made things easy enough > to some extent in software l10n. All documentation is authored in > monolingual formats not designed for translation (which is fine!) which > means we have a few issues to solve if we want to translate them. There > is a bit of a write-up on the wiki about monolingual formats and > translating them: > http://translate.sourceforge.net/wiki/guide/monolingual > (Of course it also applies to monolingual files for GUI translations, > not just docs.) > > But then there is another issue: we need to start writing documentation > with translation in mind. Just as we petition programmers to use good > i18n practices such as variables, comments, and review of the source > text, we need to do the same with documentation authors. And yes, time > is always a problem, and documentation is not always written as the > primary activity that someone is contributing to a FOSS project, so > giving extra demands on them might not have the desired outcome. > However, the quality of the source text is an issue. If the quality is > good, they are also more likely to be stable, in other words, your > translation might stay relevant for a longer time, also meaning that > updates should take less time. > > Documentation is also a bit different in the sense that incompletely > translated documentation is probably more bothersome than a partially > translated GUI - I guess some people might disagree. > > The upsides are that translating the documentation might give you a > better understanding of the software, which can improve your GUI > translation. For web stuff it can improve the search engine ranking in > your language, leading to more exposure, etc. > > Just some thoughts while busy with a lot of other things... > > Friedel > from Clytie Vietnamese Free Software Translation Team -- To UNSUBSCRIBE, email to debian-i18n-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/b248edef-dfe5-4964-82b6-75f5a522f...@riverland.net.au
