How to prevent from wrecking havoc

Hi,

I came across one contributor converting text-entries done with truly, fully compliant to Unicode standard font for my language ( same as for English language font I use and you use to read and write ) to non-compliant Unicode font, a private font.
I advised him to undo it and avoid doing it again and I appreciated his contributions for others by sending internal message to him.
The same was briefly mentioned to LaurentS ( seem to be an adminstrator ) in my reply regards to his visit to my country.
A day later, I found out my message to that contributor and reply message were deleted by someone who can do it.

Can someone guide me to how to undo the damage done by that contributor ?

A link to some - http://www.openstreetmap.org/changeset/40267375

Thank you.

First step, is to start discussing the problem via the changeset comments. In case you cannot settle the dispute, you can contact the DWR. Chances are that someone from the DWR will read your post soon (SomeoneElse reads this forum and is a DWR member) and advice you.

See https://wiki.osmfoundation.org/wiki/Data_Working_Group#Contact on how you can contact them. But please first try to settle it with the other mapper yourself. Give the other mapper enough time to respond, not everybody reads his/her email daily.

Hi (sorry I can’t use your name - it doesn’t display on an English Windows 7 here),

The first thing to do is to explain the problem to the person who’s making the changes, and as @escada suggests doing that via a changeset discussion comment is probably the best way to do that. Looking at your example http://www.openstreetmap.org/changeset/40267375 though, that seems to be just adding a building and changing a road from primary to trunk (see http://osm.mapki.com/history/way.php?id=245437694 ), so I’d make the comment on one of the changeset discussions that actually are a problem.

You’ll need to explain not just that it is a problem, but also explain to them why, since they won’t be aware of that (otherwise they wouldn’t be doing it). Maybe something on http://www.myanmarlanguage.org/unicode/zawgyi-unicode-conversions-tips-tricks-and-risks will help? Also perhaps http://www.myanmarlanguage.org/project/google-myanmar-language . Also, as well as explaining to them why it makes sense to use Unicode rather than Zawgyi, you’ll need to listen to their explanation of why they’re changing names into Zawgyi from Unicode to understand their point of view.

If you don’t get a satisfactory response, then you can contact the Data Working Group by email via data@osmfoundation.org , and explain the problem there.

(edit: spelling, another example)

Hi Guys,

Thanks for the advices.
For SomeoneElse - Windows integrated Burmese standard font from ver Windows 8, though one can use it on Windows 2000 onwards with their own ways.

( my mistake, I didn’t look at my Outbox and my messages are there. Hopefully, he’ll act it as he is a contributor since 2013. I am certain he knows he is doing it wrong about that particularly.)

Have a good day.

The offending change set was probably https://www.openstreetmap.org/changeset/40211422. JOSM shows a change in the name tag there, although I don’t see it displayed properly, either.

Taking a random sample from that changeset, https://www.openstreetmap.org/way/106358078 the characters of the name, ၿမိဳင္သာယာလမ္း are in the Unicode Myanmar range, so that one appears to be coded correctly. If that changeset is right, maybe the problem is actually that the originals were miscoded to work with a deliberately miscoded font, a common trick in Asian countries before Unicode became commonplace.

In this particular case the original was partial English, rather than an attempt to code Myanmar fonts differently. By partial English, I mean that “Road” was in English and the rest was a transliteration. If there is any evidence for this usage, it should have been retained as name:en.

The current name here starts:

If this is the changeset, it seems likely that it is correctly a previous character coding abuse rather than creating one.

In terms of the named item included in the changeset referenced in the original posting, there doesn’t seem to have been a change in the Myanmar form since it first got a name in http://www.openstreetmap.org/api/0.6/way/245437694/9 The only change seems to be the splitting of Myanmar and English forms. I’d have to see the actual road signs to see if I agreed with that. If the road signs give both forms, name should probably contain both, with the split only occurring in name:en and name:my.

Hi hardw,

I don’t know much about tagging name en. Your မြိုင်သာယာလမ်း is correct.
That non-compliant font he used, is a hacked Microsoft’s Arial font ( without permission ) and places some characters in more 1 code point, in places for characters of other languages in Myanmar Unicode Range.( a bully or stolen one )

He changed those good ones and did new ones with wrong font.
His recent entry, a few hours ago, http://www.openstreetmap.org/changeset/41564599 and he is not responding to my mail.

So, i’ll approach DWR data@osmfoundation.org

I’ve now installed a sil-padauk font on Debian and am no longer just seeing boxes with hex. The name in your first example has definitely been broken, but the damage was done in http://www.openstreetmap.org/changeset/40211422 not in the changeset you referenced. It is still the same person that did it. Really it is that changeset which should receive the changeset comments.

The name on http://www.openstreetmap.org/way/245437694 has been changed from “မြို့ရှောင်လမ်း” to “ၿမိဳ႕ေရွာင္လမ္း”.

Even just on the basis of a basic understanding of how Indic scripts work, that is clearly wrong, as it is rendering with an isolated vowel sign (U+1033 MYANMAR VOWEL SIGN MON II) “ဳ” (I see a dotted circle, but that isn’t a base character, but rather a place holder for a missing one. For those not familiar with such scripts, there are generally two types of vowel marker, an isolated form, and a diacritical form. Most characters have an implied vowel, and the diacritical overrides this. It looks almost as though two conflicting vowel marks have been applied in this case, and the Debian renderer, at least, is applying the the first, but resorting to the place holder type fall-back for the second.

What they have coded here is, base character ma (presumably m, with an implied a vowel, then modified the the vowel to i, which is OK, and further modified it to “mon ii” (presumably a variant of a long vowel), which makes no sense at all.

There is a similar defect and place holder later in the name.

The renderer on Mapnik seems to have suppressed this particular vowel mark, but there is an obvious change in the name, as compared with the original, as can be seen on this tile: http://b.tile.openstreetmap.org/19/404324/237779.png Unless the original name was completely wrong, it should be obvious, even to the person who made the change, that they have made an incorrect change.

In terms of the hacked Microsoft font, this is really about the wrong font encoding, rather than the wrong font, but there is probably only one font with this broken encoding. It looks like someone has been mapping for the font!

Rather than private mail, I would suggest adding changeset comments, but make sure you get the changeset that actually made the change.