[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-11 10:27:57
Message-ID: 200810111227.57393.strueg () mandriva ! com
[Download RAW message or body]

On Friday 10 October 2008 21:00:45 Chusslove Illich wrote:
> >> [: 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.

Maybe you are right. So maybe we stick to simply adding a plural form and 
leave it at that...

> 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).

that is the plan.

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