As Michel pointed out, we have the same issue in Belgium, especially in Brussels which is officially bi-lingual, i.e. all street names have both a french and dutch name.
To bypass the problem of having to retype both the name:nl anf name:fr in name, I've implemented in Merkaartor a feature which allows tag templates to refer to other tags. I have a template for Brussels where I have "name = $[name:fr] - $[name:nl]" I think this could be a feature of the API to recognize this kind of construct, and construct the "name" tag on request. This would have the advantage of not bloating the database with unneeded tags. - Chris - On Sun, Mar 8, 2009 at 6:48 AM, Michel Barakat <bmic...@gmail.com> wrote: > We're facing a similar issue for mapping in neighboring Lebanon. In > addition to English, we use Arabic and French so we end up having four > name tags: 'name', 'name:en', 'name:fr', 'name:ar' > The name tag is a duplicate of one of the three languages depending on > the road or POI in question, we have some POIs with English names, > French or Arabic, not accounting for some two of three other languages > used in certain areas. Similarly to the example of Belgium, canceling > the 'name' tag all together, and defaulting to the country language is > not suitable. Language should be set per element. > > > But I prefer not to enter the same name twice, but to "point" the name > tag to the name:lang. > I support the idea of not having to repeat twice the same name. It is > an extra cost that might incur additional unnecessary risk of error > when creating or modifying the tags. > > > A possibility would be to never use name=, but only name:XX=xxxx and > > have a tag name:local=XX in order to indicate which is the local one. > > For rendering, a default rule could be that if there is only one > > name:XX=xxx without name:local=... then it will use the name:XX whatever > > XX is. > Good idea but we should make sure that name:local=XX is correct, that > is 'name:xx' exists among the possible name choices. Otherwise you > will end up with inconsistency. In terms of deployment, I don't think > the community will approve canceling the 'name' tag completely. > > So an alternative plausible solution could be to have a mechanism > which refers to one of the name:xx, such as Tal has suggested. We > could agree on some escape character that is used inside the tag > content ($ or \ or whatever is not commonly used). We would have > something like that: > name=$(name:fr) > name:fr="French Here" > name:en="English Here" > name:ar="Arabic Here" > > Another possibility, which looks more like a hack, is to simply > describe the language of the 'name' tag. So we could have a tag > 'name:local=xx' describing the language of the 'name' tag. For the > same example above, it would look like that: > name="French Here" > name:local="fr" > name:en="English Here" > name:ar="Arabic Here" > > In that case, we would not need the 'name:fr' tag to be explicitly > expressed. The rendered though would need to be modified to realize > its existence. > > Cheers > Michel > > On Sat, Mar 7, 2009 at 11:40 PM, Tal <tal....@gmail.com> wrote: > > > > > > On Sat, Mar 7, 2009 at 3:51 PM, Pierre-André Jacquod > > <pjacq...@alumni.ethz.ch> wrote: > >> > >> > I would, however, like to set a default language to the renderer using > >> > name=$(name:he) > >> > or something equivalent, for the default international map on the osm > >> > site. > >> I am not aware of such a feature for the current tools. I fear a problem > >> could be that $(name:he) is also a valid name somewhere else in the > >> world (with an other font than Latin...) > > > > > > I believe otherwise. I think that in the age of unicode "$(name:he)" will > > always be the same, regardless of the font you use, as long as you stick > to > > unicode. I believe that this site uses utf-8 which is a unicode encoding. > > Therefore, "$(name:he)" will always be a dollar sign and parenthesis > around > > some Latin letters. > > > >> > > > > > > > I like this idea! > > _______________________________________________ > > newbies mailing list > > newb...@openstreetmap.org > > http://lists.openstreetmap.org/listinfo/newbies > > > > > > _______________________________________________ > talk mailing list > talk@openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk >
_______________________________________________ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
