[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:       Sebastian =?iso-8859-1?q?Tr=FCg?= <sebastian () trueg ! de>
Date:       2008-10-13 10:42:36
Message-ID: 200810131242.36765.sebastian () trueg ! de
[Download RAW message or body]

On Saturday 11 October 2008 13:37:03 Chusslove Illich wrote:
> > [: Sebastian Trüg :]
> > Maybe you are right. So maybe we stick to simply adding a plural form and
> > leave it at that...
>
> Plural form would be fine, simple and obvious enough to use.
>
> I'm just wondering, who is supposed to add these plural forms? The writer
> of ontology file? Plural form would then also be available for translation,
> right?

yes, exactly.

> >> [: Chusslove Illich :]
> >> [...] if some ontology files are going to be translated in the same
> >> manner as .desktop files [...]
> >
> > [: Sebastian Trüg :]
> > that is the plan.
>
> These ontology files, where would they be -- scattered across modules, or
> in one or few concentrated places? I.e. what is the "ideal world" usage
> pattern, in what situations are they supposed to spring up?

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.

> Depending on this and previous question (on addition of plural form),
> translators may -- just may -- be able to do some fancy stuff when a random
> KDE app throws a message like "%1 is a %2". To this end, how conceivable
> would be the following:
>
> * that "context" can be provided to arbitrary words/phrases in ontology
>   files, akin to first argument in i18nc? So that it finds it's way into
> the extracted POT file (e.g. this is *not* possible with stuff from
> .desktop files)?

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.

> * if the previous is impossible, that at least every extracted text from
>   ontology file gets "automatic" context (e.g. "element path" or
> something), such that it never happens that two same texts in the ontology
> file (or files) are given as single message in a PO file?

What would be rather simple is to use the literal name (or some context string 
one would lookup in a table) that is extracted as context.
Example: <rdfs:label>friend</rdfs:label>. Here "rdfs:label" could be extracted 
as context.

> * that translators may insert extra properties, in some suitable format, to
>   phrases extracted in the PO file, and that these are then converted back
>   into proper ontology? For example:
>
>     # An ordinary translation:
>     msgctxt "..."
>     msgid "plum"
>     msgstr "šljiva"
>
>     # Translation with translator-inserted properties:
>     msgctxt "..."
>     msgid "plum"
>     msgstr "šljiva||gender:f|number:s"
>
>   where then "gender" and "number" properties, with values "f" and "s",
>   would be inserted into ontology file, filed under the language of the
>   given PO (i.e. if another language is actual when application tries
>   to fetch them, some sort of "undefined" is returned)?

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?

Cheers,
Sebastian

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