Re: [Tracker] Internationalization in SPARQL queries

[Martyn Russell <martyn lanedo com>]

On 20/02/10 21:58, feuloren free fr wrote:
> Hello,

Hi,

> Would it be possible to add an internationalization function in
> SPARQL queries ? Actually some properties like nco:locality could
> have a different value depending on the language used. e.g. a city
> like London City's official name is 'London' so we should put that as
> its value. But a french user won't want to see the city "London" but
> "Londres" (which is the same city but with its name translated), so
> each application getting data from Tracker should translate this
> field. I think this could be solved directly in Tracker, for example
> : "SELECT ?city tracker:LocalizedName(?city) {?a a nco:PostalAddress;
> nco:locality ?city.}", with tracker:LocalizedName a function that
> look up for "London" in some db and returns its french (in my case)
> translation. Obviously if user have a tag "London" it will translate
> the name while user probably don't want that; so (I don't know if
> it's possible) we could tell tracker:LocalizedName() from where
> "London" comes ->  "tracker:LocalizedName(?a nco:locality)". I know
> there are many other problem like what's happen when the user gives a
> a already translated name, or maybe a not translated one (we can't
> make the difference !)... but implementing that in every app would be
> very long and distract the developer from its main objective.
>
> Oh! a sudden idea ! We could mark properties that need localization
> in the ontologies then Tracker would easily knows that he should have
> to use tracker:LocalizedName() on the value and automatically check
> if user input is already translated.
>
> Well, that are only ideas, but one day problems with
> internationalization/localization of data will come and now is not to
> early to solve them.

This is quite an interesting idea. Using a function like 
tracker:LocalizedName(?city) wouldn't work unless we stored the data in 
multiple translations. This would increase the data quite significantly 
but I suppose we could use something like tracker:should_translate (or 
some property to know which properties to handle).

The other problem I see with this is, we can't simply call the gettext 
functions to do the translations at run time. Translations are (as you 
likely know) supplied by the translation teams and would have to be 
there before we release Tracker. So I am not sure how run-time words 
could be translated at this point?

--
Regards,
Martyn