Currently we have the English word "Exit" in the default lines style file, which is used by the exit_hint option. Obviously it isn't appropriate for all languages, so I'm using a simple hack to avoid it, that consist in changing "Exit" by the variable ${mkgmap:exit_tr} in the style file and defining it in addresses file with lines of the form mkgmap:country=ESP { set mkgmap:exit_tr='Salida' }. It works fine, but I have thought of an better system that may be worth implementing it to be used somewhere else (may be in the nsis template). It would consist in: 1-Adding a lang=xx definition to each country entry in LocatorConfig.xml 2-Creating a translations file with entries for each language: exit_tr: en=Exit es=Salida fr=Sortie ... another_word_tr: en=word es=palabra fr=mot ... What do you think? Would it be easy to implement it?
Am 10.04.2013 17:07, schrieb Carlos Dávila:
Currently we have the English word "Exit" in the default lines style file, which is used by the exit_hint option. Obviously it isn't appropriate for all languages, so I'm using a simple hack to avoid it, that consist in changing "Exit" by the variable ${mkgmap:exit_tr} in the style file and defining it in addresses file with lines of the form mkgmap:country=ESP { set mkgmap:exit_tr='Salida' }. It works fine, but I have thought of an better system that may be worth implementing it to be used somewhere else (may be in the nsis template). I don't think that this is a good thing. It's better to decide it in style-file. Of course it will cause some lines more, but everyone can decide, if he wants to have a map of Spain with Salida, Exit or what ever.
Henning
Hi Carlos, Carlos Dávila-2 wrote
Currently we have the English word "Exit" in the default lines style file, which is used by the exit_hint option. Obviously it isn't appropriate for all languages,
This already bothered me too. I was wondering if it weren't possible to use the built-in translations of the Garmin Device itself. I mean the translations in the *.gtt Files from the GARMIN/Text directory on the Garmin device. Exit would be TXT_Exit_STR_M Has anyone ever tried whether or not we can use GARMIN Text Constants in the map ? Ciao, Franco -- View this message in context: http://gis.19327.n5.nabble.com/Translation-system-proposal-tp5756506p5756577... Sent from the Mkgmap Development mailing list archive at Nabble.com.
On Wed, Apr 10, 2013 at 10:04:20PM -0700, franco_bez wrote:
I was wondering if it weren't possible to use the built-in translations of the Garmin Device itself. I mean the translations in the *.gtt Files from the GARMIN/Text directory on the Garmin device. Exit would be TXT_Exit_STR_M
Is the GARMIN/Text a feature of newer devices? I do not remember seeing anything like that on my Edge 705.
Has anyone ever tried whether or not we can use GARMIN Text Constants in the map ?
As far as I understand, the 'default name' of unnamed things can be defined in the TYP file, for every supported language code. In NT maps (which mkgmap cannot generate) you could represent object names in multiple languages (say, street names in French or Dutch in Belgium, selectable on the device). FWIW (this would require changes to the Garmin firmware) I think that language and country should be kept separate. Ideally, it should be something like the language selection on web browsers. The user would give his list of preferred languages in the order of preference. The first matching language would be chosen for display, among all name:* in the OSM data. This would imply that all name:*=* strings would be carried over to the map, so that the user can select the language dynamically. It could be doable after deciphering the NT format, or in a new map application such as OsmAnd. Marko
Marko Mäkelä wrote
On Wed, Apr 10, 2013 at 10:04:20PM -0700, franco_bez wrote:
I was wondering if it weren't possible to use the built-in translations of the Garmin Device itself. I mean the translations in the *.gtt Files from the GARMIN/Text directory on the Garmin device. Exit would be TXT_Exit_STR_M
Is the GARMIN/Text a feature of newer devices? I do not remember seeing anything like that on my Edge 705.
I have this on the Oregon 550 and the Nüvi 40, I don't know about older devices. This is a set of xml Files where the Firmware gets the translations when you change the language setting.
Has anyone ever tried whether or not we can use GARMIN Text Constants in the map ?
As far as I understand, the 'default name' of unnamed things can be defined in the TYP file, for every supported language code. In NT maps (which mkgmap cannot generate) you could represent object names in multiple languages (say, street names in French or Dutch in Belgium, selectable on the device).
I noticed that when there is no name at all in the map, then the firmware uses a (translated) default, probably based on the typ-id of the Object. Ciao, Franco -- View this message in context: http://gis.19327.n5.nabble.com/Translation-system-proposal-tp5756506p5756591... Sent from the Mkgmap Development mailing list archive at Nabble.com.
Yes Marko, this is a feature of newer devices. Could you please take a look at the style names with brand/operator? I think you only had this intended for gas stations but it has an impact on all pois. See my previous post at http://www.mail-archive.com/mkgmap-dev@lists.mkgmap.org.uk/msg15334.html
Is the GARMIN/Text a feature of newer devices? I do not remember seeing anything like that on my Edge 705.
On Thu, Apr 11, 2013 at 10:18:01AM +0200, Minko wrote:
Yes Marko, this is a feature of newer devices.
OK.
Could you please take a look at the style names with brand/operator? I think you only had this intended for gas stations but it has an impact on all pois.
I actually intended it for privately maintained roads, bus stops, buildings that are accessible to the public, and the like.
See my previous post at http://www.mail-archive.com/mkgmap-dev@lists.mkgmap.org.uk/msg15334.html
Sorry, I missed this one. I see, it is probably not useful to add operator to place=* POIs. Also the city ref could be viewed as clutter by most map users except those who are extremely interested in administration. What other POIs do you think should not get brand, operator, ref added to the name? Only place=* and boundary=*, or do you have other examples in mind? Best regards, Marko
Hi Marko, I think it really depends where the data comes from, I saw accidently this place, but with a lot of data being imported you can expect more "strange" names. I think you better add those specific names to the categories you really want to add it and not a make general rule for the names.
Sorry, I missed this one. I see, it is probably not useful to add operator to place=* POIs. Also the city ref could be viewed as clutter by most map users except those who are extremely interested in administration.
What other POIs do you think should not get brand, operator, ref added to the name? Only place=* and boundary=*, or do you have other examples in mind?
Best regards,
Marko
Hi Marko, With the Overpass turbo tool you can find some examples in a certain area for instance all nodes with name & ref: http://overpass-turbo.eu/?q=PCEtLQpUaGlzIMSHIGFuIGV4YW1wbGUgT3ZlcnBhc8SIcXXE... This Post office gets a name tag "PostNL 9320156662: Mado" I dont think the ref tag is very useful ;-) http://www.openstreetmap.org/browse/node/1658220379 Also brand or operator names that are the same as the name tag, for instance brand=Esso name=Esso can be ignored. There is a style rule that can compare if the brand name is the same as the name tag: ${brand|not-equal:name} or ${operator|not-equal:name}.
Hi Minko,
With the Overpass turbo tool you can find some examples in a certain area for instance all nodes with name & ref:
Thanks, good to know. I have used Osmosis on downloaded map extracts until now.
This Post office gets a name tag "PostNL 9320156662: Mado" I dont think the ref tag is very useful ;-)
I would also say that it should be brand=PostNL, name=Mado instead of name=Mado, operator=PostNL. I am not sure if we should try to filter out garbage that has been put to the map data. I would rather fix the map data than to work around errors in it.
Also brand or operator names that are the same as the name tag, for instance brand=Esso name=Esso can be ignored. There is a style rule that can compare if the brand name is the same as the name tag: ${brand|not-equal:name} or ${operator|not-equal:name}.
OK, this makes sense. Marko
participants (5)
-
Carlos Dávila -
franco_bez -
Henning Scholland -
Marko Mäkelä -
Minko