Interesting, no one else has commented so I'll do so. It is worth
coming back to in the future either for localising tagging or for
generating map key legends automatically in different languages.
If the backend ids and relationships they use between words in different
languages is immutable so that if could be used as a lookup table by a
script rather than just human viewing, as Paul says, this is a possible
way of making OSM tagging more multilingual.
For example "railway station" id 4507 is translated into 22
different languages, each with an "identical meaning" tickbox
I personally don't propose that we all start using railway=4507, but it
does provide a mechanism to localise OSM down the track.
railway=station can be related to railway=railway_station can be related
At 05:50 AM 11/12/2006, Paul Youlten wrote:
I was wondering if WiktionaryZ
might be a useful resource for OSM:
> Hi Mike,
> I dont suggest translating word to another language.
> Mostly word corespond to sentence meaning, not to word to word tranlating.
> Also, in diferent country "same" word may be use for very different things.
> Better way is to set generic code for each map element, and then do
> translation list.
Alternatively, since "Map_Features" is already quite well-defined and
used, any internationalization functions can merely translate from the
"English" key/value tags to something similar to a local language.
Especially since much of that would be presented in an editing
application with a user-interface like a drop-down list, it doesn't
actually matter _what_ gets displayed in the drop-down, so long as what
goes into the actual API and database is internationally consistent.
If you compare with what is used for TPEG broadcasts, that schema was
designed from the outset with internationalization and localization in
mind (which uses very large and detailed lookup tables for value to
natural language meanings)
Since we already have a API that isn't tied down to formally defined
key/value pairs, and lots of entries in the existing format, it's not
hugely feasible to change every editor / renderer / reformatter of the
database to use numeric key/value pairs and lookup tables.