Hello OSM folks
For the integration of osm into the wikipedia there will be localized maps in all languages that have their own wikipedia. The problem is, that a lot of countries are not translated yet.
To get an overview over the status and make translating those countries more easy, I created a tool that can be found at
http://cassini.toolserver.org/~mazder/multilingual-country-list/
I'd like to encourage everyone to spend some time making translated maps better. Comments welcome!
Peter
On Wed, Aug 12, 2009 at 11:28 PM, Peter Körnerosm-lists@mazdermind.de wrote:
Hello OSM folks
For the integration of osm into the wikipedia there will be localized maps in all languages that have their own wikipedia. The problem is, that a lot of countries are not translated yet.
To get an overview over the status and make translating those countries more easy, I created a tool that can be found at
http://cassini.toolserver.org/~mazder/multilingual-country-list/
I'd like to encourage everyone to spend some time making translated maps better. Comments welcome!
That's very useful, and it's nice to see the toolserver being put to good use.
One thing that would be very useful is if you would offer a .osm file for download which would include all the place=country nodes so that one could mass-translate them in e.g. JOSM. You can do this making an OSM file whose contents are a concatenation of the various http://api.openstreetmap.org/api/0.6/node/ID where ID is the node ID.
Ævar Arnfjörð Bjarmason schrieb:
On Wed, Aug 12, 2009 at 11:28 PM, Peter Körnerosm-lists@mazdermind.de wrote:
Hello OSM folks
For the integration of osm into the wikipedia there will be localized maps in all languages that have their own wikipedia. The problem is, that a lot of countries are not translated yet.
To get an overview over the status and make translating those countries more easy, I created a tool that can be found at
http://cassini.toolserver.org/~mazder/multilingual-country-list/
I'd like to encourage everyone to spend some time making translated maps better. Comments welcome!
That's very useful, and it's nice to see the toolserver being put to good use.
One thing that would be very useful is if you would offer a .osm file for download which would include all the place=country nodes so that one could mass-translate them in e.g. JOSM. You can do this making an OSM file whose contents are a concatenation of the various http://api.openstreetmap.org/api/0.6/node/ID where ID is the node ID.
I also thought about implementing inline-editing by just clicking the wrongly translated name and do the commit to the api right from the Toolserver. This way also the MySQL-DB behind the lists would be up2date instantly.
Don't you fear corrupt mass-imports as we got just some weeks ago? (see http://cassini.toolserver.org/~mazder/duplicate-countries/)
Peter
On Wed, Aug 12, 2009 at 11:53 PM, Peter Körnerosm-lists@mazdermind.de wrote:
Ævar Arnfjörð Bjarmason schrieb:
On Wed, Aug 12, 2009 at 11:28 PM, Peter Körnerosm-lists@mazdermind.de wrote:
Hello OSM folks
For the integration of osm into the wikipedia there will be localized maps in all languages that have their own wikipedia. The problem is, that a lot of countries are not translated yet.
To get an overview over the status and make translating those countries more easy, I created a tool that can be found at
http://cassini.toolserver.org/~mazder/multilingual-country-list/
I'd like to encourage everyone to spend some time making translated maps better. Comments welcome!
That's very useful, and it's nice to see the toolserver being put to good use.
One thing that would be very useful is if you would offer a .osm file for download which would include all the place=country nodes so that one could mass-translate them in e.g. JOSM. You can do this making an OSM file whose contents are a concatenation of the various http://api.openstreetmap.org/api/0.6/node/ID where ID is the node ID.
I also thought about implementing inline-editing by just clicking the wrongly translated name and do the commit to the api right from the Toolserver. This way also the MySQL-DB behind the lists would be up2date instantly.
I think tools such as this one would be most useful if they do directly commit to the API and offer an editing interface. As has been pointed out (in the "i18n-rich areas on the map" thread on osm-talk) the current editors for OSM data offer a very lousy interface if all you're interested in is contributing translations, since they aren't optimized for that at all.
So direct uploading would be nice, whether that happens with a single dedicated bot user or through proxying of OSM user accounts (e.g. via the still-to-be-merged oauth stuff) would certainly be nice.
Don't you fear corrupt mass-imports as we got just some weeks ago? (see http://cassini.toolserver.org/~mazder/duplicate-countries/)
IIRC The corrupted mass-import happened because someone ran the bulk_upload.py script on an OSM file without understanding how the bulk-upload tool worked. Granted if you offered an OSM file with all the place=country nodes you'd be morke likely to get that sort of (and other kinds) of sillyness as a result.
I'd much rather see a click-through launchpad-like interface to translate arbitrary objects :)
Ævar Arnfjörð Bjarmason schrieb:
On Wed, Aug 12, 2009 at 11:53 PM, Peter Körnerosm-lists@mazdermind.de wrote:
Ævar Arnfjörð Bjarmason schrieb:
On Wed, Aug 12, 2009 at 11:28 PM, Peter Körnerosm-lists@mazdermind.de wrote:
Hello OSM folks
For the integration of osm into the wikipedia there will be localized maps in all languages that have their own wikipedia. The problem is, that a lot of countries are not translated yet.
To get an overview over the status and make translating those countries more easy, I created a tool that can be found at
http://cassini.toolserver.org/~mazder/multilingual-country-list/
I'd like to encourage everyone to spend some time making translated maps better. Comments welcome!
That's very useful, and it's nice to see the toolserver being put to good use.
One thing that would be very useful is if you would offer a .osm file for download which would include all the place=country nodes so that one could mass-translate them in e.g. JOSM. You can do this making an OSM file whose contents are a concatenation of the various http://api.openstreetmap.org/api/0.6/node/ID where ID is the node ID.
I also thought about implementing inline-editing by just clicking the wrongly translated name and do the commit to the api right from the Toolserver. This way also the MySQL-DB behind the lists would be up2date instantly.
I think tools such as this one would be most useful if they do directly commit to the API and offer an editing interface. As has been pointed out (in the "i18n-rich areas on the map" thread on osm-talk) the current editors for OSM data offer a very lousy interface if all you're interested in is contributing translations, since they aren't optimized for that at all.
So direct uploading would be nice, whether that happens with a single dedicated bot user or through proxying of OSM user accounts (e.g. via the still-to-be-merged oauth stuff) would certainly be nice.
Don't you fear corrupt mass-imports as we got just some weeks ago? (see http://cassini.toolserver.org/~mazder/duplicate-countries/)
IIRC The corrupted mass-import happened because someone ran the bulk_upload.py script on an OSM file without understanding how the bulk-upload tool worked. Granted if you offered an OSM file with all the place=country nodes you'd be morke likely to get that sort of (and other kinds) of sillyness as a result.
I'd much rather see a click-through launchpad-like interface to translate arbitrary objects :)
Yes and that matches to me, too. I don't know nothing about bulk_upload.py but I think I know enough about the api to do a direct commit. I'll try to implement it this week.
I'ts so cool to see the progress-bars filling :)
Peter
Nice to see the tool of Peter Körner. So it seems possible to run scripts on cassini and connect to the database (postgres or mysql?). Could somebody please document who it works. My trys to start my php-scripts from cassini and to start psql were without success.
I also want to develop a little text based tool that gives back all street names in alphabetic order which are in a bbox or (more difficult) in a way/relation. Such a street list is part of each paper city map and the streetnames could be linked to things like Query-to-map.
----
Whats the schedule for our database-server? The last date for start that I know is beginning of august.
----
A question to Avar: Would it be possible for you to rendering easily also the name-variations? http://wiki.openstreetmap.org/wiki/Key:name#Key%20Variations
We had a talk in Dresden that the "old-name"-tag would be interesting, especcially in germany with its changefull in history. But to push this feature a map with it would be nice.
Greetings Kolossos
Tim Alder schrieb:
Nice to see the tool of Peter Körner. So it seems possible to run scripts on cassini and connect to the database (postgres or mysql?). Could somebody please document who it works. My trys to start my php-scripts from cassini and to start psql were without success.
I also want to develop a little text based tool that gives back all street names in alphabetic order which are in a bbox or (more difficult) in a way/relation. Such a street list is part of each paper city map and the streetnames could be linked to things like Query-to-map.
Whats the schedule for our database-server? The last date for start that I know is beginning of august.
A question to Avar: Would it be possible for you to rendering easily also the name-variations? http://wiki.openstreetmap.org/wiki/Key:name#Key%20Variations
We had a talk in Dresden that the "old-name"-tag would be interesting, especcially in germany with its changefull in history. But to push this feature a map with it would be nice.
Greetings Kolossos
It is possible to connect to the local postgres-db, although it is very outdated (it's from 2009-07-15) and not updated at the moment. It is also possible to connect to the sql-servers.
Tools may be written in php, perl or python, although i can't guarantee that everything will work in every language right now, but i don't see any problems that can't be resolve by a ticket in jira.
I think i could write a beginners-guide on how to use cassini (I'd propose https://wiki.toolserver.org/view/Cassini/Usage_notes) but at the moment it's not too useful as the main database is not updated.
I worked around this by once doing an import of all country-nodes from the (outdated) postgresql-database into my mysql-db and have them checked regularly against the api. This works for countries (no support for new nodes, only ~230 nodes to fetch) but if you'd like to do something similar on a city-level, this wouldn't work anymore.
So what is needed to get the database updated? I don't think we'll need a root-user to do this, just someone with write-perms on /sql and maybe a file under /etc/cron.d/. I never set up a postgres-db with hourly/minutely diff-support but I think I could give it a try, if this would be ok. On the other hand, if someone already has experience whith such a setup, he's welcome to do this.
Any suggestions? Peter
Hello, the outdating is not so the problem for me because I only want to make my first steps in postgres on this way (I hope I find time). For regular updating we should wait for our db-server.
But it would be nice if you can tell me how you contact the database, in which language your scripts are and where they are. So why doesn't http://cassini.toolserver.org/~kolossos/osm work (PHP) if it's fine on http://toolserver.org/~kolossos/osm ?
Greetings Kolossos
Peter Körner schrieb:
Tim Alder schrieb:
Nice to see the tool of Peter Körner. So it seems possible to run scripts on cassini and connect to the database (postgres or mysql?). Could somebody please document who it works. My trys to start my php-scripts from cassini and to start psql were without success.
I also want to develop a little text based tool that gives back all street names in alphabetic order which are in a bbox or (more difficult) in a way/relation. Such a street list is part of each paper city map and the streetnames could be linked to things like Query-to-map.
Whats the schedule for our database-server? The last date for start that I know is beginning of august.
A question to Avar: Would it be possible for you to rendering easily also the name-variations? http://wiki.openstreetmap.org/wiki/Key:name#Key%20Variations
We had a talk in Dresden that the "old-name"-tag would be interesting, especcially in germany with its changefull in history. But to push this feature a map with it would be nice.
Greetings Kolossos
It is possible to connect to the local postgres-db, although it is very outdated (it's from 2009-07-15) and not updated at the moment. It is also possible to connect to the sql-servers.
Tools may be written in php, perl or python, although i can't guarantee that everything will work in every language right now, but i don't see any problems that can't be resolve by a ticket in jira.
I think i could write a beginners-guide on how to use cassini (I'd propose https://wiki.toolserver.org/view/Cassini/Usage_notes) but at the moment it's not too useful as the main database is not updated.
I worked around this by once doing an import of all country-nodes from the (outdated) postgresql-database into my mysql-db and have them checked regularly against the api. This works for countries (no support for new nodes, only ~230 nodes to fetch) but if you'd like to do something similar on a city-level, this wouldn't work anymore.
So what is needed to get the database updated? I don't think we'll need a root-user to do this, just someone with write-perms on /sql and maybe a file under /etc/cron.d/. I never set up a postgres-db with hourly/minutely diff-support but I think I could give it a try, if this would be ok. On the other hand, if someone already has experience whith such a setup, he's welcome to do this.
Any suggestions? Peter
Maps-l mailing list Maps-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/maps-l
On 8/13/09, Tim Alder tim.alder@s2002.tu-chemnitz.de wrote:
Hello, the outdating is not so the problem for me because I only want to make my first steps in postgres on this way (I hope I find time). For regular updating we should wait for our db-server.
But it would be nice if you can tell me how you contact the database, in which language your scripts are and where they are. So why doesn't http://cassini.toolserver.org/~kolossos/osm work (PHP) if it's fine on http://toolserver.org/~kolossos/osm ?
Greetings Kolossos
I had time available today to look at how postgres is setup and found that further configuration work is needed, including for how user authentication is handled. This means that whatever way Peter is using will change.
We should set things so they work similar to how the toolserver handles MySQL authentication with .my.cnf files. The equivalent for postgres are .pgpass files that reside in the user home directories.
Also, not everyone has an account yet. If granted the right privileges (don't need root access), then I can work on this in the next few days.
-Aude
Maps-l mailing list Maps-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/maps-l
On Thu, Aug 13, 2009 at 8:15 PM, Audeaude.wiki@gmail.com wrote:
On 8/13/09, Tim Alder tim.alder@s2002.tu-chemnitz.de wrote:
Hello, the outdating is not so the problem for me because I only want to make my first steps in postgres on this way (I hope I find time). For regular updating we should wait for our db-server.
But it would be nice if you can tell me how you contact the database, in which language your scripts are and where they are. So why doesn't http://cassini.toolserver.org/~kolossos/osm work (PHP) if it's fine on http://toolserver.org/~kolossos/osm ?
Greetings Kolossos
I had time available today to look at how postgres is setup and found that further configuration work is needed, including for how user authentication is handled. This means that whatever way Peter is using will change.
We should set things so they work similar to how the toolserver handles MySQL authentication with .my.cnf files. The equivalent for postgres are .pgpass files that reside in the user home directories.
Also, not everyone has an account yet. If granted the right privileges (don't need root access), then I can work on this in the next few days.
-Aude
I have been discussing how to handle authentication on IRC. Instead of password authentication, we may use the ident authentication option. This means that no password is needed, with postgresql instead trusting the authentication (ssh/key) that got you logged into cassini. This should work if users will access the database only locally, and we don't need to enable TCP/IP connections.
As for why http://cassini.toolserver.org/~kolossos/osm isn't working, apache UserDir is set to have osm_public_html as the root web directory. You can create a symlink from your kolossos/public_html directory to the kolossos/osm_public_html directory.
I did that and now my beautiful :) home page works:
http://cassini.toolserver.org/~aude
-Aude
Maps-l mailing list Maps-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/maps-l
Maps-l mailing list Maps-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/maps-l
Aude schrieb:
On 8/13/09, Tim Alder tim.alder@s2002.tu-chemnitz.de wrote:
Hello, the outdating is not so the problem for me because I only want to make my first steps in postgres on this way (I hope I find time). For regular updating we should wait for our db-server.
But it would be nice if you can tell me how you contact the database, in which language your scripts are and where they are. So why doesn't http://cassini.toolserver.org/~kolossos/osm work (PHP) if it's fine on http://toolserver.org/~kolossos/osm ?
Greetings Kolossos
I had time available today to look at how postgres is setup and found that further configuration work is needed, including for how user authentication is handled. This means that whatever way Peter is using will change.
I don't see any problem with that. Atm i'm not even using the postgres-db as it's not interesting to me as long as it's not up2date.
We should set things so they work similar to how the toolserver handles MySQL authentication with .my.cnf files. The equivalent for postgres are .pgpass files that reside in the user home directories.
Also, not everyone has an account yet. If granted the right privileges (don't need root access), then I can work on this in the next few days.
Is there a difference between having an standard-toolserver-account and having one for cassini? I'm able do login to willow as well as directly to cassini and afaik the homedirs are shared anyway.
Peter
Hi
the outdated database makes the toolserver less useful to any tool out there (becouse it can't reflect changes easily). Do you have any plan when the main-db server could be up & running?
I think I can wait until it's done (and i know it's done when it's done :), but on the other hand i see the toolserver & it's ressources in place and i got a bunch of ideas to use it, but this will not be possible with an not updated db..
I wrote my scripts in php and it's accessing the database via the pg_* functions. This "import from postgis" is only run once to fetch the list of all countries. This list is then written so a mysql-db on sql, from where the scripts pull their information. The hourly update-process checks the nodes in the mysql-db against the api (as this is atm the only way to get up2date information).
I'm authenticating against the local postgresql-db with user gis and an empty password, the name of the db is gis. This information can be read from /sql/mapnik-stylesheets/osm-like/osm-de.xml by any toolserver-user, so i hope i'm not disclosing a secret..
You can get the source of my scripts here: http://cassini.toolserver.org/~mazder/multilingual-country-list/source.tar.b...
As already pointed out, the httpd on cassini is looking for /home/*/osm_public_html.
I'll see if I can write this down into a usage-guide at the end of this weekend.
Peter
Tim Alder schrieb:
Hello, the outdating is not so the problem for me because I only want to make my first steps in postgres on this way (I hope I find time). For regular updating we should wait for our db-server.
But it would be nice if you can tell me how you contact the database, in which language your scripts are and where they are. So why doesn't http://cassini.toolserver.org/~kolossos/osm work (PHP) if it's fine on http://toolserver.org/~kolossos/osm ?
Greetings Kolossos
Peter Körner schrieb:
Tim Alder schrieb:
Nice to see the tool of Peter Körner. So it seems possible to run scripts on cassini and connect to the database (postgres or mysql?). Could somebody please document who it works. My trys to start my php-scripts from cassini and to start psql were without success.
I also want to develop a little text based tool that gives back all street names in alphabetic order which are in a bbox or (more difficult) in a way/relation. Such a street list is part of each paper city map and the streetnames could be linked to things like Query-to-map.
Whats the schedule for our database-server? The last date for start that I know is beginning of august.
A question to Avar: Would it be possible for you to rendering easily also the name-variations? http://wiki.openstreetmap.org/wiki/Key:name#Key%20Variations
We had a talk in Dresden that the "old-name"-tag would be interesting, especcially in germany with its changefull in history. But to push this feature a map with it would be nice.
Greetings Kolossos
It is possible to connect to the local postgres-db, although it is very outdated (it's from 2009-07-15) and not updated at the moment. It is also possible to connect to the sql-servers.
Tools may be written in php, perl or python, although i can't guarantee that everything will work in every language right now, but i don't see any problems that can't be resolve by a ticket in jira.
I think i could write a beginners-guide on how to use cassini (I'd propose https://wiki.toolserver.org/view/Cassini/Usage_notes) but at the moment it's not too useful as the main database is not updated.
I worked around this by once doing an import of all country-nodes from the (outdated) postgresql-database into my mysql-db and have them checked regularly against the api. This works for countries (no support for new nodes, only ~230 nodes to fetch) but if you'd like to do something similar on a city-level, this wouldn't work anymore.
So what is needed to get the database updated? I don't think we'll need a root-user to do this, just someone with write-perms on /sql and maybe a file under /etc/cron.d/. I never set up a postgres-db with hourly/minutely diff-support but I think I could give it a try, if this would be ok. On the other hand, if someone already has experience whith such a setup, he's welcome to do this.
Any suggestions? Peter
Maps-l mailing list Maps-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/maps-l
Maps-l mailing list Maps-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/maps-l
On Thu, Aug 13, 2009 at 2:35 PM, Peter Körner osm-lists@mazdermind.dewrote:
It is possible to connect to the local postgres-db, although it is very outdated (it's from 2009-07-15) and not updated at the moment. It is also possible to connect to the sql-servers.
Tools may be written in php, perl or python, although i can't guarantee that everything will work in every language right now, but i don't see any problems that can't be resolve by a ticket in jira.
I think i could write a beginners-guide on how to use cassini (I'd propose https://wiki.toolserver.org/view/Cassini/Usage_notes) but at the moment it's not too useful as the main database is not updated.
I worked around this by once doing an import of all country-nodes from the (outdated) postgresql-database into my mysql-db and have them checked regularly against the api. This works for countries (no support for new nodes, only ~230 nodes to fetch) but if you'd like to do something similar on a city-level, this wouldn't work anymore.
So what is needed to get the database updated? I don't think we'll need a root-user to do this, just someone with write-perms on /sql and maybe a file under /etc/cron.d/. I never set up a postgres-db with hourly/minutely diff-support but I think I could give it a try, if this would be ok. On the other hand, if someone already has experience whith such a setup, he's welcome to do this.
Any suggestions? Peter
The osm planet needs to be re-imported into the mapnik PostgresSQL database, with the intarray (_int.sql) module enabled on the gis database before doing the import.
This requires either root access or sudo privileges to run commands as user postgres. I have submitted a jira ticket, requesting sudo privileges so that I can work on this.
Once planet osm is re-imported, the database will be setup to handle regular imports of OSM .osc diff files using osm2pgsql.
-Aude
Maps-l mailing list Maps-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/maps-l
2009/8/13 Aude aude.wiki@gmail.com:
The osm planet needs to be re-imported into the mapnik PostgresSQL database, with the intarray (_int.sql) module enabled on the gis database before doing the import.
Right, this is already necessary because the hourly osc files don't reach back so far into the past, even if it wasn't for the intarray module.
I have mentioned this before but do it again to prevent hours of importing time being wasted: please bear in mind that in order to support alternative map styles, osm2pgsql's default.style file will need to be extended. I.e. this is the one needed for the hike & bike map: http://mapnik-utils.googlecode.com/svn/sandbox/cascadenik/hike_n_bike/defaul...
alt_name/old_name etc. would need to be in there as well.
Thanks for working on this.
Cheers Colin
Colin Marquardt schrieb:
2009/8/13 Aude aude.wiki@gmail.com:
The osm planet needs to be re-imported into the mapnik PostgresSQL database, with the intarray (_int.sql) module enabled on the gis database before doing the import.
Right, this is already necessary because the hourly osc files don't reach back so far into the past, even if it wasn't for the intarray module.
I have mentioned this before but do it again to prevent hours of importing time being wasted: please bear in mind that in order to support alternative map styles, osm2pgsql's default.style file will need to be extended. I.e. this is the one needed for the hike & bike map: http://mapnik-utils.googlecode.com/svn/sandbox/cascadenik/hike_n_bike/defaul...
alt_name/old_name etc. would need to be in there as well.
Thanks for working on this.
Cheers Colin
Hi Colin
i combined the wikimedia.style with your hike_n_bike.style and some of the alternatice name-tags and attached it. I think that the more of the existing data of osm is in the db, the more useful will it be for experiments, trying new things etc.
Peter
# This is the style file that matches the old version of osm2pgsql, which # did not make distinctions between tags for nodes and for ways. There are a # number of optimisations that can be applied here. Firstly, certain tags # only apply to only nodes or only ways. By fixing this we reduce the amount # of useless data loaded into the DB, which is a good thing. Possible # optimisations for the future:
# 1. Generate this file directly from the mapnik XML config, so it's always # optimal
# 2. Extend it so it can understand that highway=tertiary is for ways and # highway=bus_stop is for nodes
# Flags field isn't used much yet, expect if it contains the text "polygon" # it indicates the shape is candidate for the polygon table. In the future I # would like to be able to add directives like "nocache" which tells # osm2pgsql that it is unlikely this node will be used by a way and so it # doesn't need to be stored (eg coastline nodes). While in essence an # optimisation hack, for --slim mode it doesn't matter if you're wrong, but # in non-slim you might break something!
# Also possibly an ignore flag, for things like "note" and "source" which # can simply be deleted. (In slim mode this is, does not apply to non-slim # obviously)
# OsmType Tag DataType Flags node,way note text delete # These tags can be long but are useless for rendering node,way source text delete # This indicates that we shouldn't store them
node,way access text linear node,way addr:flats text polygon node,way addr:housenumber text linear node,way addr:interpolation text linear node,way admin_level text linear node,way aerialway text linear node,way aeroway text polygon node,way amenity text nocache,polygon node,way area text # hard coded support for area=1/yes => polygon is in osm2pgsql node,way barrier text linear node,way bicycle text nocache node,way bridge text linear node,way boundary text linear node,way building text polygon node capital text linear node,way construction text linear node,way cutting text linear node,way disused text linear node ele text linear node,way embankment text linear node,way foot text linear node,way highway text linear node,way historic text polygon node,way horse text linear node,way junction text linear node,way landuse text polygon node,way layer text linear node,way learning text linear node,way leisure text polygon node,way lock text linear node,way man_made text polygon node,way military text polygon node,way motorcar text linear
################################################################################## # This is a list of 278 languages for which we want to gather the name:lang tags # ##################################################################################
# name= is the generic fallback node,way name text linear
# aa (Qafár af) node,way name:aa text linear # ab (Аҧсуа) node,way name:ab text linear # af (Afrikaans) node,way name:af text linear # ak (Akan) node,way name:ak text linear # als (Alemannisch) node,way name:als text linear # am (አማርኛ) node,way name:am text linear # an (Aragonés) node,way name:an text linear # ang (Anglo-Saxon) node,way name:ang text linear # ar (العربية) node,way name:ar text linear # arc (ܐܪܡܝܐ) node,way name:arc text linear # arz (مصرى) node,way name:arz text linear # as (অসমীয়া) node,way name:as text linear # ast (Asturianu) node,way name:ast text linear # av (Авар) node,way name:av text linear # ay (Aymar aru) node,way name:ay text linear # az (Azərbaycan) node,way name:az text linear # ba (Башҡорт) node,way name:ba text linear # bar (Boarisch) node,way name:bar text linear # bat-smg (Žemaitėška) node,way name:bat-smg text linear # bcl (Bikol Central) node,way name:bcl text linear # be (Беларуская) node,way name:be text linear # be-x-old (Беларуская (тарашкевіца)) node,way name:be-x-old text linear # bg (Български) node,way name:bg text linear # bh (भोजपुरी) node,way name:bh text linear # bi (Bislama) node,way name:bi text linear # bm (Bamanankan) node,way name:bm text linear # bn (বাংলা) node,way name:bn text linear # bo (བོད་ཡིག) node,way name:bo text linear # bpy (ইমার ঠার/বিষ্ণুপ্রিয়া মণিপুরী) node,way name:bpy text linear # br (Brezhoneg) node,way name:br text linear # bs (Bosanski) node,way name:bs text linear # bug (ᨅᨔ ᨕᨘᨁᨗ) node,way name:bug text linear # bxr (Буряад) node,way name:bxr text linear # ca (Català) node,way name:ca text linear # cbk-zam (Chavacano de Zamboanga) node,way name:cbk-zam text linear # cdo (Mìng-dĕ̤ng-ngṳ̄) node,way name:cdo text linear # ce (Нохчийн) node,way name:ce text linear # ceb (Cebuano) node,way name:ceb text linear # ch (Chamoru) node,way name:ch text linear # cho (Choctaw) node,way name:cho text linear # chr (ᏣᎳᎩ) node,way name:chr text linear # chy (Tsetsêhestâhese) node,way name:chy text linear # closed-zh-tw () node,way name:closed-zh-tw text linear # co (Corsu) node,way name:co text linear # cr (Nēhiyawēwin / ᓀᐦᐃᔭᐍᐏᐣ) node,way name:cr text linear # crh (Qırımtatarca) node,way name:crh text linear # cs (Česky) node,way name:cs text linear # csb (Kaszëbsczi) node,way name:csb text linear # cu (Словѣ́ньскъ / ⰔⰎⰑⰂⰡⰐⰠⰔⰍⰟ) node,way name:cu text linear # cv (Чӑвашла) node,way name:cv text linear # cy (Cymraeg) node,way name:cy text linear # cz () node,way name:cz text linear # da (Dansk) node,way name:da text linear # de (Deutsch) node,way name:de text linear # diq (Zazaki) node,way name:diq text linear # dk (Dansk (deprecated:da)) node,way name:dk text linear # dsb (Dolnoserbski) node,way name:dsb text linear # dv (ދިވެހިބަސް) node,way name:dv text linear # dz (ཇོང་ཁ) node,way name:dz text linear # ee (Eʋegbe) node,way name:ee text linear # el (Ελληνικά) node,way name:el text linear # eml (Emiliàn e rumagnòl) node,way name:eml text linear # en (English) node,way name:en text linear # eo (Esperanto) node,way name:eo text linear # epo () node,way name:epo text linear # es (Español) node,way name:es text linear # et (Eesti) node,way name:et text linear # eu (Euskara) node,way name:eu text linear # ext (Estremeñu) node,way name:ext text linear # fa (فارسی) node,way name:fa text linear # ff (Fulfulde) node,way name:ff text linear # fi (Suomi) node,way name:fi text linear # fiu-vro (Võro) node,way name:fiu-vro text linear # fj (Na Vosa Vakaviti) node,way name:fj text linear # fo (Føroyskt) node,way name:fo text linear # fr (Français) node,way name:fr text linear # frp (Arpetan) node,way name:frp text linear # fur (Furlan) node,way name:fur text linear # fy (Frysk) node,way name:fy text linear # ga (Gaeilge) node,way name:ga text linear # gan (贛語) node,way name:gan text linear # gd (Gàidhlig) node,way name:gd text linear # gl (Galego) node,way name:gl text linear # glk (گیلکی) node,way name:glk text linear # gn (Avañe'ẽ) node,way name:gn text linear # got (𐌲𐌿𐍄𐌹𐍃𐌺) node,way name:got text linear # gu (ગુજરાતી) node,way name:gu text linear # gv (Gaelg) node,way name:gv text linear # ha (هَوُسَ) node,way name:ha text linear # hak (Hak-kâ-fa) node,way name:hak text linear # haw (Hawai`i) node,way name:haw text linear # he (עברית) node,way name:he text linear # hi (हिन्दी) node,way name:hi text linear # hif (Fiji Hindi) node,way name:hif text linear # ho (Hiri Motu) node,way name:ho text linear # hr (Hrvatski) node,way name:hr text linear # hsb (Hornjoserbsce) node,way name:hsb text linear # ht (Kreyòl ayisyen) node,way name:ht text linear # hu (Magyar) node,way name:hu text linear # hy (Հայերեն) node,way name:hy text linear # hz (Otsiherero) node,way name:hz text linear # ia (Interlingua) node,way name:ia text linear # id (Bahasa Indonesia) node,way name:id text linear # ie (Interlingue) node,way name:ie text linear # ig (Igbo) node,way name:ig text linear # ii (ꆇꉙ) node,way name:ii text linear # ik (Iñupiak) node,way name:ik text linear # ilo (Ilokano) node,way name:ilo text linear # io (Ido) node,way name:io text linear # is (Íslenska) node,way name:is text linear # it (Italiano) node,way name:it text linear # iu (ᐃᓄᒃᑎᑐᑦ/inuktitut) node,way name:iu text linear # ja (日本語) node,way name:ja text linear # jbo (Lojban) node,way name:jbo text linear # jp () node,way name:jp text linear # jv (Basa Jawa) node,way name:jv text linear # ka (ქართული) node,way name:ka text linear # kaa (Qaraqalpaqsha) node,way name:kaa text linear # kab (Taqbaylit) node,way name:kab text linear # kg (Kongo) node,way name:kg text linear # ki (Gĩkũyũ) node,way name:ki text linear # kj (Kwanyama) node,way name:kj text linear # kk (Қазақша) node,way name:kk text linear # kl (Kalaallisut) node,way name:kl text linear # km (ភាសាខ្មែរ) node,way name:km text linear # kn (ಕನ್ನಡ) node,way name:kn text linear # ko (한국어) node,way name:ko text linear # kr (Kanuri) node,way name:kr text linear # ks (कश्मीरी - (كشميري)) node,way name:ks text linear # ksh (Ripoarisch) node,way name:ksh text linear # ku (Kurdî / كوردی) node,way name:ku text linear # kv (Коми) node,way name:kv text linear # kw (Kernewek) node,way name:kw text linear # ky (Кыргызча) node,way name:ky text linear # la (Latina) node,way name:la text linear # lad (Ladino) node,way name:lad text linear # lb (Lëtzebuergesch) node,way name:lb text linear # lbe (Лакку) node,way name:lbe text linear # lg (Luganda) node,way name:lg text linear # li (Limburgs) node,way name:li text linear # lij (Líguru) node,way name:lij text linear # lmo (Lumbaart) node,way name:lmo text linear # ln (Lingála) node,way name:ln text linear # lo (ລາວ) node,way name:lo text linear # lt (Lietuvių) node,way name:lt text linear # lv (Latviešu) node,way name:lv text linear # map-bms (Basa Banyumasan) node,way name:map-bms text linear # mdf (Мокшень) node,way name:mdf text linear # mg (Malagasy) node,way name:mg text linear # mh (Ebon) node,way name:mh text linear # mhr (Олык Марий) node,way name:mhr text linear # mi (Māori) node,way name:mi text linear # minnan () node,way name:minnan text linear # mk (Македонски) node,way name:mk text linear # ml (മലയാളം) node,way name:ml text linear # mn (Монгол) node,way name:mn text linear # mo (Молдовеняскэ) node,way name:mo text linear # mr (मराठी) node,way name:mr text linear # ms (Bahasa Melayu) node,way name:ms text linear # mt (Malti) node,way name:mt text linear # mus (Mvskoke) node,way name:mus text linear # my (မြန်မာဘာသာ) node,way name:my text linear # myv (Эрзянь) node,way name:myv text linear # mzn (مَزِروني) node,way name:mzn text linear # na (Dorerin Naoero) node,way name:na text linear # nah (Nāhuatl) node,way name:nah text linear # nan (Bân-lâm-gú) node,way name:nan text linear # nap (Nnapulitano) node,way name:nap text linear # nb (Norsk (bokmål)) node,way name:nb text linear # nds (Plattdüütsch) node,way name:nds text linear # nds-nl (Nedersaksisch) node,way name:nds-nl text linear # ne (नेपाली) node,way name:ne text linear # new (नेपाल भाषा) node,way name:new text linear # ng (Oshiwambo) node,way name:ng text linear # nl (Nederlands) node,way name:nl text linear # nn (Norsk (nynorsk)) node,way name:nn text linear # no (Norsk (bokmål)) node,way name:no text linear # nomcom () node,way name:nomcom text linear # nov (Novial) node,way name:nov text linear # nrm (Nouormand) node,way name:nrm text linear # nv (Diné bizaad) node,way name:nv text linear # ny (Chi-Chewa) node,way name:ny text linear # oc (Occitan) node,way name:oc text linear # om (Oromoo) node,way name:om text linear # or (ଓଡ଼ିଆ) node,way name:or text linear # os (Иронау) node,way name:os text linear # pa (ਪੰਜਾਬੀ) node,way name:pa text linear # pag (Pangasinan) node,way name:pag text linear # pam (Kapampangan) node,way name:pam text linear # pap (Papiamentu) node,way name:pap text linear # pdc (Deitsch) node,way name:pdc text linear # pi (पािऴ) node,way name:pi text linear # pih (Norfuk / Pitkern) node,way name:pih text linear # pl (Polski) node,way name:pl text linear # pms (Piemontèis) node,way name:pms text linear # pnt (Ποντιακά) node,way name:pnt text linear # ps (پښتو) node,way name:ps text linear # pt (Português) node,way name:pt text linear # qu (Runa Simi) node,way name:qu text linear # rm (Rumantsch) node,way name:rm text linear # rmy (Romani) node,way name:rmy text linear # rn (Kirundi) node,way name:rn text linear # ro (Română) node,way name:ro text linear # roa-rup (Armãneashce) node,way name:roa-rup text linear # roa-tara (Tarandíne) node,way name:roa-tara text linear # ru (Русский) node,way name:ru text linear # rw (Kinyarwanda) node,way name:rw text linear # sa (संस्कृत) node,way name:sa text linear # sah (Саха тыла) node,way name:sah text linear # sc (Sardu) node,way name:sc text linear # scn (Sicilianu) node,way name:scn text linear # sco (Scots) node,way name:sco text linear # sd (سنڌي) node,way name:sd text linear # se (Sámegiella) node,way name:se text linear # sg (Sängö) node,way name:sg text linear # sh (Srpskohrvatski / Српскохрватски) node,way name:sh text linear # si (සිංහල) node,way name:si text linear # simple (Simple English) node,way name:simple text linear # sk (Slovenčina) node,way name:sk text linear # sl (Slovenščina) node,way name:sl text linear # sm (Gagana Samoa) node,way name:sm text linear # sn (chiShona) node,way name:sn text linear # so (Soomaaliga) node,way name:so text linear # sq (Shqip) node,way name:sq text linear # sr (Српски / Srpski) node,way name:sr text linear # srn (Sranantongo) node,way name:srn text linear # ss (SiSwati) node,way name:ss text linear # st (Sesotho) node,way name:st text linear # stq (Seeltersk) node,way name:stq text linear # su (Basa Sunda) node,way name:su text linear # sv (Svenska) node,way name:sv text linear # sw (Kiswahili) node,way name:sw text linear # szl (Ślůnski) node,way name:szl text linear # ta (தமிழ்) node,way name:ta text linear # te (తెలుగు) node,way name:te text linear # tet (Tetun) node,way name:tet text linear # tg (Тоҷикӣ) node,way name:tg text linear # th (ไทย) node,way name:th text linear # ti (ትግርኛ) node,way name:ti text linear # tk (Türkmençe) node,way name:tk text linear # tl (Tagalog) node,way name:tl text linear # tn (Setswana) node,way name:tn text linear # to (lea faka-Tonga) node,way name:to text linear # tokipona (Toki Pona) node,way name:tokipona text linear # tp (Toki Pona (deprecated:tokipona)) node,way name:tp text linear # tpi (Tok Pisin) node,way name:tpi text linear # tr (Türkçe) node,way name:tr text linear # ts (Xitsonga) node,way name:ts text linear # tt (Tatarça/Татарча) node,way name:tt text linear # tum (chiTumbuka) node,way name:tum text linear # tw (Twi) node,way name:tw text linear # ty (Reo Mā`ohi) node,way name:ty text linear # udm (Удмурт) node,way name:udm text linear # ug (Uyghurche / ئۇيغۇرچە) node,way name:ug text linear # uk (Українська) node,way name:uk text linear # ur (اردو) node,way name:ur text linear # uz (O'zbek) node,way name:uz text linear # ve (Tshivenda) node,way name:ve text linear # vec (Vèneto) node,way name:vec text linear # vi (Tiếng Việt) node,way name:vi text linear # vls (West-Vlams) node,way name:vls text linear # vo (Volapük) node,way name:vo text linear # wa (Walon) node,way name:wa text linear # war (Winaray) node,way name:war text linear # wo (Wolof) node,way name:wo text linear # wuu (吴语) node,way name:wuu text linear # xal (Хальмг) node,way name:xal text linear # xh (isiXhosa) node,way name:xh text linear # yi (ייִדיש) node,way name:yi text linear # yo (Yorùbá) node,way name:yo text linear # za (Vahcuengh) node,way name:za text linear # zea (Zeêuws) node,way name:zea text linear # zh (中文) node,way name:zh text linear # zh-cfr () node,way name:zh-cfr text linear # zh-classical (文言) node,way name:zh-classical text linear # zh-min-nan (Bân-lâm-gú) node,way name:zh-min-nan text linear # zh-yue (粵語) node,way name:zh-yue text linear # zu (isiZulu) node,way name:zu text linear
node,way natural text polygon # natural=coastline tags are discarded by a hard coded rule in osm2pgsql node,way oneway text linear node poi text node,way power text polygon node,way power_source text linear node,way place text linear node,way railway text linear node,way ref text linear node,way religion text nocache node,way residence text linear node,way route text linear node,way service text linear node,way sport text polygon node,way tourism text polygon way tracktype text linear node,way tunnel text linear node,way waterway text polygon node,way width text linear node,way wood text linear node,way z_order int4 linear # This is calculated during import way way_area real # This is calculated during import
# If you're interested in bicycle routes, you may want the following fields # To make these work you need slim mode or the necessary data won't be remembered. way lcn_ref text linear way rcn_ref text linear way ncn_ref text linear way lcn text linear way rcn text linear way ncn text linear way lwn_ref text linear way rwn_ref text linear way nwn_ref text linear way lwn text linear way rwn text linear way nwn text linear way route_pref_color text linear way route_name text linear way symbol text linear way osmc:symbol text linear way marked_trail text linear
way network text linear way surface text linear
node,way importance real node,way fee text linear way lanes int4 linear node,way information text linear node,way shop text linear node,way path text linear node,way tower text linear node,way lit text linear
# some more names that could be used for localized rendering and other experiments node,way alt_name text linear node,way old_name text linear node,way official_name text linear node,way loc_name text linear node,way nick_name text linear
2009/8/14 Peter Körner osm-lists@mazdermind.de:
i combined the wikimedia.style with your hike_n_bike.style and some of the alternatice name-tags and attached it. I think that the more of the existing data of osm is in the db, the more useful will it be for experiments, trying new things etc.
Thanks very much. Maybe at one point we should have a script that combines the original OSM file and additions from individual map developers into a single file so that updates are easier, but maybe it just works fine even without something like that.
Cheers Colin
I'm not sure if this will work as a change to the styles-file requires a complete re-import (it doesn't work with the diffs), but as I read even tiles.openstreetmap.org does a complete re-import once a week to fix complications with the diff-import, so there might be a chance..
Peter
Thanks very much. Maybe at one point we should have a script that combines the original OSM file and additions from individual map developers into a single file so that updates are easier, but maybe it just works fine even without something like that.
Peter Körner wrote:
Hello OSM folks
For the integration of osm into the wikipedia there will be localized maps in all languages that have their own wikipedia. The problem is, that a lot of countries are not translated yet.
To get an overview over the status and make translating those countries more easy, I created a tool that can be found at
http://cassini.toolserver.org/~mazder/multilingual-country-list/
I'd like to encourage everyone to spend some time making translated maps better. Comments welcome!
I am editing wrong names in JOSM. Whenever I click on the link, Remote Control plugin loads a map with a desired node (I can see and add node properties). However, the map shows some small island icon only and not a real shape. Is this okay?
Marcin Cieslak schrieb:
Peter Körner wrote:
Hello OSM folks
For the integration of osm into the wikipedia there will be localized maps in all languages that have their own wikipedia. The problem is, that a lot of countries are not translated yet.
To get an overview over the status and make translating those countries more easy, I created a tool that can be found at
http://cassini.toolserver.org/~mazder/multilingual-country-list/
I'd like to encourage everyone to spend some time making translated maps better. Comments welcome!
I am editing wrong names in JOSM. Whenever I click on the link, Remote Control plugin loads a map with a desired node (I can see and add node properties). However, the map shows some small island icon only and not a real shape. Is this okay?
Josm is just loading the node that makes up the countries' name on lower zoom levels, not the coastline. So you should only see a single node with place=country, nothing else.
Peter
2009/8/13 Peter Körner osm-lists@mazdermind.de:
To get an overview over the status and make translating those countries more easy, I created a tool that can be found at
http://cassini.toolserver.org/~mazder/multilingual-country-list/
I'd like to encourage everyone to spend some time making translated maps better. Comments welcome!
Montenegro is still missing from the list of countries, its node id is 445970763 and I only added it about two weeks ago because I noticed it was missing when adding some tags to all the countries.
http://www.openstreetmap.org/browse/node/445970763
The instructions at the top of the pages could also mention the official_name:* tags - I don't know if these are approved in any way but I found they were on some of the nodes and I thought it was a good idea to propagate these too where the full name differs from the normal name the country is known by (which could otherwise be placed in loc_name, but it should probably be the one displayed by default)
Cheers
Hi Peter,
Peter Körner schreef:
Hello OSM folks
For the integration of osm into the wikipedia there will be localized maps in all languages that have their own wikipedia. The problem is, that a lot of countries are not translated yet.
I see you created your own tool. Probably works just fine, but you might be interested in http://translatewiki.net : "Translatewiki.net is a localisation platform for translation communities, language communities, and open source projects. It started out with localisation for MediaWiki. Later support for MediaWiki extensions, FreeCol and other open source projects was added."
Maarten
Maarten Dammers schrieb:
Hi Peter,
Peter Körner schreef:
Hello OSM folks
For the integration of osm into the wikipedia there will be localized maps in all languages that have their own wikipedia. The problem is, that a lot of countries are not translated yet.
I see you created your own tool. Probably works just fine, but you might be interested in http://translatewiki.net : "Translatewiki.net is a localisation platform for translation communities, language communities, and open source projects. It started out with localisation for MediaWiki. Later support for MediaWiki extensions, FreeCol and other open source projects was added."
Maarten
Hum, but how would you exchange data between the osm-db and translatewiki? Can this be done with a bot (in both directions?) I never wrote a bot for a wiki, so I don't know what may be done with it..
Peter
Peter Körner schrieb:
Hello OSM folks
For the integration of osm into the wikipedia there will be localized maps in all languages that have their own wikipedia. The problem is, that a lot of countries are not translated yet.
To get an overview over the status and make translating those countries more easy, I created a tool that can be found at
http://cassini.toolserver.org/~mazder/multilingual-country-list/
I'd like to encourage everyone to spend some time making translated maps better. Comments welcome!
Peter
Update:
I added CSV & GPX export and highlights for identical translations (when the name:xx-Tag is identical to the name-Tag).
Also I added delete-support to the update-routine so that it should delete translations that are no longer in the osm-database. It should also delete nodes that are no longer flagged as place=country.
I didn't have the time for intensive testing, so if you encounter any unexpected behavior, please just report this here.
Each hour, right before the update, i create an sql-dump, so restoring the ok-states should be not too much trouble.
Peter
Peter Körner wrote:
Hello OSM folks
For the integration of osm into the wikipedia there will be localized maps in all languages that have their own wikipedia. The problem is, that a lot of countries are not translated yet.
To get an overview over the status and make translating those countries more easy, I created a tool that can be found at
http://cassini.toolserver.org/~mazder/multilingual-country-list/
I'd like to encourage everyone to spend some time making translated maps better. Comments welcome!
Peter
The files are sent with "Content-Type: text/html" (ie. no charset). The pages are utf-8 but my browser -and probably many others too- is assuming ISO-8859-1. Please change the header to properly provide charset=utf8.
Platonides schrieb:
Peter Körner wrote:
Hello OSM folks
For the integration of osm into the wikipedia there will be localized maps in all languages that have their own wikipedia. The problem is, that a lot of countries are not translated yet.
To get an overview over the status and make translating those countries more easy, I created a tool that can be found at
http://cassini.toolserver.org/~mazder/multilingual-country-list/
I'd like to encourage everyone to spend some time making translated maps better. Comments welcome!
Peter
The files are sent with "Content-Type: text/html" (ie. no charset). The pages are utf-8 but my browser -and probably many others too- is assuming ISO-8859-1. Please change the header to properly provide charset=utf8.
Whoops, sorry for that. All my servers are set up to serve utf8 automatically (as well as serving application/octet-stream instead of text/plain as default, but that's another one), so i forgot to do this.
Thank you for your message! Peter
On Wed, Aug 12, 2009 at 7:28 PM, Peter Körner osm-lists@mazdermind.dewrote:
Hello OSM folks
For the integration of osm into the wikipedia there will be localized maps in all languages that have their own wikipedia. The problem is, that a lot of countries are not translated yet.
To get an overview over the status and make translating those countries more easy, I created a tool that can be found at
http://cassini.toolserver.org/~mazder/multilingual-country-list/http://cassini.toolserver.org/%7Emazder/multilingual-country-list/
I'd like to encourage everyone to spend some time making translated maps better. Comments welcome!
Peter
For the OSM translations, do we really want separate name:arz tags (Egyptian Arabic), when the country names are the same as standard Arabic? Having a separate Wikipedia for Egyptian was controversial in the first place, and many don't really consider it a separate language but rather consider it a dialect.
In the postgres db views, can we map the Arabic (ar) names to arz?
There may be other situations like this, where separate tags in OSM might not be needed.
-Aude
Maps-l mailing list Maps-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/maps-l
Peter Körner wrote:
Hello OSM folks
For the integration of osm into the wikipedia there will be localized maps in all languages that have their own wikipedia. The problem is, that a lot of countries are not translated yet.
To get an overview over the status and make translating those countries more easy, I created a tool that can be found at
http://cassini.toolserver.org/~mazder/multilingual-country-list/
I'd like to encourage everyone to spend some time making translated maps better. Comments welcome!
Some translations show up orange. What does that signify?
And a typo: endlish -> english
Regards, Maarten
Maarten Deen schrieb:
Peter Körner wrote:
Hello OSM folks
For the integration of osm into the wikipedia there will be localized maps in all languages that have their own wikipedia. The problem is, that a lot of countries are not translated yet.
To get an overview over the status and make translating those countries more easy, I created a tool that can be found at
http://cassini.toolserver.org/~mazder/multilingual-country-list/
I'd like to encourage everyone to spend some time making translated maps better. Comments welcome!
Some translations show up orange. What does that signify?
And a typo: endlish -> english
Regards, Maarten
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.
Peter
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
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
2009/8/23 Peter Körner osm-lists@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
I need some advice: I'm currently translating the names to Portuguese, and for some countries the portuguese name differ from the brazilian portuguese (which I speak) to the european portuguese. So, should I tag, "official_/name:pt=one of the forms" or "official_/name:pt=brazilian portuguese name; european portuguese name"? Or maybe official_/name:pt_PT and official_/name:pt_BR?
Cheers,
2009/8/12 Peter Körner osm-lists@mazdermind.de:
Hello OSM folks
For the integration of osm into the wikipedia there will be localized maps in all languages that have their own wikipedia. The problem is, that a lot of countries are not translated yet.
To get an overview over the status and make translating those countries more easy, I created a tool that can be found at
http://cassini.toolserver.org/~mazder/multilingual-country-list/
I'd like to encourage everyone to spend some time making translated maps better. Comments welcome!
Peter
talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Arlindo Pereira schrieb:
I need some advice: I'm currently translating the names to Portuguese, and for some countries the portuguese name differ from the brazilian portuguese (which I speak) to the european portuguese. So, should I tag, "official_/name:pt=one of the forms" or "official_/name:pt=brazilian portuguese name; european portuguese name"? Or maybe official_/name:pt_PT and official_/name:pt_BR?
Cheers,
The list of languages presented is derived from the languages that their own wikipedia [1], because that's the most prominent place those localized maps will be visible. If you're unsure I'd suggest to use the name of the corresponding article in the wikipedia for the language-code on the list.
Despite of that feel free to add another tag with the other name. Please take a look at [2] and check if there's a language-code for it. Please consider also asking at talk-pt [3], although there's not much traffic..
Peter
[1] http://en.wikipedia.org/wiki/Special:SiteMatrix [2] http://www.loc.gov/standards/iso639-2/php/code_list.php [3] http://lists.openstreetmap.org/listinfo/talk-pt
2009/8/16 Arlindo Pereira nighto@nighto.net:
I need some advice: I'm currently translating the names to Portuguese, and for some countries the portuguese name differ from the brazilian portuguese (which I speak) to the european portuguese. So, should I tag, "official_/name:pt=one of the forms" or "official_/name:pt=brazilian portuguese name; european portuguese name"? Or maybe official_/name:pt_PT and official_/name:pt_BR?
I think I remember someone using @ instead of _ in those OSM language codes for these kind of differences, I don't remember if that is "approved" or anything (possibly it was part of this same thread). But by all means add both forms (either both in name:pt or separate tags) so that they become searchable.
Cheers
Hi
I think there was a bug introduced during resorting of the list or during the transition from zh-classic -> zh-classical. The list behaves strange. Once I noticed that when i changed a country name in one language, the status of the same country name in another language changed also. I cannot verify or nail down any bug from remote.
Please see also the image attached which shows a 100.43% progress for translation of the Arabic country names. http://cassini.toolserver.org/~mazder/multilingual-country-list/?lang=ar
It reaches 100% when *Tromelin Island *is set to not-ok.
Gruess, Micha
Thank you for the bug-report, i'll check both bugs soon.
Peter
I think there was a bug introduced during resorting of the list or during the transition from zh-classic -> zh-classical. The list behaves strange. Once I noticed that when i changed a country name in one language, the status of the same country name in another language changed also. I cannot verify or nail down any bug from remote.
Please see also the image attached which shows a 100.43% progress for translation of the Arabic country names. http://cassini.toolserver.org/~mazder/multilingual-country-list/?lang=ar
It reaches 100% when /Tromelin Island /is set to not-ok.
Hi
As I guessed the bug with the >100% comes from countries that aren't countries anymore. They are removed from the list with the hourly update, but if you got your list open while this happens you can still mark it as ok. so we got a country that only exists in this language - and more than 100% ok :)
I removed those countries and included a fix in the ajax-script that handles the mark-ok-request that checks for the existence of this country in the list.
Namely they are http://www.openstreetmap.org/browse/node/424313867 and http://www.openstreetmap.org/browse/node/424317578 which are both islands now. By the way i added http://www.openstreetmap.org/browse/node/25342325 (Alderney) which was somehow missing.
The other bug is a hard one. As long as I'm not able to reproduce it, i can't fix it.
I'm feeling sorry about having these bug in this tool. It was just an experiment, hacked together in three or four nights - so no clear structure in the programming nor the database. I know I can do better (I'm doing every day at work) but this was my first tool on a toolserver, my with first tool working with geo-data and my first tool using the osm-api, so please perceive it just as an hacky experiment - not fully worked-out tool, and thus be gently with me :)
Just had to say that.
Peter
I think there was a bug introduced during resorting of the list or during the transition from zh-classic -> zh-classical. The list behaves strange. Once I noticed that when i changed a country name in one language, the status of the same country name in another language changed also. I cannot verify or nail down any bug from remote.
Please see also the image attached which shows a 100.43% progress for translation of the Arabic country names. http://cassini.toolserver.org/~mazder/multilingual-country-list/?lang=ar
It reaches 100% when /Tromelin Island /is set to not-ok.
2009/8/18 Peter Körner osm-lists@mazdermind.de:
Namely they are http://www.openstreetmap.org/browse/node/424313867 and http://www.openstreetmap.org/browse/node/424317578 which are both islands now. By the way i added http://www.openstreetmap.org/browse/node/25342325 (Alderney) which was somehow missing.
*poke* (Montenegro is still missing)
Cheers
andrzej zaborowski schrieb:
2009/8/18 Peter Körner osm-lists@mazdermind.de:
Namely they are http://www.openstreetmap.org/browse/node/424313867 and http://www.openstreetmap.org/browse/node/424317578 which are both islands now. By the way i added http://www.openstreetmap.org/browse/node/25342325 (Alderney) which was somehow missing.
*poke* (Montenegro is still missing)
It seems there is no node for it. Searching if with the Namefinder doesn't bring up a node. I'd need a node id to add it to the list.
Peter
Peter Körner wrote:
(Montenegro is still missing)
It seems there is no node for it. Searching if with the Namefinder doesn't bring up a node. I'd need a node id to add it to the list.
I think it's 445970763
2009/8/19 Peter Körner osm-lists@mazdermind.de:
andrzej zaborowski schrieb:
2009/8/18 Peter Körner osm-lists@mazdermind.de:
Namely they are http://www.openstreetmap.org/browse/node/424313867 and http://www.openstreetmap.org/browse/node/424317578 which are both islands now. By the way i added http://www.openstreetmap.org/browse/node/25342325 (Alderney) which was somehow missing.
*poke* (Montenegro is still missing)
It seems there is no node for it. Searching if with the Namefinder doesn't bring up a node. I'd need a node id to add it to the list.
It's 445970763 as mentioned in http://lists.openstreetmap.org/pipermail/talk/2009-August/040327.html
Cheers
andrzej zaborowski schrieb:
2009/8/19 Peter Körner osm-lists@mazdermind.de:
andrzej zaborowski schrieb:
2009/8/18 Peter Körner osm-lists@mazdermind.de:
Namely they are http://www.openstreetmap.org/browse/node/424313867 and http://www.openstreetmap.org/browse/node/424317578 which are both islands now. By the way i added http://www.openstreetmap.org/browse/node/25342325 (Alderney) which was somehow missing.
*poke* (Montenegro is still missing)
It seems there is no node for it. Searching if with the Namefinder doesn't bring up a node. I'd need a node id to add it to the list.
It's 445970763 as mentioned in http://lists.openstreetmap.org/pipermail/talk/2009-August/040327.html
Cheers
I can confirm that: http://www.openstreetmap.org/browse/node/445970763. I'll add it this evening.
Peter