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

List:       kde-i18n-doc
Subject:    Re: kbabel in kde4
From:       Chusslove Illich <caslav.ilic () gmx ! net>
Date:       2007-08-13 16:25:05
Message-ID: 200708131825.08415.caslav.ilic () gmx ! net
[Download RAW message or body]


>> [: 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.

For example, whereas your 2002 post on gnome-i18n that I managed to dig up
:) 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.

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).

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

It seems to be bent around the concept of "my employer is my world" and
"we'll translate whatever we're thrown at", 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.

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.

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.

-- 
Chusslove Illich (Часлав Илић)
Serbian KDE translation team

[Attachment #3 (application/pgp-signature)]

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