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

List:       kde-i18n-doc
Subject:    Re: usage of &kappname; in documentation
From:       Park Shinjo <peremen () gmail ! com>
Date:       2009-03-05 4:45:30
Message-ID: b36f065f0903042045x45ad095fo225ccf05f8fe7a02 () mail ! gmail ! com
[Download RAW message or body]

2009/3/4, Sergiu Bivol <sergiu@ase.md>:
> În data de Marți 03 Martie 2009 22:25:15 Burkhard Lück a scris:
>
> > Am Mittwoch 25 Februar 2009 01:18:45 schrieb Chusslove Illich:
>
> ...
>
> > > The problem for declination-heavy languages is the following. When I see
>  > > "...of Okular..." I will translate it in my language as "...Okulara...",
>  > > where the "of" preposition is replaced with masculine genitive ending -a.
>  > > Or, "...with Okular..." becomes "...Okularom...", etc. Furthermore, when
>  > > the name is feminine-like, the root and endings change, so e.g. "...of
>  > > Okteta..." becomes "...Oktete..." (-a stripped, -e added).
>  > >
>  > > For this reason in my language we completely do away with entities when
>  > > translating documentation; when I see "...of &okteta;..." I replace it
>  > > with "...Oktete...", no entity there. If, however, the the proper name is
>  > > masked as "...&kappname;..." then I have to check what it actually is, in
>  > > order to know what to replace it with. This check should waste little
>  > > time overall, but there's a much more serious issue: if the name changes,
>  > > I don't get a fuzzy in PO file, and thus don't get signalled that I
>  > > should modify the translation.
>  > >
>  > > This is basically the same problem as "word puzzles" in UI messages.
>  >
>  > opinions from other teams?
>
>
> Romanian also uses declination and is affected by „&kappname;" as much as
>  Serbian is. As far as I am concerned, „&okteta;" or even „Okteta" make much
>  more sense.
>
We Korean has minor issue in some postpositions, though there is a
workaround for this situation. Actually we have a nice solution for UI
messages: Transcript.(1) If we have pluggable Javascript interpreter
that is able to process docmessages instead of messages, we may reuse
Transcript's js file in document processing.

(1) http://techbase.kde.org/Localization/Concepts/Transcript

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