Re: [Tracker] Internationalization in SPARQL queries

On 22/02/10 11:03, Florent ThÃvenet wrote:
Le lundi 22 fÃvrier 2010 Ã 08:21 +0000, Martyn Russell a Ãcrit :
Hi Martyn

Hej ;)

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?

I think Michele's solution is very good, what's more it's "sparql
( )
About the increase of the data: every property doesn't need to be
translated (I don't think we will store the plainTextContent of a 700
pages pdf file :-) ) and with nowadays hard drive, storing two strings
instead of one is not terrible, even on embedded devices.

Of course, hence why I said I agreed with the idea that we have some ontology to know which properties are translatable ;)


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]