-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Karsten Otto wrote:
> The point here is that the action *must not* be a simple string. While
> an English speaking human may understand the string "open", someone who
> only speaks Chinese will not understand it. Same with your average
> agent, who does not speak *any* language at all :-)
>
You actually bring up a very interesting problem that I would *love* to
find a general solution for, before there's too much existing users of
VOS -- supporting multiple translations in human-oriented metadata.
This would probably be part of the MetaData vobject properties, but
couldf also be used anywhere there is text for humans to read.
I have three ideas on it:
1. Have seperate properties, with the language indicated in the property
name. E.g. misc:title.en-us, misc:title.de, misc:title.cn. If your
language isn't present, you would use the first one in the list. You
could always also omit the language, and just say misc:title; some
metadata strings would not really benefit much from translation in some
cases.
2. Have seperate properties with the same name, but indicate the
language in the property datatype. The definition of a property
datatype leaves room for this in that MIME types can have "parameters".
E.g. misc:title with data type "text/plain(lang=en/US)", misc:title with
data type "text/html(lang=de).
The disadvantage of (2) is you have to iterate over the properties
before you find your language. Peter is proposing including the
datatype in with the property vobject type; if you could do a site
search query on vobject types, you could search for your language. (But
that forces you to do a search query which is not required for a site to
support; you'd have to fall back on iterating all properties if search
is not supported.)
3. Another idea is to allow a metadata property to have children with
translations. I kind of like this. It lets you know what the original
or native property value is (the parent property's value), and you can
craft search queries not to descend it if you don't care about
translations. You would probably then just name all the child
translation properties after their language ("en", "de", etc.), and you
would probably add a type to the parent property to indicate that it has
child translations. You could even represent a whole tree of
translations, if, for example, the original value is in Russian, and you
then make a French translation, then someone uses that to make a
derivative English translation.
The disadvantage of (3) is that it adds complexity to the data
structure, especially if you represent the whole family tree of
translations. Not sure if there are any actual problems with this yet
though.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFETsAkFK83gN8ItOQRAuVuAJ43BcjxBjK86QuGQ3/atHTl41wlbQCeJow1
on4bcrVRkCHkwscz9B1+KlQ=
=Z1Gt
-----END PGP SIGNATURE-----
_______________________________________________
vos-d mailing list
vos-d@interreality.org
http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d
