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

List:       kde-i18n-doc
Subject:    Re: Please discuss: Translation of types and properties in Nepomuk
From:       Chusslove Illich <caslav.ilic () gmx ! net>
Date:       2008-10-13 12:55:31
Message-ID: 200810131455.35585.caslav.ilic () gmx ! net
[Download RAW message or body]


> [: Sebastian Trüg :]
> ATM the most commonly used ontologies are in kdebase/runtime/nepomuk/
> ontologies. But at some point in the future any application may bring
> their own little ontology. One may even think of ontologies on kde-
> apps.org.

Thought something like that.

> This could in theory be done using comments with a specific syntax like
>   "###i18n --> THIS IS THE CONTEXT <-- ###"
> These comments could always refer to the next defined string by
> convention. Although I don't see why this won't work in desktop files so
> maybe I misunderstood.

Hm... now that you point out the obvious, I must reconsider why we don't and
whether we should support contexts in desktop files :) No reason why
something like this would not work.

> Example: <rdfs:label>friend</rdfs:label>. Here "rdfs:label" could be
> extracted as context.

Yes, that would be very good. Just like in desktop files now we have field
name in context, like "Name", "Comment", etc. Should be combined with the
previous, so that:

  <!-- i18n: in cryptography -->
  <rdfs:label>key</rdfs:label>

gets to be translatable as, say:

  msgctxt "rdfs:label# in cryptography"
  msgid "key"

> You mean to introduce optional additional grammar here? I think extracting
> thses properties from the translations is simple. But then wouldn't it be
> necessary to allow multiple translations of the same term? Or did I
> misunderstand?

Let me refine/simplify/generalize the idea.

For any Nepomuk API function that returns a localized field (name, comment,
etc.) of some object, there should be a way to fetch "translation data" of
that same object/field, which is a random string possibly provided by the
translator next to real translation. For example, if:

  msgctxt "rdfs:label# in cryptography"
  msgid "key"
  msgstr "ključ||blah-blah-blah"

then in code:

  type.label() // returns "ključ"
  type.labelTrdata() // returns "blah-blah-blah"
  // or perhaps:
  type.trdata("label") // less API, but not compile-time checkable

It is entirely optional how to represent this trdata in ontology file;
perhaps even as attribute to localized element:

  <rdfs:label lang="sr" trdata="blah-blah-blah">ključ</rdfs:label>

(I've no idea what are the constraints on the format, but whatever it is
that makes possible, in principle, to add plural and other grammar forms,
should work for trdata too.)

This is used in the following way. A random KDE app at first does the usual:

  QString msg = i18nc("...", "%1 is a %2", res.label(), type.label());

When "need trdata" request comes from a translator, it changes to:

  QString msg = ki18nc("...provides dynamic contexts...",
                       "%1 is a %2")
                .subs(res.label()).inContext("td-1", res.labelTrdata())
                .subs(type.label()).inContext("td-2", type.labelTrdata())
                .toString();
  // Number in "td-x" context label corresponds to placeholder number,
  // for convenience.

(this is the actual i18n API, nothing pending implementation).

And that's it on the side of Nepomuk API, ontology file translation, and
usage in random KDE apps. This is sufficient to enable each language,
independently and behind the scene, to support as much of the grammar as its
translators can algorithmically define and implement.

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

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

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