[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-i18n-doc
Subject:    Re: kbabel in kde4
From:       Gudmund Areskoug <gudmundpublic () gmail ! com>
Date:       2007-08-14 8:59:12
Message-ID: 46C16F71.4090809 () gmail ! com
[Download RAW message or body]

Hello Chusslove,

Chusslove Illich wrote:
>>> [: Nick Shaforostoff :]
>>> [...] [no full-auto rough translation] because sometimes one english
>>> string may have two or more different translations depending on the
>>> context.
> 
>> [: Gudmund Areskoug :]
>> then how about taking context into account? [...] or through context info
>> derived from file name, header info and surrounding info, or through
>> parsing and comparing the actual text context where possible [...]
> 
> Given that the software and its development are not black-boxed to us, there
> are also some things that we can do and promote on the code/programmer side,
> to make the job easier both for translators and possibly vigilant
> translating tools.

I know :)

> For example, whereas your 2002 post on gnome-i18n that I managed to dig up
> :) 

My memory fails me, those posts I thought of (hierarchical subject
tagging systems - open, of course) may have gone straight to various
developers and others involved. Sorry.

> concerns with enabling translators to "spread" contexts within their
> language/team, the programmers could do part of that via more formal context
> to gettext calls (as represented by the new PO msgctxt keyword), which then
> helps all languages. Such a system is currently advised for new KDE code,
> check the POT of Dolphin (
> http://websvn.kde.org/trunk/l10n-kde4/templates/messages/kdebase/dolphin.pot?revision=HEAD&view=markup
> ) for usage example.

Thanks, will do. I know these things are underway, and have been for
some time already. Wouldn't it be nice if a tool like Kbabel/Kaider made
use of them automatically in the matching process? Perhaps it's all in
Dolphin, will have to read up.

> Then, recently we've introduced i18n checks to KDE's code checking
> infrastructure (Krazy), so that many ambiguous messages -- currently by
> virtue of translators having listed them, or being a lone adjective -- are
> being reported along with rest of the code checks, e.g.
> http://www.englishbreakfastnetwork.org/krazy/reports/kde-4.0/kdegraphics/okular/index.html
> (look for i18n checks).

Will take a look at that too (not least to see if someone already
thought of back-checking, to see whether a term/string in the target
language has been used as translation for different things, not just
that one source has the same translation everywhere.

>> Gudmund, with some experience from one of those expensive commercial tools
>> (not Trados) ;)
> 
> Indeed, I wonder sometimes how well, hm, adapted the commercial CATs would
> be to the processes that we have in free software.

They've got a lot to learn, and as you say - the processes, like e. g.
openness between translators in the same project, peer review, TM and
terminology sharing etc., and not just the software itself.

Just BTW, the commercial tool I'm using has at least limited support for
PO files.

> I've never used them
> personally, nor were engaged in any commercial translating effort, but from
> what I've read and heard, it seems to me that the commercial translation is
> wholy a different world.

Different, but not so different that experiences from one aren't useful
in the other. Both ways.

> It seems to be bent around the concept of "my employer is my world" and
> "we'll translate whatever we're thrown at",

:-D, that's the worst case scenario. Most colleagues I communicate with
(most are freelancers) don't work in quite that way.

> which is probably a reasonable
> bussiness plan, but does not hold for us. For example, I've heard some tools
> will allow you to "open an EXE file" and translate strings therein; if
> someone would approach us with such a suggestion, we'd tell him "please come
> back when your program is sanely prepared for localization" or something
> worse. Or translate live HTML, where in the first place we'd probably have
> Docbook, and then extracted to PO to integrate well into translation
> process.

What you say is exactly what I (and most/all of my closer colleagues) do
too - it's customer education. If they don't want to learn, they're
welcome to ask someone else for translations.

> Hence, I consider these "advanced" features more of malfeatures. Precisely
> due to such kludges, I think that, say, translation memory (which I've heard
> is usually considered an in-house bussines secret) and variants of auto/
> assisted-translation are of great importance in commercial CATs -- they
> simply cannot make assumption on the sanity of the environment outside their
> reach, or that translators could take action to influence it.

In short, there's a whole spectrum, from the agency-controlled
"dictatorial", quantity-oriented commercial translations, to the
quality-oriented ones that work a lot more like the open source world.

> I think that our specialized tools should be much, much more focused on the
> strength of having code freely available, and programmers and other language
> teams working in cooperation as a norm. To have tools which will make easy
> for an action taken by one translator (such as something to do with
> contexts) to spread as far as generally useful, to other language teams and
> programmers.

Yup. Including sharing some common context/subject tagging, enabling
tools like Kbabel/Kaider to help the translator more in that process.

BR,
Gudmund
[prev in list] [next in list] [prev in thread] [next in thread]