From d579db4db779be024441a452608dbc4efc78eda2 Mon Sep 17 00:00:00 2001
From: yijun-lee <yijunlee.000@gmail.com>
Date: Sat, 28 Sep 2024 00:08:20 +0900
Subject: [PATCH 1/6] docs: ko: modular_transformers.md

---
 docs/source/ko/_toctree.yml            |   2 +
 docs/source/ko/modular_transformers.md | 121 +++++++++++++++++++++++++
 2 files changed, 123 insertions(+)
 create mode 100644 docs/source/ko/modular_transformers.md

diff --git a/docs/source/ko/_toctree.yml b/docs/source/ko/_toctree.yml
index eafd389994ad52..841aabc7a23df2 100644
--- a/docs/source/ko/_toctree.yml
+++ b/docs/source/ko/_toctree.yml
@@ -137,6 +137,8 @@
     title: 문제 해결
   - local: in_translation
     title: (번역중) Interoperability with GGUF files
+  - local: modular_transformers
+    title: 'transformers'에서의 모듈성
   title: (번역중) 개발자 가이드
 - sections:
   - local: in_translation
diff --git a/docs/source/ko/modular_transformers.md b/docs/source/ko/modular_transformers.md
new file mode 100644
index 00000000000000..33d2bb9483482a
--- /dev/null
+++ b/docs/source/ko/modular_transformers.md
@@ -0,0 +1,121 @@
+# Modular transformers
+
+`transformers` is an opinionated framework; our philosophy is defined in the following [conceptual guide](./philosophy).
+
+The core of that philosophy is exemplified by the [single model, single file](https://huggingface.co/blog/transformers-design-philosophy)
+aspect of the library. This component's downside is that it limits the inheritance and importability of components from
+files to others in the toolkit.
+
+As a result, model components tend to be repeated across many files. There are as many attention layers defined
+in `transformers` as there are models, and a significant number of those are identical to each other. 
+The unfortunate consequence is that independent implementations tend to diverge as fixes and changes get applied
+to specific parts of the code.
+
+In order to balance this issue, we introduced the concept of "copies" across the library. By adding a comment indicating
+that code is a copy of another, we can enforce through CI and local commands that copies do not diverge. However,
+while the complexity is low, this is often quite tedious to do.
+
+And, finally, this contributes to adding a significant overhead to contributing models which we would like to remove.
+This approach often requires model contributions to add modeling code (~1k lines), processor (~500 lines), tests, docs,
+etc. Model contribution PRs rarely add less than 3-5k lines of code, with much of this code being boilerplate.
+
+This raises the bar for contributions, and with Modular Transformers, we're aiming to lower the bar to a much more
+acceptable point.
+
+## What is it?
+
+Modular Transformers introduces the concept of a "modular" file to a model folder. This modular file accepts code
+that isn't typically accepted in modeling/processing files, as it allows importing from neighbouring models as well
+as inheritance from classes to others.
+
+This modular file defines models, processors, and the configuration class that would otherwise be defined in their
+respective modules.
+
+Finally, this feature introduces a new `linter` which will "unravel" the modular file into the "single model, single 
+file" directory structure. These files will get auto-generated every time the script is run; reducing the required
+contributions to the modular file, and therefore only to the changes between the contributed model and others.
+
+Model users will end up importing and using the single-file interface, so no change is expected here. Doing this, we
+hope to combine the best of both worlds: enabling simple contributions while sticking to our philosophy.
+
+This is therefore a replacement for the `# Copied from` markers, and previously contributed models can be expected to
+be moved to the new Modular Transformers format in the coming months.
+
+### Details 
+
+The "linter", which unravels the inheritance and creates all single-files from the modular file, will flatten the 
+inheritance while trying to be invisible to Python users. At this time, the linter flattens a **single** level of
+inheritance.
+
+For example:
+- If a configuration class inherits from another and adds/deletes an argument, the generated file will either directly 
+  reference it (in case of addition) or completely remove it (in case of deletion).
+- If a class inherits from another, for example: class GemmaModel(LlamaModel):, dependencies are automatically 
+  inferred. All submodules will be automatically inferred from the superclass.
+
+You should be able to write everything (the tokenizer, the image processor, the model, the config) in this `modular` 
+file, and the corresponding files will be created for you. 
+
+### Enforcement
+
+[TODO] We are introducing a new test, that makes sure the generated content matches what is present in the `modular_xxxx.py`
+
+### Examples
+
+Here is a quick example with BERT and RoBERTa. The two models are intimately related: their modeling implementation 
+differs solely by a change in the embedding layer.
+
+Instead of redefining the model entirely, here is what the `modular_roberta.py` file looks like for the modeling &
+configuration classes (for the sake of the example, the tokenizer is ignored at this time as very different).
+
+```python
+from torch import nn
+from ..bert.configuration_bert import BertConfig
+from ..bert.modeling_bert import (
+    BertModel,
+    BertEmbeddings,
+    BertForMaskedLM
+)
+
+# The RoBERTa config is identical to BERT's config
+class RobertaConfig(BertConfig):
+  model_type = 'roberta'
+
+# We redefine the embeddings here to highlight the padding ID difference, and we redefine the position embeddings
+class RobertaEmbeddings(BertEmbeddings):
+    def __init__(self, config):
+        super().__init__(config())
+
+        self.padding_idx = config.pad_token_id
+        self.position_embeddings = nn.Embedding(
+            config.max_position_embeddings, config.hidden_size, padding_idx=self.padding_idx
+        )
+
+# The RoBERTa model is identical to the BERT model, except for the embedding layer. 
+# We redefine the embeddings above, so here there is no need to do additional work
+class RobertaModel(BertModel):
+  def __init__(self, config):
+    super().__init__(config)
+    self.embeddings = RobertaEmbeddings(config)
+
+      
+# The heads now only need to redefine the model inside to the correct `RobertaModel`
+class RobertaForMaskedLM(BertForMaskedLM):
+  def __init__(self, config):
+    super().__init__(config)
+    self.model = RobertaModel(config)
+```
+
+Note that if you do not use the dependency that you defined, you will have the following error:
+
+```bash
+ValueError: You defined `RobertaEmbeddings` in the modular_roberta.py, it should be used
+                                    when you define `BertModel`, as it is one of it's direct dependencies. Make sure
+                                    you use it in the `__init__` function.
+```
+
+Additionally, you may find a list of examples here:
+
+## What it is not
+
+It is not a replacement for the modeling code (yet?), and if your model is not based on anything else that ever existed, then you can add a `modeling` file as usual.
\ No newline at end of file

From 107092a40a9f1a8d795e101f00cdbb196e77d165 Mon Sep 17 00:00:00 2001
From: yijun-lee <yijunlee.000@gmail.com>
Date: Sat, 28 Sep 2024 00:10:54 +0900
Subject: [PATCH 2/6] feat: nmt draft

---
 docs/source/ko/modular_transformers.md | 109 ++++++++++---------------
 1 file changed, 42 insertions(+), 67 deletions(-)

diff --git a/docs/source/ko/modular_transformers.md b/docs/source/ko/modular_transformers.md
index 33d2bb9483482a..d3e0a40f1f4dd2 100644
--- a/docs/source/ko/modular_transformers.md
+++ b/docs/source/ko/modular_transformers.md
@@ -1,72 +1,48 @@
-# Modular transformers
+# 모듈식 트랜스포머 [[modular-transformers]]
 
-`transformers` is an opinionated framework; our philosophy is defined in the following [conceptual guide](./philosophy).
+`transformers`는 의견이 반영된 프레임워크이며, 우리의 철학은 다음의 [개념 가이드](./philosophy)에 정의되어 있습니다.
 
-The core of that philosophy is exemplified by the [single model, single file](https://huggingface.co/blog/transformers-design-philosophy)
-aspect of the library. This component's downside is that it limits the inheritance and importability of components from
-files to others in the toolkit.
+이 철학의 핵심은 라이브러리의 [단일 모델, 단일 파일](https://huggingface.co/blog/transformers-design-philosophy) 측면에서 잘 나타납니다. 이 구성 요소의 단점은 파일 간에 구성 요소의 상속과 임포트 가능성을 제한한다는 것입니다.
 
-As a result, model components tend to be repeated across many files. There are as many attention layers defined
-in `transformers` as there are models, and a significant number of those are identical to each other. 
-The unfortunate consequence is that independent implementations tend to diverge as fixes and changes get applied
-to specific parts of the code.
+그 결과, 모델 구성 요소가 여러 파일에 걸쳐 반복되는 경향이 있습니다. `transformers`에는 모델 수만큼 많은 어텐션 레이어가 정의되어 있으며, 그 중 상당수는 서로 동일합니다. 불행하게도, 독립적인 구현이 특정 코드 부분에 수정 및 변경이 적용되면서 분기되는 결과를 초래합니다.
 
-In order to balance this issue, we introduced the concept of "copies" across the library. By adding a comment indicating
-that code is a copy of another, we can enforce through CI and local commands that copies do not diverge. However,
-while the complexity is low, this is often quite tedious to do.
+이 문제를 균형 있게 해결하기 위해, 우리는 라이브러리 전체에 "복사본"의 개념을 도입했습니다. 코드가 다른 코드의 복사본임을 나타내는 주석을 추가함으로써, CI 및 로컬 명령을 통해 복사본이 분기되지 않도록 강제할 수 있습니다. 그러나 복잡성이 낮더라도 이는 종종 매우 번거로운 작업입니다.
 
-And, finally, this contributes to adding a significant overhead to contributing models which we would like to remove.
-This approach often requires model contributions to add modeling code (~1k lines), processor (~500 lines), tests, docs,
-etc. Model contribution PRs rarely add less than 3-5k lines of code, with much of this code being boilerplate.
+마지막으로, 이는 우리가 제거하고자 하는 모델 기여에 상당한 오버헤드를 추가합니다. 이 접근 방식은 종종 모델 기여에 모델링 코드(~1,000줄), 프로세서(~500줄), 테스트, 문서 등을 추가해야 합니다. 모델 기여 PR은 대부분 3,000~5,000줄 이상의 코드를 추가하며, 이 중 많은 부분이 보일러플레이트입니다.
 
-This raises the bar for contributions, and with Modular Transformers, we're aiming to lower the bar to a much more
-acceptable point.
+이는 기여의 장벽을 높이며, 모듈식 트랜스포머를 통해 우리는 이 장벽을 훨씬 더 수용 가능한 수준으로 낮추고자 합니다.
 
-## What is it?
+## 무엇인가요? [[what-is-it]]
 
-Modular Transformers introduces the concept of a "modular" file to a model folder. This modular file accepts code
-that isn't typically accepted in modeling/processing files, as it allows importing from neighbouring models as well
-as inheritance from classes to others.
+모듈식 트랜스포머는 모델 폴더에 "모듈식" 파일의 개념을 도입합니다. 이 모듈식 파일은 일반적으로 모델링/프로세싱 파일에서 허용되지 않는 코드를 허용하며, 이는 인접한 모델로부터의 임포트와 클래스 간의 상속을 허용합니다.
 
-This modular file defines models, processors, and the configuration class that would otherwise be defined in their
-respective modules.
+이 모듈식 파일은 모델, 프로세서 및 구성 클래스를 정의하며, 이는 원래 해당 모듈에서 정의되었을 것입니다.
 
-Finally, this feature introduces a new `linter` which will "unravel" the modular file into the "single model, single 
-file" directory structure. These files will get auto-generated every time the script is run; reducing the required
-contributions to the modular file, and therefore only to the changes between the contributed model and others.
+마지막으로, 이 기능은 모듈식 파일을 "풀어내어" 단일 모델, 단일 파일 디렉토리 구조로 변환하는 새로운 `linter`를 도입합니다. 이 파일들은 스크립트가 실행될 때마다 자동으로 생성되며, 기여해야 할 내용을 모듈식 파일과 따라서 기여된 모델과 다른 모델 간의 차이점으로만 줄여줍니다.
 
-Model users will end up importing and using the single-file interface, so no change is expected here. Doing this, we
-hope to combine the best of both worlds: enabling simple contributions while sticking to our philosophy.
+모델 사용자는 단일 파일 인터페이스를 임포트하고 사용하게 되므로, 여기에는 변화가 예상되지 않습니다. 이를 통해 우리는 양쪽 세계의 장점을 결합하고자 합니다: 간단한 기여를 가능하게 하면서도 우리의 철학을 유지하는 것입니다.
 
-This is therefore a replacement for the `# Copied from` markers, and previously contributed models can be expected to
-be moved to the new Modular Transformers format in the coming months.
+따라서 이는 `# Copied from` 마커의 대체품이며, 이전에 기여된 모델은 앞으로 몇 달 내에 새로운 모듈식 트랜스포머 형식으로 이동할 것으로 예상됩니다.
 
-### Details 
+### 자세한 내용 [[details]]
 
-The "linter", which unravels the inheritance and creates all single-files from the modular file, will flatten the 
-inheritance while trying to be invisible to Python users. At this time, the linter flattens a **single** level of
-inheritance.
+상속을 풀어내고 모듈식 파일로부터 모든 단일 파일을 생성하는 "linter"는 파이썬 사용자에게 보이지 않으면서 상속을 평탄화합니다. 현재로서는, linter는 **단일** 수준의 상속을 평탄화합니다.
 
-For example:
-- If a configuration class inherits from another and adds/deletes an argument, the generated file will either directly 
-  reference it (in case of addition) or completely remove it (in case of deletion).
-- If a class inherits from another, for example: class GemmaModel(LlamaModel):, dependencies are automatically 
-  inferred. All submodules will be automatically inferred from the superclass.
+예를 들어:
+- 구성 클래스가 다른 클래스를 상속하고 인자를 추가/삭제하는 경우, 생성된 파일은 직접 참조(추가의 경우)하거나 완전히 제거합니다(삭제의 경우).
+- 클래스가 다른 클래스를 상속하는 경우, 예를 들어: `class GemmaModel(LlamaModel):`, 종속성이 자동으로 추론됩니다. 모든 서브모듈은 슈퍼클래스로부터 자동으로 추론됩니다.
 
-You should be able to write everything (the tokenizer, the image processor, the model, the config) in this `modular` 
-file, and the corresponding files will be created for you. 
+토크나이저, 이미지 프로세서, 모델, 구성 등을 이 `modular` 파일에 모두 작성할 수 있으며, 해당 파일들이 자동으로 생성됩니다.
 
-### Enforcement
+### 시행 [[enforcement]]
 
-[TODO] We are introducing a new test, that makes sure the generated content matches what is present in the `modular_xxxx.py`
+[TODO] 우리는 새로운 테스트를 도입하여 생성된 콘텐츠가 `modular_xxxx.py`에 있는 내용과 일치하는지 확인합니다.
 
-### Examples
+### 예시 [[examples]]
 
-Here is a quick example with BERT and RoBERTa. The two models are intimately related: their modeling implementation 
-differs solely by a change in the embedding layer.
+여기 BERT와 RoBERTa의 간단한 예가 있습니다. 두 모델은 밀접하게 관련되어 있으며, 모델링 구현은 임베딩 레이어의 변경만으로 차이가 있습니다.
 
-Instead of redefining the model entirely, here is what the `modular_roberta.py` file looks like for the modeling &
-configuration classes (for the sake of the example, the tokenizer is ignored at this time as very different).
+모델을 완전히 재정의하는 대신, `modular_roberta.py` 파일은 모델링 및 구성 클래스를 위해 다음과 같이 생겼습니다(예를 위해 토크나이저는 현재 무시합니다. 매우 다르기 때문입니다).
 
 ```python
 from torch import nn
@@ -77,11 +53,11 @@ from ..bert.modeling_bert import (
     BertForMaskedLM
 )
 
-# The RoBERTa config is identical to BERT's config
+# RoBERTa 구성은 BERT의 구성과 동일합니다
 class RobertaConfig(BertConfig):
-  model_type = 'roberta'
+    model_type = 'roberta'
 
-# We redefine the embeddings here to highlight the padding ID difference, and we redefine the position embeddings
+# 여기서 패딩 ID 차이를 강조하기 위해 임베딩을 재정의하고, 위치 임베딩을 재정의합니다
 class RobertaEmbeddings(BertEmbeddings):
     def __init__(self, config):
         super().__init__(config())
@@ -91,31 +67,30 @@ class RobertaEmbeddings(BertEmbeddings):
             config.max_position_embeddings, config.hidden_size, padding_idx=self.padding_idx
         )
 
-# The RoBERTa model is identical to the BERT model, except for the embedding layer. 
-# We redefine the embeddings above, so here there is no need to do additional work
+# RoBERTa 모델은 임베딩 레이어를 제외하면 BERT 모델과 동일합니다.
+# 위에서 임베딩을 재정의했으므로, 여기서는 추가 작업이 필요 없습니다
 class RobertaModel(BertModel):
-  def __init__(self, config):
-    super().__init__(config)
-    self.embeddings = RobertaEmbeddings(config)
+    def __init__(self, config):
+        super().__init__(config)
+        self.embeddings = RobertaEmbeddings(config)
 
-      
-# The heads now only need to redefine the model inside to the correct `RobertaModel`
+# 헤드는 이제 내부에서 올바른 `RobertaModel`을 재정의하기만 하면 됩니다
 class RobertaForMaskedLM(BertForMaskedLM):
-  def __init__(self, config):
-    super().__init__(config)
-    self.model = RobertaModel(config)
+    def __init__(self, config):
+        super().__init__(config)
+        self.model = RobertaModel(config)
 ```
 
-Note that if you do not use the dependency that you defined, you will have the following error:
+정의한 종속성을 사용하지 않으면 다음과 같은 오류가 발생합니다:
 
 ```bash
 ValueError: You defined `RobertaEmbeddings` in the modular_roberta.py, it should be used
-                                    when you define `BertModel`, as it is one of it's direct dependencies. Make sure
-                                    you use it in the `__init__` function.
+                                        when you define `BertModel`, as it is one of it's direct dependencies. Make sure
+                                        you use it in the `__init__` function.
 ```
 
-Additionally, you may find a list of examples here:
+또한, 다음에서 예시 목록을 찾을 수 있습니다:
 
-## What it is not
+## 무엇이 아니냐 하면
 
-It is not a replacement for the modeling code (yet?), and if your model is not based on anything else that ever existed, then you can add a `modeling` file as usual.
\ No newline at end of file
+(아직은) 모델링 코드를 대체하는 것은 아닙니다. 그리고 여러분의 모델이 지금까지 존재했던 다른 어떤 것에도 기반하지 않는다면, 기존과 같이 `modeling` 파일을 추가할 수 있습니다.
\ No newline at end of file

From 8ac92e5adfeea51efce5ca2e11c198f9886a12a3 Mon Sep 17 00:00:00 2001
From: yijun-lee <yijunlee.000@gmail.com>
Date: Sat, 28 Sep 2024 00:13:55 +0900
Subject: [PATCH 3/6] fix inline TOC

---
 docs/source/ko/modular_transformers.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/docs/source/ko/modular_transformers.md b/docs/source/ko/modular_transformers.md
index d3e0a40f1f4dd2..d6a3e50b303f10 100644
--- a/docs/source/ko/modular_transformers.md
+++ b/docs/source/ko/modular_transformers.md
@@ -91,6 +91,6 @@ ValueError: You defined `RobertaEmbeddings` in the modular_roberta.py, it should
 
 또한, 다음에서 예시 목록을 찾을 수 있습니다:
 
-## 무엇이 아니냐 하면
+## 무엇이 아니냐 하면 [[what-it-is-not]]
 
 (아직은) 모델링 코드를 대체하는 것은 아닙니다. 그리고 여러분의 모델이 지금까지 존재했던 다른 어떤 것에도 기반하지 않는다면, 기존과 같이 `modeling` 파일을 추가할 수 있습니다.
\ No newline at end of file

From aa00ecd30b824ff1b7a6d7d882a0844f03484adf Mon Sep 17 00:00:00 2001
From: yijun-lee <yijunlee.000@gmail.com>
Date: Sat, 28 Sep 2024 01:50:45 +0900
Subject: [PATCH 4/6] fix: manual edits

---
 docs/source/ko/modular_transformers.md | 28 +++++++++++++-------------
 1 file changed, 14 insertions(+), 14 deletions(-)

diff --git a/docs/source/ko/modular_transformers.md b/docs/source/ko/modular_transformers.md
index d6a3e50b303f10..f15d191c9b19da 100644
--- a/docs/source/ko/modular_transformers.md
+++ b/docs/source/ko/modular_transformers.md
@@ -4,33 +4,33 @@
 
 이 철학의 핵심은 라이브러리의 [단일 모델, 단일 파일](https://huggingface.co/blog/transformers-design-philosophy) 측면에서 잘 나타납니다. 이 구성 요소의 단점은 파일 간에 구성 요소의 상속과 임포트 가능성을 제한한다는 것입니다.
 
-그 결과, 모델 구성 요소가 여러 파일에 걸쳐 반복되는 경향이 있습니다. `transformers`에는 모델 수만큼 많은 어텐션 레이어가 정의되어 있으며, 그 중 상당수는 서로 동일합니다. 불행하게도, 독립적인 구현이 특정 코드 부분에 수정 및 변경이 적용되면서 분기되는 결과를 초래합니다.
+그 결과, 모델 구성 요소가 여러 파일에 걸쳐 반복되는 경향이 있습니다. `transformers`에는 모델 수만큼 많은 어텐션 레이어가 정의되어 있으며, 그 중 상당수는 서로 동일합니다. 안타깝게도, 수정과 변경 사항이 코드의 특정 부분에 적용되면서 독립적인 구현들이 서로 분기되는 경향이 있습니다.
 
-이 문제를 균형 있게 해결하기 위해, 우리는 라이브러리 전체에 "복사본"의 개념을 도입했습니다. 코드가 다른 코드의 복사본임을 나타내는 주석을 추가함으로써, CI 및 로컬 명령을 통해 복사본이 분기되지 않도록 강제할 수 있습니다. 그러나 복잡성이 낮더라도 이는 종종 매우 번거로운 작업입니다.
+이 문제를 적절히 해결하기 위해, 우리는 라이브러리 전체에 "복사본"의 개념을 도입했습니다. 코드가 다른 코드의 복사본임을 나타내는 주석을 추가함으로써, CI 및 로컬 명령을 통해 복사본이 분기되지 않도록 강제할 수 있습니다. 그러나 복잡성이 낮더라도 이는 종종 매우 번거로운 작업입니다.
 
-마지막으로, 이는 우리가 제거하고자 하는 모델 기여에 상당한 오버헤드를 추가합니다. 이 접근 방식은 종종 모델 기여에 모델링 코드(~1,000줄), 프로세서(~500줄), 테스트, 문서 등을 추가해야 합니다. 모델 기여 PR은 대부분 3,000~5,000줄 이상의 코드를 추가하며, 이 중 많은 부분이 보일러플레이트입니다.
+마지막으로, 이 방식은 우리가 줄이고자 하는 상당한 오버헤드를 모델 기여 과정에 추가하게 됩니다. 이 접근 방식은 종종 모델 기여에 모델링 코드(~1,000줄), 프로세서(~500줄), 테스트, 문서 등을 추가해야 합니다. 모델 기여 PR은 대부분 3,000~5,000줄 이상의 코드를 추가하며, 이 중 많은 부분이 반복되는 문장입니다.
 
-이는 기여의 장벽을 높이며, 모듈식 트랜스포머를 통해 우리는 이 장벽을 훨씬 더 수용 가능한 수준으로 낮추고자 합니다.
+이는 기여의 장벽을 높이며, 모듈식 트랜스포머를 통해 우리는 이러한 장벽을 훨씬 더 수용 가능한 수준으로 낮추고자 합니다.
 
-## 무엇인가요? [[what-is-it]]
+## 무엇인가요 [[what-is-it]]
 
 모듈식 트랜스포머는 모델 폴더에 "모듈식" 파일의 개념을 도입합니다. 이 모듈식 파일은 일반적으로 모델링/프로세싱 파일에서 허용되지 않는 코드를 허용하며, 이는 인접한 모델로부터의 임포트와 클래스 간의 상속을 허용합니다.
 
-이 모듈식 파일은 모델, 프로세서 및 구성 클래스를 정의하며, 이는 원래 해당 모듈에서 정의되었을 것입니다.
+이 모듈식 파일은 각각의 별도의 모듈에서 정의되었을 모델, 프로세서 및 구성 클래스를 정의합니다.
 
-마지막으로, 이 기능은 모듈식 파일을 "풀어내어" 단일 모델, 단일 파일 디렉토리 구조로 변환하는 새로운 `linter`를 도입합니다. 이 파일들은 스크립트가 실행될 때마다 자동으로 생성되며, 기여해야 할 내용을 모듈식 파일과 따라서 기여된 모델과 다른 모델 간의 차이점으로만 줄여줍니다.
+마지막으로, 이 기능은 모듈식 파일을 "풀어내어" 단일 모델, 단일 파일 디렉토리 구조로 변환하는 새로운 `linter`를 도입합니다. 이 파일들은 스크립트가 실행될 때마다 자동으로 생성되며, 기여해야 할 내용을 모듈식 파일, 그리고 기여된 모델과 다른 모델 간의 차이점으로만 줄여줍니다.
 
-모델 사용자는 단일 파일 인터페이스를 임포트하고 사용하게 되므로, 여기에는 변화가 예상되지 않습니다. 이를 통해 우리는 양쪽 세계의 장점을 결합하고자 합니다: 간단한 기여를 가능하게 하면서도 우리의 철학을 유지하는 것입니다.
+모델 사용자는 단일 파일 인터페이스를 임포트하고 사용하게 되므로, 여기에는 변화가 없을 것입니다. 이를 통해 우리는 양쪽 세계의 장점을 결합하고자 합니다: 간단한 기여를 가능하게 하면서도 우리의 철학을 유지하는 것입니다.
 
 따라서 이는 `# Copied from` 마커의 대체품이며, 이전에 기여된 모델은 앞으로 몇 달 내에 새로운 모듈식 트랜스포머 형식으로 이동할 것으로 예상됩니다.
 
 ### 자세한 내용 [[details]]
 
-상속을 풀어내고 모듈식 파일로부터 모든 단일 파일을 생성하는 "linter"는 파이썬 사용자에게 보이지 않으면서 상속을 평탄화합니다. 현재로서는, linter는 **단일** 수준의 상속을 평탄화합니다.
+상속을 풀어내고 모듈식 파일로부터 모든 단일 파일을 생성하는 "linter"는 파이썬 사용자에게 보이지 않는 상태로 상속을 평탄화합니다. 현재로서는, linter는 **단일** 수준의 상속을 평탄화합니다.
 
 예를 들어:
 - 구성 클래스가 다른 클래스를 상속하고 인자를 추가/삭제하는 경우, 생성된 파일은 직접 참조(추가의 경우)하거나 완전히 제거합니다(삭제의 경우).
-- 클래스가 다른 클래스를 상속하는 경우, 예를 들어: `class GemmaModel(LlamaModel):`, 종속성이 자동으로 추론됩니다. 모든 서브모듈은 슈퍼클래스로부터 자동으로 추론됩니다.
+- 클래스가 다른 클래스를 상속하는 경우, 예를 들어 class GemmaModel(LlamaModel): 의 경우, 종속성이 자동으로 추론됩니다. 모든 서브모듈은 슈퍼클래스로부터 자동으로 추론됩니다.
 
 토크나이저, 이미지 프로세서, 모델, 구성 등을 이 `modular` 파일에 모두 작성할 수 있으며, 해당 파일들이 자동으로 생성됩니다.
 
@@ -40,9 +40,9 @@
 
 ### 예시 [[examples]]
 
-여기 BERT와 RoBERTa의 간단한 예가 있습니다. 두 모델은 밀접하게 관련되어 있으며, 모델링 구현은 임베딩 레이어의 변경만으로 차이가 있습니다.
+여기 BERT와 RoBERTa의 간단한 예가 있습니다. 두 모델은 밀접하게 관련되어 있으며, 모델 구현의 차이는 임베딩 레이어의 변경에서만 있습니다.
 
-모델을 완전히 재정의하는 대신, `modular_roberta.py` 파일은 모델링 및 구성 클래스를 위해 다음과 같이 생겼습니다(예를 위해 토크나이저는 현재 무시합니다. 매우 다르기 때문입니다).
+모델을 완전히 재정의하는 대신, `modular_roberta.py` 파일은 모델링 및 구성 클래스를 위해 다음과 같이 생겼습니다. (예시를 위해, 토크나이저는 매우 다르므로 일단 무시합니다.)
 
 ```python
 from torch import nn
@@ -91,6 +91,6 @@ ValueError: You defined `RobertaEmbeddings` in the modular_roberta.py, it should
 
 또한, 다음에서 예시 목록을 찾을 수 있습니다:
 
-## 무엇이 아니냐 하면 [[what-it-is-not]]
+## 무엇이 아닌가요 [[what-it-is-not]]
 
-(아직은) 모델링 코드를 대체하는 것은 아닙니다. 그리고 여러분의 모델이 지금까지 존재했던 다른 어떤 것에도 기반하지 않는다면, 기존과 같이 `modeling` 파일을 추가할 수 있습니다.
\ No newline at end of file
+(아직은?) 모델링 코드를 대체하는 것은 아닙니다. 그리고 여러분의 모델이 지금까지 존재했던 다른 어떤 것에도 기반하지 않는다면, 기존과 같이 `modeling` 파일을 추가할 수 있습니다.
\ No newline at end of file

From d3b69cfff170ba67c94a66f34fe614aef919a514 Mon Sep 17 00:00:00 2001
From: Yijun Lee <119404328+yijun-lee@users.noreply.github.com>
Date: Sun, 29 Sep 2024 23:28:29 +0900
Subject: [PATCH 5/6] fix: resolve suggestions

---
 docs/source/ko/modular_transformers.md | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/docs/source/ko/modular_transformers.md b/docs/source/ko/modular_transformers.md
index f15d191c9b19da..0e8bc83c805fd9 100644
--- a/docs/source/ko/modular_transformers.md
+++ b/docs/source/ko/modular_transformers.md
@@ -8,7 +8,7 @@
 
 이 문제를 적절히 해결하기 위해, 우리는 라이브러리 전체에 "복사본"의 개념을 도입했습니다. 코드가 다른 코드의 복사본임을 나타내는 주석을 추가함으로써, CI 및 로컬 명령을 통해 복사본이 분기되지 않도록 강제할 수 있습니다. 그러나 복잡성이 낮더라도 이는 종종 매우 번거로운 작업입니다.
 
-마지막으로, 이 방식은 우리가 줄이고자 하는 상당한 오버헤드를 모델 기여 과정에 추가하게 됩니다. 이 접근 방식은 종종 모델 기여에 모델링 코드(~1,000줄), 프로세서(~500줄), 테스트, 문서 등을 추가해야 합니다. 모델 기여 PR은 대부분 3,000~5,000줄 이상의 코드를 추가하며, 이 중 많은 부분이 반복되는 문장입니다.
+마지막으로, 이 방식은 우리가 줄이고자 하는 상당한 오버헤드를 모델 기여 과정에 추가하게 됩니다. 이 접근 방식은 종종 모델 기여에 모델링 코드(~1,000줄), 프로세서(~500줄), 테스트, 문서 등을 추가해야 합니다. 모델 기여 PR은 대부분 3,000~5,000줄 이상의 코드를 추가하며, 이 중 많은 부분이 보일러플레이트(boilerplate) 코드입니다.
 
 이는 기여의 장벽을 높이며, 모듈식 트랜스포머를 통해 우리는 이러한 장벽을 훨씬 더 수용 가능한 수준으로 낮추고자 합니다.
 
@@ -93,4 +93,4 @@ ValueError: You defined `RobertaEmbeddings` in the modular_roberta.py, it should
 
 ## 무엇이 아닌가요 [[what-it-is-not]]
 
-(아직은?) 모델링 코드를 대체하는 것은 아닙니다. 그리고 여러분의 모델이 지금까지 존재했던 다른 어떤 것에도 기반하지 않는다면, 기존과 같이 `modeling` 파일을 추가할 수 있습니다.
\ No newline at end of file
+(아직은?) 모델링 코드를 대체하는 것은 아닙니다. 그리고 여러분의 모델이 지금까지 존재했던 다른 어떤 것에도 기반하지 않는다면, 기존과 같이 `modeling` 파일을 추가할 수 있습니다.

From 80a905148998902874d96f9d1de40b4f8102abe6 Mon Sep 17 00:00:00 2001
From: Yijun Lee <119404328+yijun-lee@users.noreply.github.com>
Date: Sun, 29 Sep 2024 23:29:00 +0900
Subject: [PATCH 6/6] fix: resolve suggestions

Co-authored-by: Jiwook Han <33192762+mreraser@users.noreply.github.com>
Co-authored-by: Chulhwa (Evan) Han <cjfghk5697@ajou.ac.kr>
---
 docs/source/ko/modular_transformers.md | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/docs/source/ko/modular_transformers.md b/docs/source/ko/modular_transformers.md
index 0e8bc83c805fd9..096dd4f13a9889 100644
--- a/docs/source/ko/modular_transformers.md
+++ b/docs/source/ko/modular_transformers.md
@@ -1,6 +1,6 @@
 # 모듈식 트랜스포머 [[modular-transformers]]
 
-`transformers`는 의견이 반영된 프레임워크이며, 우리의 철학은 다음의 [개념 가이드](./philosophy)에 정의되어 있습니다.
+`transformers`는 opinionated(자기 의견이 강한) 프레임워크이며, 우리의 철학은 다음의 [개념 가이드](./philosophy)에 정의되어 있습니다.
 
 이 철학의 핵심은 라이브러리의 [단일 모델, 단일 파일](https://huggingface.co/blog/transformers-design-philosophy) 측면에서 잘 나타납니다. 이 구성 요소의 단점은 파일 간에 구성 요소의 상속과 임포트 가능성을 제한한다는 것입니다.
 
@@ -20,13 +20,13 @@
 
 마지막으로, 이 기능은 모듈식 파일을 "풀어내어" 단일 모델, 단일 파일 디렉토리 구조로 변환하는 새로운 `linter`를 도입합니다. 이 파일들은 스크립트가 실행될 때마다 자동으로 생성되며, 기여해야 할 내용을 모듈식 파일, 그리고 기여된 모델과 다른 모델 간의 차이점으로만 줄여줍니다.
 
-모델 사용자는 단일 파일 인터페이스를 임포트하고 사용하게 되므로, 여기에는 변화가 없을 것입니다. 이를 통해 우리는 양쪽 세계의 장점을 결합하고자 합니다: 간단한 기여를 가능하게 하면서도 우리의 철학을 유지하는 것입니다.
+모델 사용자는 단일 파일 인터페이스를 임포트하고 사용하게 되므로, 여기에는 변화가 없을 것입니다. 이를 통해 간단한 기여를 가능하게 하면서도 우리의 철학을 유지하는 양쪽의 장점을 결합하고자 합니다.
 
-따라서 이는 `# Copied from` 마커의 대체품이며, 이전에 기여된 모델은 앞으로 몇 달 내에 새로운 모듈식 트랜스포머 형식으로 이동할 것으로 예상됩니다.
+따라서 이는 `# Copied from` 마커의 대체품이며, 이전에 기여된 모델은 앞으로 몇 달 내에 새로운 모듈식 트랜스포머 형식으로 전환될 예정입니다.
 
 ### 자세한 내용 [[details]]
 
-상속을 풀어내고 모듈식 파일로부터 모든 단일 파일을 생성하는 "linter"는 파이썬 사용자에게 보이지 않는 상태로 상속을 평탄화합니다. 현재로서는, linter는 **단일** 수준의 상속을 평탄화합니다.
+“linter”는 상속 구조를 풀어서 모듈화된 파일로부터 모든 단일 파일을 생성하며, Python 사용자들에게는 그 과정이 보이지 않도록 동작합니다. 현재 linter는 **단일** 수준의 상속만을 평탄화합니다.
 
 예를 들어:
 - 구성 클래스가 다른 클래스를 상속하고 인자를 추가/삭제하는 경우, 생성된 파일은 직접 참조(추가의 경우)하거나 완전히 제거합니다(삭제의 경우).