Skip to content
This repository has been archived by the owner on Mar 22, 2023. It is now read-only.

번역 가이드라인 #7

Closed
taggon opened this issue Feb 9, 2015 · 16 comments
Closed

번역 가이드라인 #7

taggon opened this issue Feb 9, 2015 · 16 comments

Comments

@taggon
Copy link
Contributor

taggon commented Feb 9, 2015

#3 에서 나누었습니다.

전체 또는 대부분이 동의한 내용은 다음과 같습니다.

  • 번역 리뷰는 대체로 하는 쪽으로 의견을 주었습니다.
  • 번역할 글에는 translation 레이블을 붙여 이슈로 등록하면
    • 내부에서 번역할 때는 자신에게 할당한 후 진행합니다.
    • 외부에서는 번역 후 Pull Request를 요청하면 됩니다.
    • 이슈로 등록할 때 글 제목은 이슈 제목으로 글 링크는 이슈 본문으로 적습니다.
  • 번역이 완료되면 in review 레이블을 붙여 리뷰를 진행합니다.
    • Pull Request로 받은 번역문은 로컬 브랜치에서 리뷰 후 master 브랜치에 머지합니다.

이 분류에 남은 의제는 다음과 같습니다.

  1. 번역자와 리뷰어의 크레딧은?
    1. 필요없다.
    2. 항상 글 말미에 둔다.
    3. Medium 글에만 말미에 표시하고 GitHub에는 별도로 표시하지 않는다.
  2. 마감 시한은?
    1. 필요없다.
    2. 1주
    3. 2주 이상
    4. 글의 종류에 따라 다르게 설정한다.
@hibiyasleep
Copy link
Contributor

  1. 3; GitHub에선 contributor를 확인하면 됩니다
  2. 4; 기본 1주일로 설정하고, 특별히 긴 글 같은 경우에 2주로 설정하면 좋을 것 같습니다.

@xarus01
Copy link
Contributor

xarus01 commented Feb 9, 2015

  1. (iii) Github은 크레딧이 따로 필요 없을 것 같네요. Medium에만 표시하는것이 좋겠습니다.
  2. (iv) 1주 이상 늘어지면 번역 자체가 힘들 수 있다는것이 제 생각입니다. 하지만 @hibiyasleep님 말씀대로 긴 글이 있을 수 있다는 점을 고려하지 못했네요.

@outsideris
Copy link
Contributor

저도 Github에서는 크레딧이 필요없고 Medium에 올릴때 표시하는 쪽에 동의합니다.
마감시한은 전 없어도 될것 같긴 한데 관리차원에서 있는걸 반대하진 않습니다.

위 라벨 얘기가 있어서 생각난건데 저장소들 보면 need help같은 라벨이 있으면 프로젝트를 평상시 보고있지 않아도 이슈를 처리해볼까라는 생각이 들게 되더라구요. translation이 그 의도이신것 같긴 한데 외부에서 참여는 어떻게 진행되고있는지 모르니까 좀더 명확한 표시가 있으면 참여하기가 좋은것 같아서요.

@nundefined
Copy link

  1. 크레딧: iii
  2. 마감시한: iv. 번역에 걸리는 시간이 글마다 다를 것 같다는 생각이어서 개별적으로 정하면 될 것 같아요.

@xarus01
Copy link
Contributor

xarus01 commented Feb 10, 2015

@outsideris html5rocks에서는 라벨로 토픽을 나누려고 했었는데 잘 안되었어요. 라벨로 급한(기한이 많이 된) 것을 표시하는것도 좋은 방법일것 같네요.

@outsideris
Copy link
Contributor

#16 보다보니 번역문을 평문으로 할지 존대말로 할지도 정해야 할것 같습니다. 저는 보통 평문(반말?)로 적는 편인데 사람마다 다르면 좀 어색할것 같아서요.

@yous
Copy link
Contributor

yous commented Feb 11, 2015

Medium의 글을 보니까 링크 자체에도 굵은 글씨를 사용하거나, 일부 단어만 굵게 만들어둔 경우도 있는데, 이런 것도 최대한 옮기는 것이 나을까요? 가령, State of io.js에는 이런 문장이 있습니다.

Domenic Denicola has also been invited to the TC meetings as a non-voting participant (like myself and Rod Vagg) which has opened up collaboration with v8 and TC39.

@outsideris
Copy link
Contributor

개인적으로는 특별한 이유가 있지 않으면 강조라고 생각해서 따르는 편이긴 합니다.(물론 문장에 따라서는 영어랑 한국어랑 강조단어가 달라지는 경우도 있긴 합니다만...)

@nundefined
Copy link

번역 가이드라인을 공개할 때
리뷰 요청 전에 맞춤법 검사기를 사용하는 것에 대해서도 언급하면 어떨까요..?
http://speller.cs.pusan.ac.kr/

외국어가 많아 검사 결과를 모두 반영할 수는 없겠지만
띄어 쓰기와 같은 부분은 많이 걸러줄 수 있겠다는 생각이 듭니다.

@outsideris
Copy link
Contributor

맞춤법검사는 저는 보통 한번씩 돌려주는데 리뷰때 맞춤법까지 검증하는게 쉽지 않으므로 가이드라인에 추가하면 좋을것 같아요.

@outsideris
Copy link
Contributor

jp 쪽은 주석으로 원문을 추가하는 방식을 사용하더라구요. 리뷰나 나중에 수정할 때도 본문이 함께 있으면 좋은것 같아서 참고할만 해 보입니다.

@marocchino
Copy link
Contributor

일회성 글이라 원문이 갱신되지 않으면 상관없는데.. 갱신되는 문서는 저렇게 해두면, 나중에 관리하기 더 힘들어 질것 같아요.

@outsideris
Copy link
Contributor

저는 오히려 갱신되는 문서면 저렇게 할 경우 원문도 갱신하면 바로 diff 볼 수 있어서 유용하다고 생각하는 편인데요. git으로 자체 관리가 되면 더 좋지만 그렇지 않은 경우는 번역문이 어떤 버전의 원문으로 번역했는지 모르면 전체를 다시 볼수 밖에 없어서요.

@marocchino
Copy link
Contributor

아 저도 git으로 관리된다는 전제하에서 하는 이야기였어요.

@taggon
Copy link
Contributor Author

taggon commented Feb 12, 2015

저도 원문 추가에 👍 보탭니다. :)

@taggon
Copy link
Contributor Author

taggon commented Feb 14, 2015

지금까지 나온 내용을 바탕으로 번역 가이드라인 초안을 작성해보았습니다. 보시고 의견부탁드립니다. 현재 이슈는 닫겠습니다.

@taggon taggon closed this as completed Feb 14, 2015
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

7 participants