Translations (was Re: svn commit: r43974 - head/en_US.ISO8859-1/books/handbook/advanced-networking)

[Benedict Reuschling]

-----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 at 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-----