[Next.js 번역 프로젝트] 번역 작업하기 - 과정 후기

번역한 파트

• BuildingYourApplicaton / Optimizing / Index (메인 화면)  ->  번역본
• BuildingYourApplicaton / Optimizing / Fonts  ->  번역본
• BuildingYourApplicaton / Optimizing / Images  ->  번역본
• BuildingYourApplicaton / Optimizing / Metadata  ->  번역본
• BuildingYourApplicaton / Optimizing / Scripts  ->  번역본

Optimizing: Scripts | Next.js

 

---

 

되돌아보며

 

나의 최종 PR이 merge되면서 설레는 마음으로 시작했던

Next.js 13 정식 문서 번역 오픈소스 기여 프로젝트는 끝이 났다.

 

 

처음 정말 오픈소스 기여 방법, git 사용법, 문서 번역 컨벤션 등 지금 되돌아보면 아무 것도 모르는 상태에서 

"Nextjs 13 프로젝트" 스터디가 열리자마자 호기롭게 신청했던 과거의 나를.. 음... 칭찬한다. 

 

스터디에 막 가입해서 스터디장님의 공지를 읽었을 때, 이해가 안 가서 2~3번 계속 읽었던 기억이 난다. (아래는 문제의 내용)

 

 

뭐가 됐든 중요한 것은, 별일없이 후련하게 PR을 날리고

아.아.와 함께 후기글을 쓰고 있다는 것이다.

 

 

 

컨트리뷰터 목록 (왼쪽에서 두 번째 💕)

 

 

배운 것들

 

1. 오픈 소스 기여 과정

• 관련 포스팅
• 번역 프로젝트를 처음 시작하게 되면서, 그와 관련된 확실한(그리고 세세한) 컨벤션이 있어야 한다는 것을 알게 되었다.
• 간단하게 예를 들면,
  • 공식 문서에 포함되어 있는 이미지는 반드시 첨부한다.
  • 이미지는 자신이 작업하고 있는 문서 이름으로 문서와 동일한 깊이에서 폴더를 생성한다.
  • 폴더 이름은 작업하는 문서 + Images 로 통일한다.
  • 번역을 마치면 맞춤법 검사를 한다.
• 이런 전체적인 흐름에 대해 처음부터 끝까지 참여할 수 있었던 소중한 시간이었다.

[Next.js 번역 프로젝트] 오픈소스 기여한 과정 (단계)

 

2. 깃 사용법

• 관련 포스팅
• 깃에 대해 안개가 낀 것처럼 막연한 느낌이 있었는데, 이번 프로젝트를 하면서 어느 정도 개념이 잡힌 것 같다.
• 특히 구글링을 해보면 upstream/main, upstream main, upstream 등 포스팅마다 레포지토리와 브랜치 컨벤션이 다른 식으로  적혀있어서 정말 헷갈렸는데 직접 해보며 헷갈리는 부분에 대해 확실하게 알고 넘어갈 수 있게 되었다.
• 브랜치 최신화 개념과 작업 브랜치를 나눠서 PR을 날리는 방식은 이번 프로젝트에서 처음 접했기에 할 때는 막막한 느낌이었지만, 다른 프로젝트를 시작하게 되었을 때 능숙하게 작업할 수 있었다.

'git merge upstream main' #(===git merge upstream/main  === git merge upstream upstream/main)

 

[Next.js 번역 프로젝트] pull을 통한 브랜치 최신화

 

3. 마크다운

• 마크다운에 대한 부분은 이 블로그에서 많은 도움을 받았다. 
• '마크다운'이라는 것도 굉장히 생소하고 피하고 싶은 개념이었는데 역시 바로 실전에 적용해가며 개념을 익힌 덕인지 PR을 보낼 때는 제법 능숙하고 효율적으로 마크다운을 사용하여 메시지를 작성할 수 있었다.

 

• 코드블럭과 내부 링크 이동하는 법을 처음 알게 되었다. 신세계!!!!! 
  
  • 특히 코드블럭은 구글링하며 몇 블로그에서 사용하는 것을 보고 어떻게 한 걸까? 너무 궁금해서 내 블로그에도 구현해보고자 많은 검색과 시도를 했었다.
  • 예를 들면, 취소선을 CSS로 코드블럭처럼 꾸며주어 취소선을 사용하여 코드블럭을 표현하곤 했다. 취소선입니다.
  • 모바일에서는 모바일 버전이 적용되어 취소선이 그대로 나와 쓰지 못하고 있었다.

 

• README 작성을 자유자재로 할 수 있게 되었다. (아래는 다른 프로젝트에서의 README 작성)

 

힘들었던 순간

 

이 짧은 프로젝트에서도 힘들었던 순간을 꼽아보라고 하면, 간단하게 아래의 두 상황을 얘기해볼 수 있겠다.

 

1. 정식 문서의 등장 

프로젝트를 시작한지 정말 이틀 만에 베타 문서에서 정식 문서로 모든 내용이 싹 달라져있었다.

• 한 챕터 번역을 마친 다음 다음 챕터 번역을 위해 next.js 홈페이지를 들어간 순간, 검정색이 가득했던 배경에서 갑자기 화이트톤의 화사한 홈페이지가 나와 조우했다. 
• 잉? 뭐지? 잘못 들어왔나? 싶어 새로고침을 하고, 주소창을 확인했지만 실수한 부분은 없었다.
• 홈페이지 개편을 했나보다, 라고 단순히 생각을 하고 내가 번역할 파트로 들어가기 위해 카테고리를 누르는데...
• 내가 번역한 챕터가 사라지고 없었다...!!!!!!!!
• 또한 Optimizing 카테고리 안에 챕터가 기존에는 4개였던 것이 9개로 늘어나 있었다!!!!!

 

• 사실 멘붕이 온 것은 스터디장님이 아니실까 하지만, 나 역시 번역 한 챕터를 끝낸 상황에서 당황스러운 마음을 진정하고 스터디원들에게 이슈 공유를 했다.

 

결론적으로,

• 파트 분배를 다시 하고, (다행히 내가 번역한 파트가 없어진 게 아니라 다른 챕터로 흡수된 것이라 살릴 수 있었다.)
• 스터디장님께서 파일 구조를 새로 엎고 (스터디장님께 무한한 감사를 보내옵니다)
• 스터디원들은 업데이트된 내용을 pull해오는 작업을 하는 것으로 마무리되었다. 

 

2. git rebase 멘붕

git merge, rebase는 물론 git에 대해 fork, clone, origin으로 push한 경험밖에 없었던 나는 브랜치 최신화에 대해 너무 안일하게 생각했었다. 구글링해서 나온 포스팅과 타입 스크립트 번역 프로젝트 : PR 보내는 방법을 참고하여 rebase를 이용한 브랜치 동기화를 시키고자 했다.  

• 그렇게, git rebase 어쩌구 를 입력한 순간 지옥이 시작됐다
• 뭔가 내 브랜치가 main 브랜치에 합쳐진 느낌이야.... 망했어 (?) + 계속 이전 commit으로 돌아가는 느낌적인 느낌으로 나의 멘탈이 서서히 붕괴되기 시작했다.

 

결론적으로,

• 이대로 계속 진행시키면 프로젝트 전체의 커밋 상태가 엉망이 될 것 같다는 생각에 우선 나의 작업물들을 다른 곳으로 옮겨두고, 다시 clone해서 merge를 이용해 브랜치 최신화를 시켰다.
• 브랜치 최신화와 관련하여 rebase를 활용한 방법은 커밋 상태를 깔끔하게 만들어준다는 장점이 있지만, 다른 팀원들이 중간에 커밋을 많이 한 상황에서는 문제가 생길 요지가 있다.
• 관련 참고할 만한 포스팅 

[Git 깃] git rebase 위험성

 

메인 프로젝트에 들어가기 전에 , 미리 이와 같은 상황을 겪으며 해결책을 찾으려 노력하는 과정들이 있어서 정말 다행이라는 생각이 든다. 어떻게든 길은 있다는 생각이 들었다. 

 

기여한 것들

 

1. 번역

당연히 번역 프로젝트이기 때문에, 내가 해야 하는 가장 큰 기여는 '정확하고 일관적인 번역을 제공하는 것'이다.

• 1차로는 번역기로 초벌 번역을 하고 2차로 직접 원문과 초벌 번역을 참고하여 최종 번역을 작성하는 과정을 거쳤다. 
• 특히 번역기가 '컴포넌트'를 '구성요소'로 번역하는 등 번역해버리는 번역하면 안되는 단어들을 다시 제대로 번역하였다.
• 또, 영어 단어를 한글로 고치기 전에 구글링을 통해 일반적으로 통용되는 단어가 있는지 등을 먼저 살펴보고자 노력했다.
• 개발자 사이에서 영어가 더 많이 통용되는 단어나, 한글로 번역하게 되면 어색하게 되는 단어는 원문 그대로 번역을 진행했다.
  • 예시: absolute 포지션, SEO, priority, OpenTelemetry 등
• 헷갈릴 수 있는 개념의 경우 번역한 단어와 원문 단어를 같이 탑재했다.
  • 예시: 누적 레이아웃(Cumulative Layout Shift), 정적 가져오기(static import) 등

 

💬 문제 인식

그렇게 번역 작업을 하다보니, 애매하게 더이상 작업이 지지부진해지는 상황이 생겼다. 바로 아래와 같은 생각들 때문이었다.

• 다른 챕터의 소제목으로의 마크다운 링크를 걸어야 하는 상황이 있는데, 아직 그 소제목이 어떻게 번역될지를 모른다. 
• Good to know, Recommendation 등 모든 문서에 공통적으로 들어가는 단어들을 어떻게 번역해야 할지, (이대로면 제각각 번역이 될 것이다.) 고민이 된다.
• 보기 좋은 UI를 위해 나는 소제목 사이를 한 줄씩 띄워주고 ':' 기호 앞 뒤로 여백을 줬는데, 이대로면 챕터 별 UI 역시 일관성이 없게 될 것이다.

 

다시 말해, 스터디원끼리의 합의된 컨벤션이 필요하다!

 

 

1-1. 용어 및 기타 컨벤션 공유 파일 생성

따라서, [Nextjs Doc 번역] 용어 및 기타 컨벤션 엑셀 공유 시트를 만들어 디스코드로 공유를 했다. 목적은 아래와 같다.

• 모든 문서에 공통으로 들어가는 문구를 어떻게 번역할지 정하고, 양식틀 정하기
• parent element를 '상위 엘리먼트'로 쓸지, '부모 엘리먼트'로 쓸지 아니면 '상위 요소'나 '부모 요소'로 쓸지 등 일관적으로 용어 번역 통일하기
• + 만약 다르게 번역해야 하는 부분이나, 기존 합의된 내용에 이견이 있을 경우 이슈 공유하기

 

 

엑셀 시트의 내용 : 

 

 

2.  작업 상황 워크시트 생성

기존의 작업상황 워크시트는 아래와 같이 각자의 이름에 해당되는 칸에 자기가 맡은 파트와 작업 상황을 표시하는 정도였다.

• 베타 버전에서 각자의 역할과 작업 파트를 분배한 후, 며칠이 지나지도 않아 새롭게 싹 갈아진 정식 문서의 등장으로 대혼란의 상황이 발생했다. (나만 혼란일 수도...ㅎ)
  • 파트 분배 부분에서 누가 어느 파트를 새롭게 가져갔고,
  • 아직 맡지 않은 파트는 무엇이 있으며
  • 각자의 진행 상황은 어떠한지 등이 명확하지 않았다.

 

짧고 굵게 번역 프로젝트만 하는, 정기 모임이 없는 스터디였기 때문에 커뮤니케이션은 정말 어려웠다.

• 하지만!! 마침 스터디장님과 페어가 되어!!! 이런 저런 궁금증 등을 음성 채팅으로 이야기 나눌 수 있었다.
• 그래서 하라는 페어 과제는 일단 제쳐두고(ㅋㅋㅋㅋ) 일단 같이 워크시트에 대해 논의를 한 뒤, 워크시트를 생성하기로 했다.
  • 깃헙의 '이슈' 탭에서 처음에 생성하고자 했으나, 여러 자잘한 문제와 함께 우선 스터디원들이 익숙한 노션에서 생성하는 것이 낫다는 판단을 내렸다.
  •  카테고리들을 다 긁어서 간단하게 번역 작업상황에 대한 테이블을 만들고 <진행중(찜)>, <진행중>, <번역완료>, <PR완료> 태그를 생성했다.

 

---

 

이렇게 첫 오픈소스 기여 프로젝트를 무사히 마치고,

뭔가 나와는 먼 이야기일 것만 같았던 컨트리뷰터에 이름을 올리며

정말 많은 것을 배울 수 있었다. 

 

---

 

md파일을 작성하며 마크다운은 이제 가볍게 쓸 수 있게 되었고,

git 사용법에 대해 어느 정도 숙달이 되었으며, 협업에 대한 이해가 생겼다.

 

또한, 번역을 진행하며 생각보다도 더 일찍 자연스럽게 Next.js를 공부하며

그 다음 프로젝트는 Next.js로 만들 수 있게 되었다.

 

무엇보다도 이러한 경험을 통해 다른 오픈소스 기여 기회가 생긴다면

주저하지 않고 참여하고자 하는 마음가짐을 얻게 되었다.

 

---

 

다음엔 어느 프로젝트에 숟가락을 올려볼까?

벌써부터 기대가 된다.