Date: Tue, 18 Feb 2014 20:50:43 +0100 From: Benedict Reuschling <bcr@FreeBSD.org> To: freebsd-doc@FreeBSD.org Subject: Re: Translations (was Re: svn commit: r43974 - head/en_US.ISO8859-1/books/handbook/advanced-networking) Message-ID: <5303B993.2030505@FreeBSD.org> In-Reply-To: <2A866B00-A040-4726-AD95-04E0F413FEBC@FreeBSD.org> References: <201402180226.s1I2QS0x076422@svn.freebsd.org> <5302C7B9.7090208@delphij.net> <alpine.BSF.2.00.1402171940210.42338@wonkity.com> <5302E05F.1050200@delphij.net> <alpine.BSF.2.00.1402172145010.42338@wonkity.com> <B3ED89A2-6692-4B51-98BF-3F47081800AE@FreeBSD.org> <alpine.BSF.2.00.1402180856070.47821@wonkity.com> <2A866B00-A040-4726-AD95-04E0F413FEBC@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Am 18.02.14 20:21, schrieb Remko Lodder: > > On 18 Feb 2014, at 17:17, Warren Block <wblock@wonkity.com> wrote: > >> On Tue, 18 Feb 2014, Remko Lodder wrote: >> >>> My project at work is not able to keep up with the ?content >>> spree? that Dru is doing to make things better. Good work, but >>> a drama for translation teams that need to be in sync first >>> (and with a train that moves so fast, it will remain out of >>> date). >> >> Maybe the only way to do that is translate a fixed >> revision/snapshot. At least with our existing system. >> >>> Do note that translating strings of text might have a dramatic >>> result; especially in non english versions, one translation >>> might fit the one line but the other line wouldn?t fit. >>> Although ofcourse this sounds interesting there is much more to >>> it. (we do not have a set of predefined things we mention like >>> $_[LANG] = ?The bird flew over the house?; which is used once >>> or perhaps twice. We have ?rolling? content like a book. >> >> Translation software like Pootle or poedit generally gives the >> translator the choice. Content is shown in chunks, like a title >> or a sentence. If one or more translations of that chunk already >> exist (either from the current document or a different one!), the >> translator can choose from them, or enter a better translation of >> their own. >> >> This would radically change the way we do things. Translators >> would still need to be aware that source documents had changed, >> but the translation software would identify parts that were not >> yet translated. It would ease the job for existing translators >> and lower the threshold for new translators. >> >> Obviously, this is all vague and ill-defined. Actual >> implementations that can be tested would be much more useful. I >> believe the tools in textproc/po4a are from Debian and somewhat >> dated. textproc/itstool might do a better job separating content >> if we can just get it to recognize and use our XML catalogs. >> >> An easy way for translators to try it out is the next step. > > Since I do not have -that- much free time at the moment, and a new > assignment might interfere with my current project, I cannot do the > heavy lifting of this. I am willing to test this though if someone > has something that I can try to work with. > You can start with the <mini-howto> I posted earlier. That's what I used. I recommend you try it with a small article (or you cut one down to like two <para>'s) to see results early without having to translate the whole thing. I've used poedit because it is multi-platform, but I still did an iconv run before commit (if you want to go that far). The important stuff lies in the po-file later on, which you can also feed into poedit to build up a translation memory to be used for another document. For me, this is the most important thing: reuse. I don't know how many times I've translated "Enter the following command" and similar phrases. With this new approach, these would be fed from the translation memory (of course, you can or make small changes to it like Warren mentioned) and concentrate on the new, untranslated strings. The same is true for words like MAKEFILE, names of products, people, and similar things that don't need to be translated. Sharing these in a common database across translation projects will ensure a consistent vocabulary. Putting these strings out for anyone to translate would be a good thing to get more translations than we already have. Collecting these in a database for mixing and matching them to a final translated document is the next step and would probably be done by someone familiar with the source material. But the burden of doing the actual translation work can be put into the hands of people who don't need to know how our doc toolchain works or even how the xml documents look like. That is still the work for a doc committer, but the tedious part could be put on many more shoulders. Regards Benedict -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) Comment: GPGTools - https://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCgAGBQJTA7mTAAoJEAQa31nbPD2Lr6UIALg9+edKEk7AgBGY2iyZl4nl XUgosad0QvaN4OXf9dQjuR2B8KTZfc0PibyeVbjtszBWNBdLDDO5A50JgLKY6Rk2 aghijDZ8C+kR2P5FUQgGe4V1bKdI72OfQphpp/u7jMyacY0ZAgenxPBez5/RVOdA pt84xMeL19yIfEech0ZwBYVbz1Cb37FMI3AnUlhBUhkANU4IxWEP8ZkvP0XeEHLG ADhzcNn4/dzVE1y+0fC0S4S0vijq9VT4o2bH+m1U6lGOo3DUZEtLwUFyRkCgrwGa lOVbdsH4+fSScPb2KT1wjuHK0TRDdvgCPFfDzOnXL0IagsogDBhzLIJKu/lJ2+8= =+OuL -----END PGP SIGNATURE-----
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?5303B993.2030505>