[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-10 19:00:45
Message-ID: 200810102100.45996.caslav.ilic () gmx ! net
[Download RAW message or body]


>> [: Chusslove Illich :]
>> [...] Or you actually want exactly this, to come up with a spec/API for
>> grammar stuff in Nepomuk, which apps can then follow?
>
> [: Sebastian Trüg :]
> Nepomuk already contains an API to access types and relations
> (Nepomuk::Types::Class and Nepomuk::Types::Property). [...] I figured to
> add the necessary API for other versions of the label there.

Ok, so API it is, and...

> [...] The labelReference method would use the translated string containing
> two placeholders for a resource and the value of the property:
>
>   Nepomuk::Resource res = getResource(...);
>   foreach( Property prop, Variant value, res.properties() ) {
>      myList.append( prop.labelReference( res.genericLabel(),
>                                          value.toString() ) );
>   }

...by this I think understand how you intend it to be used by applications.

Based on nothing but personal feeling, I think that, from programmer's point
of view, this would be overly complex and inflexible. Complex in the sense
that even if such API is available, you'd find that random apps are rather
doing something like:

  Nepomuk::Resource res = getResource(...);
  foreach( Property prop, Variant value, res.properties() ) {
      resName = res.genericLabel();
      propName = prop....;
      valueStr = value.toString();
      myList.append( i18n( "The %1 of %2 is %3", propName, resName, valueStr ) );
  }

and inflexible in the sense that I don't think that one particular string,
e.g. as provided by prop.labelReference() from your example, would be
suitable (formatting, ordering, etc.) for arbitrary needs.

In other words, even if "enough" grammar cases are covered by existing form-
declining and sentence-combining API functions, there would probably be much
more ways and forms in which programmers would want to combine the data for
output in apps, so they'd simply skip using the special functionality.

> Nepomuk already contains an API to access types and relations
> (Nepomuk::Types::Class and Nepomuk::Types::Property). So far they allow
> access to rdfs:label and rdfs:comment via label() and comment() methods
> that always use the translation according to the currently configured
> language (if that label or comment has actually been translated).

Therefore, I'd just not care for grammar, English or other, and leave API as
it is -- providing direct information only. Apps are anyway full of i18n
calls such as in my example above.

On a side note, if some ontology files are going to be translated in the
same manner as .desktop files -- something extracts them into POs, and then
puts translations back into original files -- it would be good if such POs
would have a distinct prefix in the name, say ontology_*.po (again like
desktop_*.po).

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

["signature.asc" (application/pgp-signature)]

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