Re: [OSM-talk] [Maps-l] using default country name

2009-08-24 Thread andrzej zaborowski
2009/8/23 Peter Körner osm-li...@mazdermind.de:
 (1) Default tags can be changed. We should remember that default tags
 can be edited by somebody later and they will no longer be good for
 other languages.

This fact speaks for both sides of the argument.  If some feature's
name changes (think, a street) you don't want to have to change 180
names in the name:*= tags.  In the great majority of cases foreign
names are based strictly on the native name.

 This will mark all all uses of the default name as not ok (in any language)

 (2) There is some inconsistency in default tags. Sometimes it's the
 English name, sometimes it's written in the Latin alphabet, local
 alphabet (e.g. Arabic) or both. I think Iran is spelt in Arabic, Comoros
 are spelt in both. Some people say Burma, some say Myanmar for various
 reasons.
 Yes, that's true. The default name should be how the name is spelled in
 this country (just as it is with city- and street-names). If there are
 two major languages in this country, both should be supplied.

Additionally Burma is a pretty bad example because it's tagged
incorrectly, the name= value should be using the native name and
native alphabet, i.e. Burmese script, while right now it uses the
english name.  It's going to be fixed at one point.

Cheers

___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk


Re: [OSM-talk] [Maps-l] using default country name

2009-08-23 Thread Marcin Cieslak
Peter Körner wrote:
 Maarten Deen schrieb:
 They tell you that the translation in the given language is identical to 
 the value of the name=* tag. If you see the name-Tag as a fallback for a 
 missing name:xx-tag (what you should), those pseudo-translations are 
 needless. I'm currently in a discussion with Marc Schütz (search through 
 the mails of the last days) if deleting them is a good or a bad thing.

I have read the above mentioned discussion[1] (unfortunately it  is
spread among two mailing lists) and I have two additional points to make:

(1) Default tags can be changed. We should remember that default tags
can be edited by somebody later and they will no longer be good for
other languages.

(2) There is some inconsistency in default tags. Sometimes it's the
English name, sometimes it's written in the Latin alphabet, local
alphabet (e.g. Arabic) or both. I think Iran is spelt in Arabic, Comoros
are spelt in both. Some people say Burma, some say Myanmar for various
reasons. I think having explicit name:xx tags even if *at the given
moment of time* it's the same as the default.

That's said, I have added name:pl to Polska even thought it is
the default name, too. Therefore having name:de == Deutschland is
perfectly fine. In this case it actually indicates that the local
official language is Hochdeutsch (de or de_DE).

Therefore I would propose to remove orange tags from the utility -
such name will be either italic or orange and never normal.
Both carry notion of something being wrong with the name.

I actually wonder if the default tag is the right thing to have
altogether. Probably better might be to use some fallback order (say,
en,de,ru to be very European-centric) and displaying the name in
italic in OSM (meaning fallback language applied).


Some more intelligent fallback mechanism could be applied in the future
(using user's browser preferences for example):

- Browser says Accept-Language: zh;q=1.0, ja;q=0.2, en;q=0.1 - this
means I understand Chinese (say Mandarin) and a bit of Japanese and
some tiny English. For more details on that see RFC2616[2].

- The webserver sees that there is no name:zh but there are name:en
and name:ja. This user indicates it prefers Japanese to English.
Actually in this case Japanese is much better option for the users since
there are chances that the kanji spelling will be the same as Chinese,
like, for example, 中国 (same in the Japan language and simplified
notation of Chinese).

But this would require on-demand application of the negotiated labels on
the map and this technically might not be easy to be done in a feasible
name (it would be difficult to create pre-generated tiles for different
sets of user preferences).

[1]http://thread.gmane.org/gmane.comp.gis.openstreetmap/39745/focus=39900
[2]http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html

-- 
   Marcin Cieslak // sa...@saper.info 

___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk


Re: [OSM-talk] [Maps-l] using default country name

2009-08-23 Thread Peter Körner
 I have read the above mentioned discussion[1] (unfortunately it  is
 spread among two mailing lists) 
Sorry for that.

 (1) Default tags can be changed. We should remember that default tags
 can be edited by somebody later and they will no longer be good for
 other languages.
This will mark all all uses of the default name as not ok (in any language)

 (2) There is some inconsistency in default tags. Sometimes it's the
 English name, sometimes it's written in the Latin alphabet, local
 alphabet (e.g. Arabic) or both. I think Iran is spelt in Arabic, Comoros
 are spelt in both. Some people say Burma, some say Myanmar for various
 reasons.
Yes, that's true. The default name should be how the name is spelled in 
this country (just as it is with city- and street-names). If there are 
two major languages in this country, both should be supplied.

  I think having explicit name:xx tags even if *at the given
 moment of time* it's the same as the default.
 
 That's said, I have added name:pl to Polska even thought it is
 the default name, too. Therefore having name:de == Deutschland is
 perfectly fine. In this case it actually indicates that the local
 official language is Hochdeutsch (de or de_DE).
There is afaik no difference of in the spilling of Deutschland within 
all de_*-languages, only in pronunciation, but if there would be on, it 
would be adequate to add them as de_DE, de_XX, ..

 Therefore I would propose to remove orange tags from the utility -
 such name will be either italic or orange and never normal.
 Both carry notion of something being wrong with the name.
This is a long-going discussion. In my eyes, duplication of data is 
*always* a bad thing, just as having different rules for similar things 
(see discussion on the list for that point).

having the value of the name-Tag duplicated in a name:xx-tag is, in my 
eyes not a bad thing, bus it is also unnecessary. So removing them is 
ok, even if it is not specially recommended.

If the case changed (e.g. the default name get's changed) it's up to an 
external tool / the user, to clean this up (this is easy with the 
mentioned tool).

 I actually wonder if the default tag is the right thing to have
 altogether. Probably better might be to use some fallback order (say,
 en,de,ru to be very European-centric) and displaying the name in
 italic in OSM (meaning fallback language applied).
I don't think this should/could be applied to a world-wide system.



 Some more intelligent fallback mechanism could be applied in the future
 (using user's browser preferences for example):
You're talking about the maps now, right? Not about the tool, are you?

 - Browser says Accept-Language: zh;q=1.0, ja;q=0.2, en;q=0.1 - this
 means I understand Chinese (say Mandarin) and a bit of Japanese and
 some tiny English. For more details on that see RFC2616[2].
 
 - The webserver sees that there is no name:zh but there are name:en
 and name:ja. This user indicates it prefers Japanese to English.
 Actually in this case Japanese is much better option for the users since
 there are chances that the kanji spelling will be the same as Chinese,
 like, for example, 中国 (same in the Japan language and simplified
 notation of Chinese).
 
 But this would require on-demand application of the negotiated labels on
 the map and this technically might not be easy to be done in a feasible
 name (it would be difficult to create pre-generated tiles for different
 sets of user preferences).
We could have a map, deciding which language to display by the 
Accept-Language-header. But this decision would then be for the whole 
map as one.

Peter

___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk