[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 =?utf-8?q?Tr=C3=BCg?= <strueg () mandriva ! com>
Date:       2008-10-10 15:46:25
Message-ID: 200810101746.25977.strueg () mandriva ! com
[Download RAW message or body]

On Thursday 09 October 2008 18:09:35 Chusslove Illich wrote:
> > [: Sebastian Trüg :]
> > I hope this clears it up a bit. If not, please bug me some more. :)
>
> The way I understand it, then, is that it's like with a .desktop file --
> all the text content, including translations, comes bundled in the data
> file, because random apps fetch it (and user-supplied stuff added to that).

right.

> But, unlike with a .desktop file, I don't understand how is a random app
> supposed to fetch this or that grammar form? I mean, .desktop files have a
> certain set of fields according to specification, and that's it. Or you
> actually want exactly this, to come up with a spec/API for grammar stuff in
> Nepomuk, which apps can then follow?

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).
I figured to add the necessary API for other versions of the label there.

> It would be good (at least for me) if there is some example/demo code that
> shows the intended usage, i.e. how the message to be shown to the user is
> built. Or a few pseudo-code snippets...

OK, let me try to come up with a few.
First the simple one: categorizing search results. I get the type of the 
search results and create a list for them:

  Nepomuk::Types::Class type( mySearchResult.type() );
  categoryLabel.setText( type.labelPlural() );

Another example could be to list relations of a resource. 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() ) );
  }

Or back to types. Listing of all types in a nice way. The labelIsA() method 
uses a translated string for something like "%1 is a Friend":

  Nepomuk::Resource res = getResource(...);
  myTypeLabel->setText( res.type().labelIsA( res.genericLabel() ) );

> > Thus, the question is: how do these strings to translate need to look
> > like to cover most cases?
>
> Probably totally horribly. Keep in mind that we never came up with a "most
> cases covered" solution for something as simple as the fuzzy clock :)

I know that covering all cases is impossible. What I don''t know is if it 
makes sense to at least try to tackle the most important ones. It would just 
be great to improve the situation.

Cheers,
Sebastian

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