[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-09 12:42:05
Message-ID: 200810091442.05416.strueg () mandriva ! com
[Download RAW message or body]

Ok, I see there is quite a lot of confusion here. I should have been way more 
precise. Sorry about that.

There are basically two sources for the strings: 
1. The names and labels of types and properties as I mentioned in my mail come 
from the ontology itself. They are defined in a text file. This is different 
from "normal" translations where these strings are hardcoded in the 
application.
2. The names of resources aka instances are either created by the user or come 
from places such as the addressbook (name) or the web (webpage title)

So if I say for example that I would like to somehow translate "%1 is 
mentioned in %2", I mean that the ontology file contains "%1 is mentioned 
in %2" and the application reads this string (already translated without i18n 
since the ontology contains the translated strings) from Nepomuk. It then 
fills %1 and %2 in with names of instances which were created by the user or 
some application and do not really need translation.

So the process is a bit different. And the big issue is that new ontologies 
could be installed at any time. The system should then be able to deal with 
these new ontologies (which bring their own translations).

Thus, the question is: how do these strings to translate need to look like to 
cover most cases?

I hope this clears it up a bit. If not, please bug me some more. :)

Cheers,
Sebastian


On Thursday 09 October 2008 13:48:40 Chusslove Illich wrote:
> > [: Sebastian Trüg :]
> > With Nepomuk come a bunch of ontologies, sets of types and properties
> > that define and relate resources of any kind. This introduces a big
> > translation issue. [...] The system would work a bit different than the
> > "normal" translations as applications would not use stuff like "%1 is
> > mentioned in %2" but get exactly that from Nepomuk, i.e. the property
> > object.
>
> (I know next to nothing about Nepomuk, either concept or workings, so sorry
> about any strange questions.)
>
> Before going into grammar details -- indeed, perhaps to prevent going into
> such details -- I'd ask what is supposed to build these strings, in their
> final form? E.g. the user sees, somewhere, "Nepomuk is mentioned in
> Articles": which code did put the words "Nepomuk" and "Articles" in "%1 are
> mentioned in %2"? Is it KDE code? Does it go through a KDE i18n call? If
> not, can it be made to go through an i18n call? Similarly for the "Nepomuk"
> and "Articles" themselves, can they be pulled through an i18n call (either
> as i18nc("...", "Nepomuk") or I18N_NOOP2("...", "Nepomuk"), or even
> extracted from XML or another format, the way .ui, .rc, etc. files are)?
>
> For example, the answer to all these questions would be "no" if we would be
> speaking about .desktop files, as they are both "static" (no placeholder
> substitutions), and need to be read by non-KDE code too.
>
> > [...] After all, we never really know if the friend we are talking about
> > is male or female.
>
> If KDE code is building the final strings, could we know this, in
> principle? Assuming, of course, that the user/something did provide gender
> info, and "ontologies" sound to me like something that may be able to carry
> such info. More precisely, at the very point when i18nc("...", "%1 is a
> friend") hits, would there be a call available to fetch the gender (or
> appropriate "undefined" value if not available) of whatever %1 is?
>
> > Which do we need? Which are useless? Which are missing?
>
> The problem is that there is no end to what is needed to cover "all"
> languages, and if collected, then much of it would be useless to any given
> language.
>
> On the other hand, if the answers to all the above questions
> could-questions would be "yes", then I would say -- we need nothing, just
> think about and hardcode for reasonable English, with ample contexts (and
> as usual, with plural i18n calls where these are due, and no split
> sentences).

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