Apache Airflow 프로젝트에 한국어가 3.1.0 버전부터 지원된다는 소식을 접하신 분들이 많으실 텐데요.
한국어 지원 뒤에는 Airflow 프로젝트가 처음으로 i18n을 도입하면서 겪은 여러 시행착오가 있었습니다.
Airflow 프로젝트는 버전이 빠르게 올라가는 프로젝트입니다. 더 나은 프로젝트가 되기 위해 메이저/마이너 버전이 빠르게 릴리즈되는데요.
이때 모든 언어 번역은 해당 버전에 맞춰야 하고, 번역 내용을 테스트하고 검증할 시간도 필요합니다.언어 동결(freeze) 기간 이 필요하다는 결론이 나왔고, 동결 기준과 방법에 대한 논의가 진행되었습니다.
첫 시도는 Pre-commit 훅을 이용해 en 폴더에서 변경 사항이 있으면 커밋 자체를 막는 방식이었습니다.
main ← shahar1:default-language-freeze-pre-commit
열림 07:00PM - 31 Aug 25 UTC
Following the recent dev call, this PR introduces a pre-commit to prevent change… s in the default language during freeze time. The current freeze will be between Sep. 1 to Sep 9 (inc.); all times are arbitrarily measured in ~UTC~ AoE time.
This pre-commit should be reused in later freezes simply by changing the dates (I'll add it to the i18n policy).
---
**^ Add meaningful description above**
Read the **[Pull Request Guidelines](https://github.com/apache/airflow/blob/main/contributing-docs/05_pull_requests.rst#pull-request-guidelines)** for more information.
In case of fundamental code changes, an Airflow Improvement Proposal ([AIP](https://cwiki.apache.org/confluence/display/AIRFLOW/Airflow+Improvement+Proposals)) is needed.
In case of a new dependency, check compliance with the [ASF 3rd Party License Policy](https://www.apache.org/legal/resolved.html#category-x).
In case of backwards incompatible changes please leave a note in a newsfragment file, named `{pr_number}.significant.rst` or `{issue_number}.significant.rst`, in [airflow-core/newsfragments](https://github.com/apache/airflow/tree/main/airflow-core/newsfragments).
한 의견으로 UTC 대신 AoE(AoE: Anywhere on Earth) 기준을 사용하는 것이 제안되었습니다.
구분
UTC
AoE
기준
전 세계 표준 시
지구상 가장 늦게 날짜가 바뀌는 시간(UTC-12)
날짜 변경
UTC 기준 자정에 변경
지구상 마지막 지역 기준 날짜 변경
AoE 기준을 적용하면, 글로벌 협업에서도 몇 월 몇 일까지 같은 동결 조건을 쉽게 적용할 수 있습니다.
freeze_exemptions를 활용한 슬라이딩 방식의 문제점지난 번역 파일에 대해 번들 사이즈 개선을 하면서도 그렇지만, 이번에도 제가 작업하고 있는 부분에서 문제가 생겼습니다 ㅋㅋㅋㅋㅋㅋㅋㅋ
기존에는 슬라이딩 방식 을 사용했습니다.en 폴더에 문자열을 추가 또는 변경해야 하는 경우 _freeze_exemptions.json에 등록하고, 동결 기간이 지나면 자동으로 슬라이딩되는 방식이었죠.
문제는 제가 3.1.0에 들어가야 할 작업을 하고 있을 때, 동결 기간에 걸리면서 Pre-commit이 막혔던 상황입니다.
결론적은, freeze_exemptions를 활용한 슬라이딩 방식은 너무 엄격하고 복잡해 엣지 케이스를 양산 하게 되었습니다.
현재는 CI 기반 관리 방식 으로 변경되었습니다.
main ← potiuk:simpler-translation-freeze
열림 04:36PM - 01 Sep 25 UTC
This is follow-up after #55119 - implements the translation freeze quite a bit s… impler and faster:
* uses selective checks (fail fast)
* does not check the dates (we will set the flag to False when freeze time passes
* you can bypass the freeze with a label rather than having to commit exemption file
---
**^ Add meaningful description above**
Read the **[Pull Request Guidelines](https://github.com/apache/airflow/blob/main/contributing-docs/05_pull_requests.rst#pull-request-guidelines)** for more information.
In case of fundamental code changes, an Airflow Improvement Proposal ([AIP](https://cwiki.apache.org/confluence/display/AIRFLOW/Airflow+Improvement+Proposals)) is needed.
In case of a new dependency, check compliance with the [ASF 3rd Party License Policy](https://www.apache.org/legal/resolved.html#category-x).
In case of backwards incompatible changes please leave a note in a newsfragment file, named `{pr_number}.significant.rst` or `{issue_number}.significant.rst`, in [airflow-core/newsfragments](https://github.com/apache/airflow/tree/main/airflow-core/newsfragments).
동결이 시작되면 dev/breeze/src/airflow_breeze/utils/selective_checks.py 파일에서 아래 변수를 수동으로 설정합니다.
FAIL_WHEN_ENGLISH_TRANSLATION_CHANGED = True
이렇게 하면 PR에 영문 변경 허용 라벨을 따로 적용하지 않는 한, PR에서 영어 번역 파일을 변경했다면 모든 CI는 실패합니다.
동결 기간 중 영어 번역 파일을 수정해야 할 경우, 반드시 Slack #i18n 채널에서 논의하고, 최소 1명의 PMC 멤버 승인을 받아야 합니다.
일단 커밋을 다시 할 수 있어서 너무 좋았고, 훨씬 체계적인 느낌이 들어서 현재의 방식이 가장 좋을 것 같다는 생각이 듭니다.
Apache Airflow 프로젝트의 i18n 관리 과정을 가까운 곳에서 살펴보면서 번역 관리가 단순히 글자를 번역하는 일이 아니라는 걸 새삼 느낍니다.
버전이 빨리 올라가는 프로젝트에서 안정적으로 번역을 관리하려면 동결 기간 , 글로벌 시간 기준 , CI 검증 같은 체계적인 관리가 꼭 필요하다는 것도 알게 되었고,정확한 프로세스와 협업 규칙 이 얼마나 중요한지도 직접 시행 착오들을 겪으며 확인할 수 있었습니다.
처음엔 저도 번역을 단순한 기여라고 생각했지만, 참여할수록 시행착오를 직접 경험하며 생각보다 재미있고 배울게 많은 기회라는 걸 느꼈습니다.
곧 3.1.0 버전이 출시되는데, 한국어로 설정해보시고 어색한 번역이 보이면 한국어 번역팀 에 조인해서 함께 개선해보시는 것도 추천드립니다!
