Filip Miletic wrote:
>translate-pootle-request@... wrote:
>
>
>
>>This will depend largely on what we, the translators want. What do you
>>think would be the most effective way to manage glossaries, and the
>>best TM procedure and format?
>>
>>
>
>May I interrupt this conversation with some ideas?
>
>IMHO the unfortunate truth about translation, but also many other tasks
>that might be automated by the computer, is that the way it is done at
>present is not really too advanced.
>
>Let's illustrate with an example.
>
>In the past, in times before computers and keyboards, the book
>translators had to do it all. They had to read the text, make sense of
>it, transform it in the spirit of the target language, maybe dig through
>tomes of dictionaries to finally either commit the translation to paper
>or to tap the keys of the typewriter.
>
>Today, in the age of computers, most of the time the only improvement to
>this process is that we've exchanged the paper or typewriter for a
>computer screen and keyboard. Similar holds for some other common
>computer aided activities as well.
>
>This is indeed a pity, as so much more work could in fact be delegated
>to the computers.
>
>The l10n problems that I have noticed are as follows:
>
>1. People with a good understanding of the language rarely understand
>the technology as well.
>2. People with a good understanding of the technology rarely understand
>the language as well.
>3. A lot of technology shines through when l10n'ing programs. You have
>to know about .po files, C format strings, CVS --- things that are far
>from being essential for good l10n.
>4. The l10n tools have developed in a fairly independent fashion, making
>it necessary for the people to understand each of the technologies to be
>able to participate. This turns away people who might be able to help,
>since you really need to know about CVS, PO, emacs, etc. just to make it
>over the entry barrier: an unlikely effort to spend for many but the
>most devoted.
>
>It requires that the user does a load of work by hand, despite that it
>could be automated well. With this respect, we are not far away from the
>translators from 50 years ago:
>
>If I don't know what a word means I still have to look it up manually in
>dictionaries.
>
>If I translated the same phrase 50 times, if it comes by the 51st time,
>I will still have to retype it manually -- or manually cut/paste,
>whatever. This includes searching for the phrase in a set of files,
>selecting it and transferring to the new translation.
>
>
I agree, this is a good description of the problems facing translators...
>Even if I type 300 words per minute in my favourite editor, to go along
>with say Pootle I will have to confine myself to the tiny edit window
>inside a web browser, that does not support all the nifty things built
>into the editor I use, and the extensions I made over the years. If you
>know this scenario, you will know it hurts.
>
>Yes, I can download the .po file for own use, and play around in the
>editor, but that defeats the purpose of Pootle. gcc.po has thousands of
>strings and it would be _absolutely_ great to be able to distribute the
>translation effort.
>
>
Agreed, this is a problem with the current Pootle interface, but let's
separate it out:
- The window is too small (fairly easy to fix)
- The editor is limited (this is outside Pootle's control but you can
get extensions to browsers to embed other editors)
Ultimately I'd like to create a rich web interface with Pootle but this
is first things first...
>I believe that the Pootle philosophy of 'all programs in all languages,
>in one place' is not the best of approaches, although it is clear to see
>that on the small scale it works pretty well.
>
>
Who said that was the Pootle philosophy? I've tried to make it clear
that its an open source project and you can run your own Pootle, as some
people have started doing. What Pootle aims at is to make it *possible*
to put all languages and projects in one place ... but also to make them
distributed.
>Why would, say, I have to depend on the original Pootle project for a
>set of programs of local interest?
>Or, why would it not be possible for a group of translators to 'check
>out' a set of packages and work on them on a Pootle repository away from
>
>
That's exactly what we've done in South Africa at translatathons, we run
a local Pootle in a lab. It makes it much faster. Then afterwards we
resync with the main Pootle if required.
>This is not said to offend anyone of the kind people from
>translate.sf.net or anywhere else; it is rather the line of thought to
>arise _naturally_ when you try to build translation organizations. I.e.
>you can expect independent copies of Pootle _will_ spring into
>existence. The Pootle project should make sure that they do not become
>isolated islands of functionality.
>
>
Right, preventing isolated islands will be done by integrating version
control and merging between Pootle installations.
>Most of the time, the l10n motos of today are: "To translate, use tool
>X, here and now."
>
>The goal should IMHO be: "To translate: use any tool, anywhere, any time."
>
>
I like that goal.
>Some ideas on the useful features:
>
>1. Ability to link different translation sites together, to be able to
>share, synchronize, review translations in a _truly_ distributed way.
>
>
I've had some thoughts about this. First step is just using actual PO
file URLs + merging, and allow people to manually synchronise (in the
same way one would with CVS).
>2. Ability to allow arbitrary tools to be used for translation: web
>interfaces, editors dedicated programs etc.
>
>
Peter Damoc was trying to encourage something like this with POEdit -
still more work needed there.
>3. Ability to combine different translation efforts automatically.
>4. Ability to cooperate automatically with other translation
>technologies such as online dictionaries, version control, content
>management.
>
>
There are so many technologies here it has to be done one step at a time.
>5. Ability to also use other means for translation: IM, IRC, news, mail etc.
>
>Rather than trying to make Pootle a huge program to incorporate all of
>these features, it would be more interesting to try to define a (sort-of
>standard) interface that should be used by translation tools.
>
>Any tool conforming to this interface would be able to join to the
>community of translation programs. You would then have interfaces to
>access web front ends, versioning control, dictionaries, translation
>repositories, translation exchange etc.
>
>
This is a nice idea but I'm not sure we're ready to standardise these
things yet.
Reason? A lot of these interfaces don't exist yet! But we can and should
work on it step by step.
>Long story short, the Internet was a success because people understood
>the importance of having the same interface on a planet-wide scale.
>Nobody enforces central data management, nobody enforces the protocols.
>
>An example of a simple fully distributed service on the Internet of
>today is the NNTP (i.e. Usenet newsgroups). Some lessons may be drawn
>from there.
>
>
Well we'll see where these things go. Thanks for your suggestions!
David
|