Re: [HOT] Name tag in non-latin script - hindrance for NGOs/aid agencies?

[Mikel Maron]

There’s no reason to hide this about a dispute in Bangladesh when that’s 
already in the open, and there’s definitely overlap between the two mailing 
lists.
https://lists.openstreetmap.org/pipermail/talk-bd/2019-November/000151.html 

My position is that it’s hard to understand why you’d want to map in English 
when the local names are otherwise. As far as I know this isn’t an issue in 
other countries where international NGOs operate, who should have the capacity 
to use name:en if needed. So yes count me confused by the position of OSM 
Bangladesh.
But I certainly don’t know the ins and outs of this particular situation, the 
people and the history behind how things have been organized in Bangladesh. 
What seems more important here than poking holes in arguments on public mailing 
lists is an attempt at a healthy dialog between the parties involved in the 
dispute.
Mikel

On Wednesday, November 27, 2019, 7:00 PM, Frederik Ramm  
wrote:

Dear HOT list,

the DWG has been involved in a discussion being had by the community in
a country where the official language uses non-latin characters.

I would like to keep this abstract hence I will not say which country it
is even though some of you will know; I don't think it matters. It is
not Japan but you can imagine Japan if you need an example.

In the country, more than 98% of the population speak the official
language as their native language, though English is commonly taught at
school and used in higher education. Older people or people outside of
the university system will often not be able to write English fluently.

Signs (road signs, signposts) seem to be exclusively in the official
language if less important, and in official language plus English where
more important. It is claimed that some signs in big cities are
English-only but I haven't yet seen one.

There is a dominant group in the country that says: Let us use English
for our "name" tags, and put the official language in name:xx (where xx
is the language code). This is relatively unusual for OSM, but it seems
to be the current consensus in the community. Some of them also request
that changeset discussions should be had in English instead of the
official language. Just like in many other countries, OSM was first
adopted by people at or involved with universities and hence used to
English, so the decision came lightly.

Parts of the discussion hinge on not all IT systems properly supporting
the special characters needed for the official language; but the main
argument brought up again and again by the proponents is that there are
many people from aid agencies and NGOs contributing data to OSM or using
data from OSM in that country, and the data was of lesser use (or even
useless) to them if name tags were in the official language. (This
reasoning is also used for the request to hold changeset discussions in
English.)

We have been told by the pro-English-name group:

> as the major user & contributors to the local repository are the aid agencies 
> like UN, MSF, Red Cross/Red Crescent eventually they are also facing problem 
> while using the data ... We have been reported a recent case were WFP was 
> unable to use the data due to this reason. ... Aid agencies like UN, MSF, Red 
> Crescent have run many projects to map large portions of the country and 
> given those data to OSM, which makes them big contributors and users of the 
> OSM data. But this data becomes useless if all `name` tags are replaced with 
> [local language] ... The Humanitarian OpenStreetMap Team (HOT) made a map for 
> disaster response that is available in OSM main site as an additional layer, 
> which also can't render [local language]. And that makes it a challenge in 
> times of disaster response.

Of course, the pro-local-name group feels stymied by the request to use
English; they feel this is an sign that the map is not "their" map but
someone else's and that requesting English changeset discussions
practically excludes large parts of the population.

This is an issue that ultimately the local community must solve for
itself. But it seems to be that there might be a danger of favouring
the comfort of international contributors and NGOs over that of the
local population - in a line of thought that goes "the map in our
country gains more if we can keep these NGOs interested by using
English, than if we attract the less-well-English speaking citizens of
our country".

I hope that there might be people from the organisations mentioned (UN,
MSF, Red Cross/Red Crescent, WFP, HOT) on this list who can tell me if
their organisations have policies or a general approach towards issues
like this. Is this a thing, projects hinging on whether the locals are
willing to deal in English? Or is "we have to use English to favour our
international partners" a red herring?

Bye
Frederik

-- 
Frederik Ramm  ##  eMail frede...@remote.org  ##  N49°00'09" E008°23'33"

___
HOT mailing list

Re: [HOT] Name tag in non-latin script - hindrance for NGOs/aid agencies?

[Pierre Béland via HOT]

Summary of Frederik Ramm presentation> the DWG has been involved in a 
discussion being had by the community in
a country where the official language uses non-latin characters.
> more than 98% of the population speak the official language as their native 
> language
> Older people or people outside of the university system will often not be 
> able to write English fluently.
> Signs (road signs, signposts) seem to be exclusively in the official
language 
> There is a dominant group in the country that says: Let us use English

This is a country where the great majority of the people (98%) speak the native 
language and where many are not fluent in english.  Sign post are it seem in 
native language except for the major roads.

Like for many african countries, their access to the digital world is often 
through phones. And surely applications could be adapted to let them access the 
information in their one language / alphabet including why not Maps.  Various 
experimentations of  Vector map layers that let switch from languages / 
alphabets show that it is possible to answer the needs of various communities.  
And the humanitarian international community would be surely better served if 
it could know the local road names and not only an english translation. 

NGOs/aid agencies is to develop the country. I also suppose that this is a non 
permanent situation and that the best is to do it with empowering the Local 
community to develop their country.

If the first to OSM contributors were mostly educated, mostly communicating in 
english and adapting rules to favor english, they should now take time to favor 
more participation and discuss about this and see if some compromises can be 
adopted.  But importantly this should be done with respect. The first adopters 
should avoid imposing their view, but take time to listen to others.

As it has been said, it is possible to add both name, name:native and name:en.  
From there it will later be easy to structure the info with the official name 
being :native or :en.
Below are some statistics I gathered from Nov.27 OSM extract for nodes having 
names. It shows that the great majoriy of names (79%) are only in english.  The 
major problem seems to assure that local names be offered in OSM.  

A big data collection effort to realize. And good challenges for our 
developpers.


Country OSM nodes statistics  that contain namesfrom Nov.27 Geofabrik extract
Name  :native   :en    Count---
bn                    1,670
bn            en     3,709
bn native           93
bn native  en     1,901
en               31,792
en            en    185
en  native     872en  native en      
59---
Total                   40,281


Pierre 

___
HOT mailing list
HOT@openstreetmap.org
https://lists.openstreetmap.org/listinfo/hot

Re: [HOT] Name tag in non-latin script - hindrance for NGOs/aid agencies?

[john whelan]

I think the major problem is how do we move forward.

XML is basically a system of containers a beginning tag and an end tag.
The nice thing about it is you can add fields to the file and existing
programs will still work. They'll just ignore the new fields.  They don't
have to understand or use unicode.  The data in the containers themselves
may or may not use the unicode sixteen bit character set.

We have legacy data, the suggestion of copying the contents if latin
alphabet into name:en is sensible.  It preserves the existing data.

Adding the local name value in a name: whatever at least allows people to
work in the language of their choice.

The secondary problem of legacy data is how it has been used in the past.
There are probably software programs, documentation including teachers'
notes, wiki and tutorials that would need to be updated to handle putting
the local language in the name field.  In the past on one of my systems a
technical person once changed the value of the port to connect to.  We'd
just printed and sent out a stack of user manuals that had the old port
number printed in them the cost to us was quite high.  We also found that
people had made their own shortened notes and they kept tripping us up for
a long time afterwards.  In the case of OpenStreetMap you've no idea who
has written instructions, or in what language.

Then you get to the person in the field who may not have the latest smart
phone or technical support or even internet.  To quote Philippe "mobile
phones that don't have a lot of embedded fonts and support a more limited
set " What they have today works.  Change it so they see small blocks
instead of letters and it no longer works for them.  Are we asking them to
buy new phones?

In commercial computer systems there is something called change management
and it is recognised that changes to computer systems can have a big
impact.  Yes if we were starting again from scratch we wouldn't have done
things the way they were done but they were done in a particular way
usually for cost reasons and I think it should be recognised.

Cheerio John

On Thu, 28 Nov 2019 at 14:11, Nasir Khan  wrote:

> Hi,
> I believe a little more information needed to be added here to point the
> discussion to the right direction. The language usage a is not Latin script
> and the Unicode block is completely ok. So there is no issue in writing
> that language anywhere in internet and no additional special font is needed
> as well to render properly. At it is true that Unicode contains all the
> letter of all the languages, so if the font has the language specific
> Unicode block it should be displayed properly.
>
> So far from my experience i can say, that country map is not complete in
> OSM. Being an open source product there is a trust and dependability issue
> as well. More people are trying to use and showing interest here now a
> days, because Google is expensive. What are the outlets of using OSM from
> desktop and mobile? Those who are active and contributing for a longer than
> me can easily list top most popular/ used apps or sites to use OSM. How
> many of them supports complex non-latin unicode characters perfectly? I
> found only a very few but there could be more.
>
> So the map is incomplete with less data, there are also incorrect data and
> we are forcing to move it in a place where it will become completely
> useless. Because the softwares can not show the texts properly. Will it be
> helpful for that language or for that country?
>
> I am not against using the native language, rather i am contributing to
> Wikipedia and a number of open source communities on the same language
> version for more than 12 years. I am also involved in a number of language
> specific national expert committees. But here i am giving my opinion not to
> use the native language now atleast for the time being.
>
> It is true that all the people of the country are comfortable and prefer
> native language. Can you please provide me data what percentage of them are
> using OSM website and how many of them have a navigation app which is based
> on OSM? what are the use cases we are targeting to cover?
>
> If we write `name` in English and add the native name in `name:xx` and
> also add English in `name:en` for now and will it be impossible to move all
> the `name:xx` to `name` when scenario improves? I believe it could be done
> via automated scripts.
>
> Regards
> Nasir Khan
>
> --
> *Nasir Khan Saikat*
> www.nasirkhn.com
>
>
>
> On Fri, 29 Nov 2019 at 00:18, Philippe Verdy  wrote:
>
>> XML never started from scratch based on old versions of SGML or any
>> updated version of SGML.
>> When it was created, Unicode was already there and its support in XML was
>> mandatary from the start, including the support for UTF-8 by default. And
>> It was based on the earlier work on XHTML which already included Unicode
>> support by default as well, from the current development of HTML4 which was
>> also updated to 

Re: [HOT] Name tag in non-latin script - hindrance for NGOs/aid agencies?

[Nasir Khan]

Hi,
I believe a little more information needed to be added here to point the
discussion to the right direction. The language usage a is not Latin script
and the Unicode block is completely ok. So there is no issue in writing
that language anywhere in internet and no additional special font is needed
as well to render properly. At it is true that Unicode contains all the
letter of all the languages, so if the font has the language specific
Unicode block it should be displayed properly.

So far from my experience i can say, that country map is not complete in
OSM. Being an open source product there is a trust and dependability issue
as well. More people are trying to use and showing interest here now a
days, because Google is expensive. What are the outlets of using OSM from
desktop and mobile? Those who are active and contributing for a longer than
me can easily list top most popular/ used apps or sites to use OSM. How
many of them supports complex non-latin unicode characters perfectly? I
found only a very few but there could be more.

So the map is incomplete with less data, there are also incorrect data and
we are forcing to move it in a place where it will become completely
useless. Because the softwares can not show the texts properly. Will it be
helpful for that language or for that country?

I am not against using the native language, rather i am contributing to
Wikipedia and a number of open source communities on the same language
version for more than 12 years. I am also involved in a number of language
specific national expert committees. But here i am giving my opinion not to
use the native language now atleast for the time being.

It is true that all the people of the country are comfortable and prefer
native language. Can you please provide me data what percentage of them are
using OSM website and how many of them have a navigation app which is based
on OSM? what are the use cases we are targeting to cover?

If we write `name` in English and add the native name in `name:xx` and also
add English in `name:en` for now and will it be impossible to move all the
`name:xx` to `name` when scenario improves? I believe it could be done via
automated scripts.

Regards
Nasir Khan

--
*Nasir Khan Saikat*
www.nasirkhn.com



On Fri, 29 Nov 2019 at 00:18, Philippe Verdy  wrote:

> XML never started from scratch based on old versions of SGML or any
> updated version of SGML.
> When it was created, Unicode was already there and its support in XML was
> mandatary from the start, including the support for UTF-8 by default. And
> It was based on the earlier work on XHTML which already included Unicode
> support by default as well, from the current development of HTML4 which was
> also updated to enforce the behavior for Unicode (notably it was made clear
> that to be conforming, the numeric character references could only refer to
> the UCS codepoints, independently of the charset used for the document, and
> that all charsets had to have a mapping to the UCS.
>
> Now the issue is possibly elsewhere: when languages uses a script or
> orthography not based on Unicode because it is still not well supported or
> has problems.
> - there were problems for Korean in Unicode 1.0 before the merge with the
> ISO 10646, but Unicode 1.0 is dead since long and no software today are
> making any reference to Unicode 1.0;
> - there has been problems with the Unicode encoding for Burmese, and
> Mongolian, they are mostly solved, except Mongolian with works still
> pending for the behavior of some clusters and the best way to encode the
> vowels, this will soon change but yes in that case there are problems; but
> the change will not be from adopting or not Unicode, but in the best
> sequences of Unicode characters to use to represent these clusters: this is
> an orthographic change, not a change of encodings, but yes in that ase it
> measn changing Unicode fonts for other updated Unicode fonts; no hack based
> on legacy charsets are involded.
>
> Now there remains languages/scripts not encoded at all (not in Unicode and
> not even in any other charset): making a reference to a legacy ISO chartset
> is inapplicable as there's no such legacy charset. All that an be done for
> now in these languages is to use some transliteration (but not necessarily
> Latin): Uyghur for example is generally written in that case using Chinese
> sinograms (with some specific forms in rare cases), or Arabic (with some
> additional diacritics and forms, but if thee forms are not handled in
> fonts, at least there's a basic orthography that is readable, the same way
> that we can substitute some characters in Latin or remove some diacritics
> for African languages, or simply not encoding some ligatures by writing
> digrams instead: this is what happens already when these langauges are used
> in some international documents and forms like passports: there's a
> degraded orthography, but this is still readable and sufficiently
> distinctive for 

Re: [HOT] Name tag in non-latin script - hindrance for NGOs/aid agencies?

[Philippe Verdy]

XML never started from scratch based on old versions of SGML or any updated
version of SGML.
When it was created, Unicode was already there and its support in XML was
mandatary from the start, including the support for UTF-8 by default. And
It was based on the earlier work on XHTML which already included Unicode
support by default as well, from the current development of HTML4 which was
also updated to enforce the behavior for Unicode (notably it was made clear
that to be conforming, the numeric character references could only refer to
the UCS codepoints, independently of the charset used for the document, and
that all charsets had to have a mapping to the UCS.

Now the issue is possibly elsewhere: when languages uses a script or
orthography not based on Unicode because it is still not well supported or
has problems.
- there were problems for Korean in Unicode 1.0 before the merge with the
ISO 10646, but Unicode 1.0 is dead since long and no software today are
making any reference to Unicode 1.0;
- there has been problems with the Unicode encoding for Burmese, and
Mongolian, they are mostly solved, except Mongolian with works still
pending for the behavior of some clusters and the best way to encode the
vowels, this will soon change but yes in that case there are problems; but
the change will not be from adopting or not Unicode, but in the best
sequences of Unicode characters to use to represent these clusters: this is
an orthographic change, not a change of encodings, but yes in that ase it
measn changing Unicode fonts for other updated Unicode fonts; no hack based
on legacy charsets are involded.

Now there remains languages/scripts not encoded at all (not in Unicode and
not even in any other charset): making a reference to a legacy ISO chartset
is inapplicable as there's no such legacy charset. All that an be done for
now in these languages is to use some transliteration (but not necessarily
Latin): Uyghur for example is generally written in that case using Chinese
sinograms (with some specific forms in rare cases), or Arabic (with some
additional diacritics and forms, but if thee forms are not handled in
fonts, at least there's a basic orthography that is readable, the same way
that we can substitute some characters in Latin or remove some diacritics
for African languages, or simply not encoding some ligatures by writing
digrams instead: this is what happens already when these langauges are used
in some international documents and forms like passports: there's a
degraded orthography, but this is still readable and sufficiently
distinctive for practical uses and isolated text fragemtsn are not the
onily source of disambiguation as there are other contextual information,
including photo and biometric data or unique identifiers, and a scanned
handwritten signature, plus personal data, including address for
identification purpose).

Anyway, even if there's a prefered orthography, slight deviation of
orthograhy is very common and frequently used in public displays or
advertizing, and no one is confused. And the "prefered" orthography is just
a matter of choice and is unstable across time, or even space when there
are competing authorities providing their own local terminology for some
local official uses, and not mandatory everywhere (and most languages also
have lot of dialects that may use different orthography to render their own
local phonology and accents: not everyone agree with these prefered form,
even in the same location where dialects are also competing. and let's
remember that all modern language continue to evolve and borrow a lot from
other languages and new terms are creatively added. Finally there are
orthographic reforms, but they take a considerable time to be adopted or
never reah any acceptation and legacy orthographies remain visible in lot
of places and publications (plus, people are much more mobile today and
there are widespread communities located around the world that adapt
constantly to their new context and on which the official reforms have no
impact).

So in conclusion, there's no other choice than Unicode today. Unicode is
mandatory in XML, and in OSM. Don't spak about legacy charsets. But we are
jsut concerned by support in fonts: ALL characters encoded up to Unicode
9.0 have suitable fonts immediately usable, and these fonts are all free
for use, and based on TrueType/OpenType. All OSM rendering softwares should
be able to use TrueType/Opentype fonts. The only remaining problem is the
existence of mobile phones that don't have a lot of embedded fonts and
support a more limited set. But none of them are using or need any legacy
charsets.


Le jeu. 28 nov. 2019 à 15:11, John Whelan  a écrit :

> The way I would approach this professionally would be to define the
> requirements first.
>
> In this case we have a requirement to display the name in the language of
> choice.
>
> We also have a requirement to be compatible with existing software.
>
> Pragmatically I would recommend 

Re: [HOT] OSM Sierra Leone is fundraising!

[Alfred Bockarie]

Hi Tommy, 

I am happy for this initiative. I did  OpenStreetMapping of roads, rooftops, 
health centres, swamps and sectional boundaries of Bo City, Sierra Leone 
between 2012 and 2016. I also did some mapping of the road network in Kenema 
City. 

I hope you have a national mapping plan which I I’m thinking will be really 
useful for researchers, planners and the city councils. 

Best of luck with your fundraising 

Kind regards
Alfred 


Sent from my iPhone

> On 28 Nov 2019, at 12:13, OSM Sierra Leone  wrote:
> 
> Hello
> 
> I'm Tommy Charles a coordinator at Openstreetmap- Sierra Leone which is a 
> registered Non-Governmental Organization in Sierra Leone. We're are engaged 
> in humanitarian mapping with the application of Openstreetmap and other open 
> data collection and visualization techniques. 
> 
> Currently, we are working to revive and expand our mapping community but we 
> lack all the prerequisites to do so. These prerequisites include, a permanent 
> venue to hold mapathons, computers, mobile phones and Internet facilities. 
> 
> Our main goal is to have a community with a strong foundation and structures  
> to execute mapping, community awareness and exposure projects similar to Map 
> Kibera, Open Cities and vulnerability assessments. This will be very 
> essential in a country that experiences disease outbreaks, Landslides and 
> flooding every year 
> 
> Against this backdrop we are seeking funds to procure computers, mobile 
> phones and portable internet sources for mapping, data collection, workshops 
> and other beneficial activities . 
> 
> With these we'll be able  to have a memorandum of understanding with the 
> Geographic Information System- Laboratory at Fourah Bay College in order to 
> use the Laboratory as a permanent location to hold mapathons, workshops and 
> activities of our community. 
> 
> We are kindly pleading for your donations in order to achieve this goal. 
> Please do so by checking out our donation page through the link below where 
> you'll find our donation link. 
> 
> https://www.google.com/url?q=http%3A%2F%2Fbit.ly%2FMTDsierraleone=D=2=AFQjCNGw4IMZjNz6-q54KXhOts1100cuwA
>  
> 
> Our community will appreciate your kind efforts whether big or small to keep 
> it alive and sustainable to continue its humanitarian course.
> 
> Regards 
> Tommy Charles 
> Coordinator 
> ___
> HOT mailing list
> HOT@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/hot
___
HOT mailing list
HOT@openstreetmap.org
https://lists.openstreetmap.org/listinfo/hot

Re: [HOT] Name tag in non-latin script - hindrance for NGOs/aid agencies?

[John Whelan]

The way I would approach this professionally would be to define the 
requirements first.


In this case we have a requirement to display the name in the language 
of choice.


We also have a requirement to be compatible with existing software.

Pragmatically I would recommend changing the name field to use only an 8 
bit Latin alphabet character set recognizing that not all systems can 
handle more complex character sets.  Which precise character set should 
be chosen would a be subject for discussion but either ISO-8859-1 or 
Windows-1252 would be contenders.  My personal preference would be the 
ISO standard.


Unicode is nice but we managed with 6 bit character sets for many years 
when I started with computers.  Even accented characters were a major 
problem.  Also remember that .OSM data is in XML format and XML came out 
of SGML which was first used to transmit documents over modems so only 7 
bits where available for encoding characters.  The extended characters 
use a special escape code sequence to hold the unicode characters.


Realistically software never wears out but source code gets lost. 
Compilers and operating systems get updated.  It may not be possible to 
modify existing software to handle unicode characters.  I have a 
perfectly good scanner sitting in the corner that no long can be used 
with Win 10 because of a new and improved driver.  With the 
OpenStreetMap environment there isn't even a way to get a complete list 
of software that uses the OpenStreetMap data so it can be tested.


The local language can be added in a name:  then software that can 
handle the local names can pick it up.  Osmand etc. can be configured to 
use the local name transparently so the local population can use it in 
the language of their choice.


This approach would appear to meet the requirements.  The argument that 
we should change all the existing software to meet a requirement that 
was not clearly defined when the software was written doesn't make sense 
to me.


Cheerio John

Frederik Ramm wrote on 2019-11-28 3:25 AM:

John,

On 28.11.19 01:40, John Whelan wrote:

Is there any reason why name:en could not be used?

The country's official language requires a "non-standard" font to be
available which does not seem to be a given on all platforms. Like if
you set up a standard tile server and don't install extra fonts you will
see little squares instead of place names all over China.

Apparently not all applications are as good in name:xx handling as
OsmAnd. A recurring point in the discussion is that the proponents of
using the official language say "we shouldn't fall back to English name
tags just because some apps/web sites are broken, we should file bug
reports with them instead", and the proponents of using English say
"let's be pragmatic, there's no way all these apps/sites will be fixed
within a short time, so we should use English".

Bye
Frederik



--
Sent from Postbox 
___
HOT mailing list
HOT@openstreetmap.org
https://lists.openstreetmap.org/listinfo/hot

Re: [HOT] OSM Sierra Leone is fundraising!

[Pete Masters via HOT]

Hi Tommy, thanks for the email. Excited about the project, especially as I
have done some OSM mapping in Sierra Leone with MSF (mapping waterpoints in
Freetown)

For future reference, if people are writing aboiut their microgrants
project, reference the microgrants programme in the email and use the
official donately link - https://pages.donately.com/hotosm/campaigns/ -
just in case people think it might be a phishing email, which obviously
this is not!

Good luck with the campaign!!

Pete

On Thu, Nov 28, 2019 at 12:16 PM OSM Sierra Leone 
wrote:

> Hello
>
> I'm Tommy Charles a coordinator at Openstreetmap- Sierra Leone which is a
> registered Non-Governmental Organization in Sierra Leone. We're are engaged
> in humanitarian mapping with the application of Openstreetmap and other
> open data collection and visualization techniques.
>
> Currently, we are working to revive and expand our mapping community but
> we lack all the prerequisites to do so. These prerequisites include, a
> permanent venue to hold mapathons, computers, mobile phones and Internet
> facilities.
>
> Our main goal is to have a community with a strong foundation and
> structures  to execute mapping, community awareness and exposure projects
> similar to Map Kibera, Open Cities and vulnerability assessments. This will
> be very essential in a country that experiences disease outbreaks,
> Landslides and flooding every year
>
> Against this backdrop we are seeking funds to procure computers, mobile
> phones and portable internet sources for mapping, data collection,
> workshops and other beneficial activities .
>
> With these we'll be able  to have a memorandum of understanding with the
> Geographic Information System- Laboratory at Fourah Bay College in order to
> use the Laboratory as a permanent location to hold mapathons, workshops and
> activities of our community.
>
> We are kindly pleading for your donations in order to achieve this goal.
> Please do so by checking out our donation page through the link below where
> you'll find our donation link.
>
>
> https://www.google.com/url?q=http%3A%2F%2Fbit.ly%2FMTDsierraleone=D=2=AFQjCNGw4IMZjNz6-q54KXhOts1100cuwA
>
>
> Our community will appreciate your kind efforts whether big or small to
> keep it alive and sustainable to continue its humanitarian course.
>
> Regards
> Tommy Charles
> Coordinator
> ___
> HOT mailing list
> HOT@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/hot
>
___
HOT mailing list
HOT@openstreetmap.org
https://lists.openstreetmap.org/listinfo/hot

Re: [HOT] Name tag in non-latin script - hindrance for NGOs/aid agencies?

[Frederik Ramm]

John,

On 28.11.19 01:40, John Whelan wrote:
> Is there any reason why name:en could not be used?

The country's official language requires a "non-standard" font to be
available which does not seem to be a given on all platforms. Like if
you set up a standard tile server and don't install extra fonts you will
see little squares instead of place names all over China.

Apparently not all applications are as good in name:xx handling as
OsmAnd. A recurring point in the discussion is that the proponents of
using the official language say "we shouldn't fall back to English name
tags just because some apps/web sites are broken, we should file bug
reports with them instead", and the proponents of using English say
"let's be pragmatic, there's no way all these apps/sites will be fixed
within a short time, so we should use English".

Bye
Frederik

-- 
Frederik Ramm  ##  eMail frede...@remote.org  ##  N49°00'09" E008°23'33"

___
HOT mailing list
HOT@openstreetmap.org
https://lists.openstreetmap.org/listinfo/hot