ISSUE-23: How should we handle multiple labels/languages?


How should we handle multiple labels/languages?

Raised by:
Raj Singh
Opened on:
Date: Wed May 04 18:25:37 2011

Putting every possible language into a single POI could get very cumbersome. How about putting each different linguistic representation of a single POI in it's own <poi>, and linking them with an "identity" relationship?

Date: Wed May 04 19:09:10 2011
POI names come with the following trappings:
+ root name
+ small set of typical synonym names (DBA names)
+ multiple language presentations of that name
+ voice TTS transcriptions of the names for spoken word / hands free ops

This name proliferation is not really that rare. My guess is upwards of 30% of the standard POI sets carry multiple names. The more common and popular POIs have the most alt names. O'Hare / ORD / Ohare / O'Hare International Airport...

Date: Wed May 04 19:23:12 2011
I'm not thinking of alternate names, but the same name in different languages. For example, geonames has names for each place in a hundred different languages. We certainly don't want all those transmitted on every request for the POI , and absent a service call specifying the language to use, we don't have another way to be concise. Maybe something in the HTTP request header to do this?

Date: Wed May 04 19:56:15 2011
I do agree that encoding all languages in all POIs would make
downloads way too big....but then is this a realistic situation? Most
content creators aren't going to be specifying much more then their
local language. We don't see many bilingual webpages. (on the same

On the other hand, having separate POIs for each many be the simplest
solution, as many parts of the POI could be effected by the language,
not just the name. Even the data the POI links too might vary. (ie,
linking to different wikipedia pages).
Related Actions Items:
No related actions
Related emails:
  1. ISSUE-23 (multi-languages): How should we handle multiple labels/languages? (from on 2011-05-11)

Related notes:

No additional notes.

Display change log ATOM feed

Alex Hill <>, Chair, Matt Womer <>, Staff Contact
Tracker: documentation, (configuration for this group), originally developed by Dean Jackson, is developed and maintained by the Systems Team <>.
$Id: 23.html,v 1.1 2012/09/28 07:11:03 vivien Exp $