[Talk-ko] Fixing laguage-mixed name tag in Korean region

[느림보]

FYI,

공공 용어의 영어 번역 및 표기 지침 (English translation and marking instructions for
public terms) was published by 문화체육관광부 (Ministry of Culture, Sports and
Tourism).

Reference: http://www.law.go.kr/LSW/admRulLsInfoP.do?admRulSeq=2100000035680

문화재명칭 영문표기 기준 규칙 (English marking instruction of culture properties) was
published by 문화재청 (Culture Heritage Administration).

Reference: http://www.law.go.kr/admRulLsInfoP.do?admRulSeq=2100000005900



I updated instructions into Google Drive because they were saved as HWP
files. (A file-type for a commercial word processor), but I replaced then
into web pages because I found alternates

2017-03-05 17:57 GMT+09:00 Changwoo Ryu <cwryu at debian.org>:

> The name tag is for local default name (data), not exactly for
> preferred label form (visibility).
>
> Like other people have said, we can't just choose the name tag
> convention based on rendering preference. Leave the job to the map
> renderers.
>
> 2017-03-05 17:00 GMT+09:00 최규성 <kyusung.choi at gmail.com>:
> >
> > References are the posts by Yongmin, Nrimbo, Andrew Errington and Robert
> > Helvie.
> >
> > I'm very interested in this dialog thinking it important. However, it
> makes
> > me confused on what the point is. To me, the points are coming as
> > 1) How to Romanize Korean tags
> > 2) Labeling convention for place names (or name field).
> >
> > If the above is correct, let me suggest my opinion as follows.
> >
> > 1. How to Romanize Korean Tags
> >
> > Regarding this issue, there is an agreed practice in Korea. Korean
> > government has led the standardization that should be officially applied
> to
> > road signs, national basemaps, etc. The Romanization standard is
> established
> > by National Institute of Korean Language (NIKL), which is found as below:
> >> [In Korean] -
> >> https://www.korean.go.kr/front/page/pageView.do?page_
> id=P000148&mn_id=99
> >> [In English] - https://www.korean.go.kr/front_eng/roman/roman_01.do
> >
> > (Nrimbo's Google Drive document seems to be consistent with this though
> lack
> > of source referral.)
> >
> > For use with mapping, a practical guideline is prepared by National
> > Geographic Information Institute (NGII), the national mapping agency of
> > Korea. It is well documented as linked below.
> >> Toponymic guidelines for map and other editors for international use:
> > https://www.dropbox.com/s/hxngjd18jtbsm1q/Toponymy_Guidelines.pdf?dl=0
> >
> > According to this, we can decide whether we have to choose 'Daehak-ro' or
> > 'University street'. My answer is 'Daehak-ro'.
> >
> > Here is one interesting online map service that exemplarily shows the
> > Romanized names. It is a Road Name Address Information System service by
> > Korean government - http://m1.juso.go.kr/eng/standardmap/MapIndex.do .
> Here,
> > we can identify how "Daehak-ro" and other street names are labelled.
> >
> > But, I have a concern on how we make the awareness sure to every OSM
> mapper
> > of this standardized Romanization practice.
> >
> > 2. Labeling convention for place names (or name field)
> >
> > I strongly support the idea of labelling the name by Korean and English
> > combination.
> >
> > As a result, it is against the idea of Yongmin. If OSM was designed only
> for
> > Koreans and by Koreans, it would have been agreeable. But, as many of us
> > would agree, OSM is designed as a global map for everyone in the world.
> The
> > map of Italy region is also lack of something. The Korean who can't
> > understand Italian (like me) becomes illiterate when I see it, which
> needs
> > to be improved. In this regard, I evaluate that OSM labeling style for
> Korea
> > region is more advanced than that for Italy.
> >
> > But, I have additional request of modifying the current style. My
> suggestion
> > is to separate Korean\English by line breaker AND to remove the
> parentheses
> > (round brackets). The parenthesis is useless.
> >
> > We can find best practices in the global map services like ArcGIS Online
> Map
> > or Google Maps.
> >
> > The example of ArcGIS Online map is linked here -
> > https://www.dropbox.com/s/vslwnpyhixw1off/Ex_agol.jpg?dl=0
> >
> > This shows like this ---
> >   강남역
> >   Gangnam Station
> >
> > In Google Maps, separate languages are labelled in two lines one by one
> > WITHOUT parentheses.
> >
> > I hope this would help to resolve the issue. If I missed any other
> arguing
> > points, please advise me.
> >
> > Best regards,
> >
> >
> > Kyu-sung Choi
> >
> > 2017-03-05 15:14 GMT+09:00 <talk-ko-request at openstreetmap.org>:
> >>
> >> Send Talk-ko mailing list submissions to
> >>         talk-ko at openstreetmap.org
> >>
> >> To subscribe or unsubscribe via the World Wide Web, visit
> >>         https://lists.openstreetmap.org/listinfo/talk-ko
> >> or, via email, send a message with subject or body 'help' to
> >>         talk-ko-request at openstreetmap.org
> >>
> >> You can reach the person managing the list at
> >>         talk-ko-owner at openstreetmap.org
> >>
> >> When replying, please edit your Subject line so it is more specific
> >> than "Re: Contents of Talk-ko digest..."
> >>
> >> Today's Topics:
> >>
> >>    1. Re: Fixing laguage-mixed name tag in Korean region (Yongmin H.)
> >>    2. Re: Fixing laguage-mixed name tag in Korean region (느림보)
> >>
> >>
> >> ---------- 전달된 메시지 ----------
> >> From: "Yongmin H." <lists at revi.pe.kr>
> >> To: OpenStreetMap Korea <talk-ko at openstreetmap.org>
> >> Cc:
> >> Bcc:
> >> Date: Sun, 5 Mar 2017 00:10:39 +0900
> >> Subject: Re: [Talk-ko] Fixing laguage-mixed name tag in Korean region
> >> I don't agree with this. When I see the Milan, Italy's map, I expect
> >> things to have name = value in Italian, not Italian(English). (And it is
> >> done that way[1].) It shouldn't be different just because it is Korea.
> If
> >> renderer doesn't show the name correctly in their given set
> language(say,
> >> English), that's renderer's fault, not the data's fault.
> >>
> >> [1]: https://osm.org/go/0CjFi4mPI-
> >>
> >> --
> >> Yongmin
> >>
> >> Sent from my iPhone
> >> https://wp.revi.blog
> >> Please note that this address is list-only address and any non-mailing
> >> list mails will be treated as spam.
> >> Please use https://encrypt.to/0x947f156f16250de39788c3c35b62
> 5da5beff197a.
> >>
> >> 2017. 3. 4. 17:39 Andrew Errington <erringtona at gmail.com> 작성:
> >>
> >> I agree that if name=* is a combination of "Korean (English)" it should
> be
> >> changed, but as an English speaker living in Korea it is very useful
> for me,
> >> so I am reluctant to make that change.  And if it's useful for me, it is
> >> probably useful for other people.
> >>
> >> This brings me to another important point, we must think of the people
> who
> >> will be using the data.  We must provide data which is properly tagged
> so
> >> that the map renderer can choose the correct tag to label every road or
> >> street or building for the language chosen by the user.  I think the
> reason
> >> why name=* was a combination of "Korean (English)" was because we didn't
> >> have renderers that could render in different languages.  Maybe we still
> >> don't, but we should be thinking of the future, as well as the present.
> >>
> >>
> >>
> >> ---------- 전달된 메시지 ----------
> >> From: "느림보" <nrimbo at gmail.com>
> >> To: OpenStreetMap Korea <talk-ko at openstreetmap.org>
> >> Cc:
> >> Bcc:
> >> Date: Sun, 5 Mar 2017 15:14:04 +0900
> >> Subject: Re: [Talk-ko] Fixing laguage-mixed name tag in Korean region
> >>
> >> Max wrote:
> >>
> >>> 2. Many POIs in Korea are outdated and not valid any more. In the
> >>> problematic import, there are all kinds of hospitals and clinics that
> are
> >>> closed by now. Editing those would "mark them like new" and it would
> not be
> >>> visible immedately that they might not be valid any more
> >>
> >>
> >> Don’t agree. First, age or last modified time of a POI don’t represent
> >> correctness of the POI. Second, if the importing was problematic, then
> we
> >> should revert the problematic importing rather than keep them without
> >> modification.
> >>
> >>
> >>
> >> No common renderer “mark them like new” or marks POI as maybe-incorrect
> >> base on their age or last modified time. It is information behind map.
> As
> >> well as, normal user want to know point-of-interest, not history of
> >> point-of-interest. Even an expert user want to see history, but he/she
> can
> >> immediate identify the last change is mechanical renaming because there
> must
> >> be a comment.
> >>
> >>
> >>
> >> As a mapper, I modified POIs because I knew information of the POIs were
> >> incorrect. Latest confirmed date(?) or something like that can be
> useful for
> >> users, however it must exist as a separate information if needed. We
> cannot
> >> know such information from history of POI itself and should not.
> >>
> >>
> >> 2017-03-04 21:54 GMT+09:00 느림보 <nrimbo at gmail.com>:
> >>>
> >>> You are right. For the name of roads in South Korea, Romanization has
> >>> precedence over translation. It is defined in 공공 용어의 영어 번역 및 표기 지침
> (English
> >>> translation and marking instructions of public terms,
> >>> https://drive.google.com/file/d/0B-H3vA9-nLFkQWNLYjJsN00tRG8/view?usp=
> sharing).
> >>>
> >>>
> >>>
> >>> Korean Government adopted street-based address. For proper working as
> >>> Address, there should be minimum differences between written forms and
> it
> >>> should be easy to convert between them. If translation of road name is
> >>> allowed, it will hurt address system of South Korea, because there can
> be
> >>> lots of alternatives for translation.
> >>>
> >>>
> >>>
> >>> Translation vs. Romanization -- they should be made case-by-case, but
> for
> >>> the name of road, I think proper one is Romanization. ‘name:en’ can
> exist
> >>> but it should has the same value as ‘name:ko_rm.’
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>> 2017-03-04 21:16 GMT+09:00 Robert Helvie <alimamo at gmail.com>:
> >>>>
> >>>> The ideas here are good, but I have a problem with the idea that the
> >>>> Korean names "should" be translated.
> >>>>
> >>>> I have come across numerous examples where a street name COULD be
> >>>> translated, for example something like "대학로" could be translated to
> >>>> "University street"; however, the English on the actual street sign
> is not
> >>>> translated and says "Daehak-ro".
> >>>> In a situation like this, shouldn't the name:en tag still exist and be
> >>>> "Daehak-ro"? In this case, the name:ko_rm=romanized would be the
> same, but
> >>>> certainly not in all cases.
> >>>>
> >>>> There is at least one service I know of that uses the name:en tag to
> >>>> create maps using OSM data. And, I expect future renderers will need
> to
> >>>> access specific language tags when things get to the point where you
> can
> >>>> choose a language and have the map rendered on the fly in your
> language.
> >>>>
> >>>> If you just start translating all street names and POI names, then
> >>>> anyone using an English rendered map to find places in Korea is going
> to
> >>>> have a pretty hard time unless they speak Korean. Sure, it will
> obviously
> >>>> take time to get the actual signage into OSM, but I think that route
> is
> >>>> better than just translating things and entering a lot of
> unrepresentative
> >>>> data.
> >>>>
> >>>> Robert
> >>>>
> >>>> "We should give meaning to life, not wait for life to
> >>>> give us meaning. "
> >>>> ~ unknown
> >>>> ---
> >>>>
> >>>> On Sat, Mar 4, 2017 at 8:45 PM, 느림보 <nrimbo at gmail.com> wrote:
> >>>>>
> >>>>> It might be useful for foreigners to have combination name as 한국어
> >>>>> (English). However, as a local mapper I don’t want see (English)
> because
> >>>>> they don’t give additional information to Korean people, as well as
> they
> >>>>> block displaying of other POIs by taking additional space. To make
> matters
> >>>>> worse, English name is longer than original Korean name, generally.
> >>>>>
> >>>>>
> >>>>>
> >>>>> Andrew said that “…as an English speaker living in Korea it is very
> >>>>> useful for me…”. So, I looked after several online services and
> OsmAnd to
> >>>>> see how they looks. In most cases, they are using local name (name
> tag)
> >>>>> only. MapQuest prefer English than local name and OsmAnd has function
> >>>>> override language, but they don’t give two languages, too.
> >>>>>
> >>>>>
> >>>>>
> >>>>> I also found two sites displaying two languages (Max already
> introduced
> >>>>> one of them.) They display Korean name and ‘foreign name’
> line-by-line. For
> >>>>> me, it is more readable than wrapping English name by parenthesis
> and looks
> >>>>> like more proper way handling name tags.
> >>>>>
> >>>>>
> >>>>> https://www.openstreetmap.de/karte.html?zoom=10&lat=49.
> 99303&lon=18.83157&layers=B000TT
> >>>>>
> >>>>>
> >>>>> http://maps.sputnik.ru/?lat=37.536410466671626&lng=127.
> 00847625732423&zoom=12
> >>>>>
> >>>>>
> >>>>>>
> >>>>>> name=한국어 and name:ko=한국어 are kind of redudnant, but it is probably
> >>>>>> neccessary to help transitioning. Also it is the same way in Japan.
> >>>>>
> >>>>>
> >>>>> Agree, I hesitated making duplicated data at the first time but I
> >>>>> accepted this rule for that reason. It looks like that it is accepted
> >>>>> globally. More than half of 20 busiest airports have duplicated name
> tags.
> >>>>>
> >>>>>
> >>>>>>
> >>>>>> ko_rm should actually be renamed in bulk to ko-Latn, possibly in
> >>>>>> cooperation and discussion with the japanese community who have the
> same
> >>>>>> problem with ja_rm that should be ja-Latn
> >>>>>>
> >>>>>> See here: https://wiki.openstreetmap.org/wiki/Names#Localization
> >>>>>> the next paragraph in this wiki page is interesting too. We should
> >>>>>> avoid transliterations. According to this rule 90% of the
> name:ko_rm and
> >>>>>> name:en tags should go.
> >>>>>
> >>>>>
> >>>>> I think Romanized name is useful when the name doesn’t have meaning
> >>>>> part. If a name doesn’t have meaning part, then there will be no
> proper
> >>>>> translated name, too. In this case, only ko-Latn tag (or ko_rm) holds
> >>>>> foreigner friendly characters properly. In this reason, I don’t
> hesitate to
> >>>>> add ko-Latn to administrative units. However, I think Romanization
> should be
> >>>>> avoided if a name has meaning part. (I already expressed my opinion
> in
> >>>>> previous thread, but again…)
> >>>>>
> >>>>> 1)     Romanization of Korean is not simple transliteration. It is
> >>>>> difficult to guarantee correctness of Romanized name. First
> principle of
> >>>>> Romanization is “Romanization is based on standard Korean
> pronunciation.”
> >>>>> Finding proper pronunciation of Korean words is difficult job even
> native
> >>>>> Koreans. As well as, “Proper names such as personal names and those
> of
> >>>>> companies may continue to be written as they have been previously.”
> Only
> >>>>> owner of the property can give proper Romanized name.
> >>>>> See http://www.korean.go.kr/front_eng/roman/roman_01.do
> >>>>>
> >>>>> 2)     Even it is my personal experiment, translated name is readable
> >>>>> than Romanized name. I think it is better to encourage translate
> rather than
> >>>>> Romanize.
> >>>>>
> >>>>>
> >>>>> 2017-03-04 18:09 GMT+09:00 Max <abonnements at revolwear.com>:
> >>>>>>
> >>>>>> On 2017년 03월 04일 09:39, Andrew Errington wrote:
> >>>>>>>
> >>>>>>> I agree that name tagging should be fixed, but I don't agree that
> we
> >>>>>>> have a solution yet.
> >>>>>>
> >>>>>> Indeed
> >>>>>>
> >>>>>>> Firstly, name=* might not be in Korean language.  I can give
> several
> >>>>>>> examples where the name of something in Korea (for example, a shop,
> >>>>>>> or a
> >>>>>>> restaurant) is in Chinese, English, or French.  So, I think we
> should
> >>>>>>> not insist that name=* must always be Korean.
> >>>>>>
> >>>>>> Very good point.
> >>>>>>
> >>>>>>> However, it is useful to make a record of the Korean name in
> >>>>>>> name:ko=*
> >>>>>>> even if it is the same as name=*.  The reason for this is so that
> we
> >>>>>>> can
> >>>>>>> make a multilingual map.
> >>>>>>
> >>>>>> Agreed
> >>>>>>
> >>>>>>> I agree that if name=* is a combination of "Korean (English)" it
> >>>>>>> should
> >>>>>>> be changed, but as an English speaker living in Korea it is very
> >>>>>>> useful
> >>>>>>> for me, so I am reluctant to make that change.  And if it's useful
> >>>>>>> for
> >>>>>>> me, it is probably useful for other people.
> >>>>>>
> >>>>>> While I generally sympathize, I think this is a bit of an
> colonialzing
> >>>>>> view onto Korea. Hell would break loose if someone would think it's
> >>>>>> appropriate to tag every item in the states with Korean or Arabic
> >>>>>> transcriptions.
> >>>>>>
> >>>>>>> This brings me to another important point, we must think of the
> >>>>>>> people
> >>>>>>> who will be using the data.  We must provide data which is properly
> >>>>>>> tagged so that the map renderer can choose the correct tag to label
> >>>>>>> every road or street or building for the language chosen by the
> user.
> >>>>>>> I
> >>>>>>> think the reason why name=* was a combination of "Korean (English)"
> >>>>>>> was
> >>>>>>> because we didn't have renderers that could render in different
> >>>>>>> languages.  Maybe we still don't, but we should be thinking of the
> >>>>>>> future, as well as the present.
> >>>>>>
> >>>>>> That's very true. I hope these multilingual renderers will appear
> >>>>>> soon, so we have one less reason to slow down the transition.
> >>>>>> Maybe an intermediate solution would be to have a Korean render
> style?
> >>>>>> openstreetmap.kr ? just like the german style at
> >>>>>> https://www.openstreetmap.de/karte.html
> >>>>>>
> >>>>>>> I think we have to have a full discussion before you run your
> >>>>>>> automated
> >>>>>>> script.  We should also remember that there is no urgency, and we
> >>>>>>> should
> >>>>>>> not be hasty.
> >>>>>>
> >>>>>>
> >>>>>> _______________________________________________
> >>>>>> Talk-ko mailing list
> >>>>>> Talk-ko at openstreetmap.org
> >>>>>> https://lists.openstreetmap.org/listinfo/talk-ko
> >>>>>
> >>>>>
> >>>>>
> >>>>> _______________________________________________
> >>>>> Talk-ko mailing list
> >>>>> Talk-ko at openstreetmap.org
> >>>>> https://lists.openstreetmap.org/listinfo/talk-ko
> >>>>>
> >>>>
> >>>>
> >>>> _______________________________________________
> >>>> Talk-ko mailing list
> >>>> Talk-ko at openstreetmap.org
> >>>> https://lists.openstreetmap.org/listinfo/talk-ko
> >>>>
> >>>
> >>
> >>
> >> _______________________________________________
> >> Talk-ko mailing list
> >> Talk-ko at openstreetmap.org
> >> https://lists.openstreetmap.org/listinfo/talk-ko
> >>
> >
> >
> > _______________________________________________
> > Talk-ko mailing list
> > Talk-ko at openstreetmap.org
> > https://lists.openstreetmap.org/listinfo/talk-ko
> >
>
> _______________________________________________
> Talk-ko mailing list
> Talk-ko at openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-ko
>
-------------- next part --------------
HTML 첨부를 없애버렸습니다...
URL: <http://lists.openstreetmap.org/pipermail/talk-ko/attachments/20170305/22a370c1/attachment-0001.html>