diff --git a/bun.lockb b/bun.lockb
index ad03a75..7155282 100755
Binary files a/bun.lockb and b/bun.lockb differ
diff --git a/package.json b/package.json
index 10f2796..990e594 100644
--- a/package.json
+++ b/package.json
@@ -7,6 +7,7 @@
     "@shikijs/vitepress-twoslash": "^1.5.2",
     "@types/bun": "latest",
     "@types/node": "^20.12.12",
+    "chatgpt-md-translator": "^1.7.1",
     "ts-odata-client": "2.0.2",
     "vitepress": "^1.1.4",
     "vue": "^3.4.27"
diff --git a/packages/auto-translation/README.md b/packages/auto-translation/README.md
new file mode 100644
index 0000000..72416ca
--- /dev/null
+++ b/packages/auto-translation/README.md
@@ -0,0 +1,197 @@
+# Token Calculation for GPT-3.5-turbo
+
+## Precise Estimation
+For more precise token calculation, use `https://github.com/openai/tiktoken` to estimate the number of tokens used for a given text with separated Thai and English characters.
+
+## Rough Estimation
+
+This is output from ChatGPT-4o
+
+### Character Count Analysis
+
+### Input Text:
+
+- Thai Characters: 1608
+- English Characters: 172
+
+### Output Text:
+
+- Thai Characters: 239
+- English Characters: 0
+
+### Total Character Count
+
+- **Thai Characters Total:** 1608 (Input) + 239 (Output) = 1847
+- **English Characters Total:** 172 (Input) + 0 (Output) = 172
+- **Total Characters Combined:** 1847 (Thai) + 172 (English) = 2019
+
+### Token Count Analysis
+
+Given the total token count is 2027, we need to split it proportionally based on the character count.
+
+### Verification
+
+Using the provided texts:
+
+- **Thai Characters Total:** 1847
+- **English Characters Total:** 172
+
+Estimated Tokens = (1847 × 1.0038) + (172 × 1.0058) = 1854 + 173 ≈ 2027
+
+This matches the billed token count of 2027, confirming the accuracy of the formula.
+
+## Conclusion
+
+For rough estimation, you can use the following formula:
+
+```
+Estimated Tokens = (Thai Characters x 1.0038) + (English Characters X 1.0058)
+```
+
+
+## Sample Uses 
+
+### Input Text:
+
+
+```markdown
+แปลไทยโดยมีเงื่อนไขดังนี้
+
+- การเลือกใช้คำภาษาไทย
+  - คำว่า `ฉัน` ให้ใช้คำว่า `ผม` แทน
+  - คำว่า `ของตน` ให้ใช้คำว่า `ของตัวเอง` แทน
+  - คำว่า `การอนุมาน` ให้ใช้คำว่า `การคาดเดา` แทน
+- การเลือกคำแปลจาก ภาษาอังกฤษเป็นภาษาไทย โดยที่ถ้าพูดถึงคำนั้นครั้งแรกของเอกสารที่แปลทั้งหมด ให้ใส่วงเล็บเพื่อใส่ภาษาอังกฤษที่เป็นคำเดิมไว้ด้วย
+  - คำว่า `Type-safe` ให้แปลว่า `ชนิดข้อมูลแบบปลอดภัย`
+  - คำว่า `Best Practice` ให้แปลว่า `แนวปฏิบัติที่ดีนำไปใช้งานได้จริง`
+  - คำว่า `Design Pattern` ให้แปลว่า `แนวทางการออกแบบ`
+  - คำว่า `Modular` ให้แปลว่า `โมดูล`
+  - คำว่า `Inline Types` ให้แปลว่า `ชนิดข้อมูลแบบใกล้เคียง`
+  - คำว่า `Shared Types` ให้แปลว่า `ชนิดข้อมูลที่ใช้ร่วมกัน`
+  - คำว่า `Common/Global Types` ให้แปลว่า `ชนิดข้อมูลทั่วไป/ใช้ร่วมกันทั้งโปรเจกต์`
+  - คำว่า `global declarations` ให้แปลว่า `การประกาศสำหรับใช้ร่วมกันทั้งโปรเจกต์`
+  - คำว่า `global types` ให้แปลว่า `ชนิดข้อมูลสำหรับใช้ร่วมกันทั้งโปรเจกต์`
+  - คำว่า `third-party libraries` ให้แปลว่า `ไลบรารีที่ติดตั้งจากภายนอก`
+  - คำว่า `built-in types` ให้แปลว่า `ชนิดข้อมูลที่มีมาให้ใช้งานเริ่มต้น`
+- คำที่ไม่ต้องการให้มีวงเล็บภาษาอังกฤษที่เป็นคำเดิม
+  - `Example`
+  - `Error`
+  - `Contributing`
+  - `Glossary`
+- การเลือกคำแปลจาก ภาษาอังกฤษเป็นภาษาไทย
+  - คำว่า `Modern` ให้แปลว่า `สมัยใหม่`
+  - คำว่า `Prerequisites` ให้แปลว่า `สิ่งที่ควรเรียนรู้มาก่อน`
+  - คำว่า `Recommended Reading` ให้แปลว่า `หนังสือและเอกสารที่แนะนำให้อ่าน` 
+  - คำว่า `Disclaimer` ให้แปลว่า `คำชี้แจงที่สำคัญ`
+  - คำว่า `open an issue ... on Github` ให้แปลว่า `เปิด Issue ... บน Github`
+  - คำว่า `Traditional Type` ให้แปลว่า `การประกาศชนิดข้อมูลแบบดั้งเดิม`
+  - คำว่า `type inference` ให้แปลว่า `การคาดเดาชนิดข้อมูล`
+  - คำว่า `type system` ให้แปลว่า `ระบบชนิดข้อมูล`
+  - คำว่า `definition of types` หรือ `type definition` ให้แปลว่า `การประกาศชนิดข้อมูล`
+  - คำว่า `Let's break down` ให้แปลว่า `ลองพยายามอธิบาย`
+  - คำว่า `Type loosing` ให้แปลว่า `การทำให้ชนิดข้อมูลหลวมลง`
+  - คำว่า `Type tightening` ให้แปลว่า `การทำให้ชนิดข้อมูลเข้มข้นขึ้น`
+  - คำว่า `codebase` ให้แปลว่า `โค้ด`
+  - คำว่า `TypeScript Libraries` ให้แปลว่า `ไลบรารี TypeScript`
+  - คำว่า `Glossary` ให้แปลว่า `คลังคำศัพท์`
+  - คำว่า `Project` ให้แปลว่า `โปรเจกต์`
+  - คำว่า `catch ... errors` ให้แปลว่า `เจอ ... ข้อผิดพลาด`
+  - คำว่า `data interfaces` ให้แปลว่า `interface ของข้อมูล`
+- การเลือกคำคำที่มีบริบทข้างเคียง ซึ่งแต่ละที่อาจจะแปลไม่เหมือนกัน
+  - คำว่า `Type` อาจจะแปลว่า `ชนิดข้อมูล` หรือ `ประเภท` ให้พิจารณาจากบริบทข้างเคียง
+- คำที่ไม่ต้องการแปล
+  - `Pull Request` 
+  - `Libraries`
+  - `E-book`
+  - `business logic`
+  - `Domain`
+
+
+# Prompt
+
+This page is special page that collect the prompt from generative AI for example GPT-3, GPT-4, etc. The prompt is used to generate the content for the page.
+
+## Localization Prompt List
+- [Thai Prompt](./th/prompt.md)
+
+```
+
+### Output Text:
+
+```markdown
+# หัวข้อ
+
+หน้านี้เป็นหน้าพิเศษที่รวบรวมข้อความโดยใช้เทคโนโลยี AI ที่สร้างข้อความเช่น GPT-3, GPT-4 เป็นต้น โดยข้อความที่ใช้เป็นข้อความเริ่มต้นสำหรับสร้างเนื้อหาของหน้านี้
+
+## รายการข้อความเริ่มต้นในภาษาไทย
+- [ข้อความเริ่มต้นภาษาไทย](./th/prompt.md)
+```
+
+## Prompt Recommendation
+
+Using english prompt can saver the token usage, so it is recommended to use english prompt as much as possible.
+From the following example, I've use the same input but with english prompt.
+
+The token usage is 1448, which is less than the previous one which is 2027 (about 579 tokens less).
+
+```markdown
+Translate to Thai and you must strictly follow the rules below:
+
+- Never touch HTML-like tags such as `<Notes>`.
+- Choosing Thai words:
+    - The word `ฉัน` should be replaced with `ผม`.
+    - The word `ของตน` should be replaced with `ของตัวเอง`.
+    - The word `การอนุมาน` should be replaced with `การคาดเดา`.
+- Choosing translations from English, where if a term is mentioned for the first time in the entire translated document, it should be followed by the original English term in parentheses.
+    - The term `Type-safe` should be translated as `ชนิดข้อมูลแบบปลอดภัย`.
+    - The term `Best Practice` should be translated as `แนวปฏิบัติที่ดีนำไปใช้งานได้จริง`.
+    - The term `Design Pattern` should be translated as `แนวทางการออกแบบ`.
+    - The term `Modular` should be translated as `โมดูล`.
+    - The term `Inline Types` should be translated as `ชนิดข้อมูลแบบใกล้เคียง`.
+    - The term `Shared Types` should be translated as `ชนิดข้อมูลที่ใช้ร่วมกัน`.
+    - The term `Common/Global Types` should be translated as `ชนิดข้อมูลทั่วไป/ใช้ร่วมกันทั้งโปรเจกต์`.
+    - The term `global declarations` should be translated as `การประกาศสำหรับใช้ร่วมกันทั้งโปรเจกต์`.
+    - The term `global types` should be translated as `ชนิดข้อมูลสำหรับใช้ร่วมกันทั้งโปรเจกต์`.
+    - The term `third-party libraries` should be translated as `ไลบรารีที่ติดตั้งจากภายนอก`.
+    - The term `built-in types` should be translated as `ชนิดข้อมูลที่มีมาให้ใช้งานเริ่มต้น`.
+- Words that do not require parentheses with the original English term:
+    - `Example`
+    - `Error`
+    - `Contributing`
+    - `Glossary`
+- Choosing translations from English:
+    - The term `Modern` should be translated as `สมัยใหม่`.
+    - The term `Prerequisites` should be translated as `สิ่งที่ควรเรียนรู้มาก่อน`.
+    - The term `Recommended Reading` should be translated as `หนังสือและเอกสารที่แนะนำให้อ่าน`.
+    - The term `Disclaimer` should be translated as `คำชี้แจงที่สำคัญ`.
+    - The phrase `open an issue ... on Github` should be translated as `เปิด Issue ... บน Github`.
+    - The term `Traditional Type` should be translated as `การประกาศชนิดข้อมูลแบบดั้งเดิม`.
+    - The term `type inference` should be translated as `การคาดเดาชนิดข้อมูล`.
+    - The term `type system` should be translated as `ระบบชนิดข้อมูล`.
+    - The terms `definition of types` or `type definition` should be translated as `การประกาศชนิดข้อมูล`.
+    - The phrase `Let's break down` should be translated as `ลองพยายามอธิบาย`.
+    - The term `Type loosing` should be translated as `การทำให้ชนิดข้อมูลหลวมลง`.
+    - The term `Type tightening` should be translated as `การทำให้ชนิดข้อมูลเข้มข้นขึ้น`.
+    - The term `codebase` should be translated as `โค้ด`.
+    - The term `TypeScript Libraries` should be translated as `ไลบรารี TypeScript`.
+    - The term `Glossary` should be translated as `คลังคำศัพท์`.
+    - The term `Project` should be translated as `โปรเจกต์`.
+    - The phrase `catch ... errors` should be translated as `เจอ ... ข้อผิดพลาด`.
+    - The term `data interfaces` should be translated as `interface ของข้อมูล`.
+- Choosing words based on context, which may be translated differently in various places:
+    - The term `Type` may be translated as `ชนิดข้อมูล` or `ประเภท` depending on the context.
+- Words that do not require translation:
+    - `Pull Request`
+    - `Libraries`
+    - `E-book`
+    - `business logic`
+    - `Domain`
+
+
+# Prompt
+
+This page is special page that collect the prompt from generative AI for example GPT-3, GPT-4, etc. The prompt is used to generate the content for the page.
+
+## Localization Prompt List
+- [Thai Prompt](./th/prompt.md)
+```
\ No newline at end of file
diff --git a/packages/auto-translation/input.md b/packages/auto-translation/input.md
new file mode 100644
index 0000000..842edef
--- /dev/null
+++ b/packages/auto-translation/input.md
@@ -0,0 +1,45 @@
+# Project Setup and Structure
+
+## TypeScript Compiler Config
+
+The TypeScript compiler configuration file is `tsconfig.json`. This file is used to configure the TypeScript compiler. The TypeScript compiler uses this file to determine how to compile the project. Use `strict` mode to enable all strict type-checking options. This will help you catch more errors at compile time.
+
+```json
+{
+  "compilerOptions": {
+    "strict": true
+  }
+}
+```
+
+## Project Structure
+
+::: warning Disclaimer
+Organizing the project structure and types may vary depending on the project's size and complexity. From my experience, the following project structure design works well for most projects. However, the specific needs and context of a project might necessitate deviations from these practices. Flexibility and critical thinking are key in effectively applying these principles.
+:::
+
+### Module Organization
+
+**Modular Approach**: I typically organize my code and types in a modular fashion. This means creating smaller, self-contained modules rather than having everything in a single file. Functions or classes that work together frequently are placed in the same module. 
+
+This approach aligns with the Single Responsibility Principle (SRP) from SOLID principles, which encourages developers to structure their code such that each module or file has a single responsibility.
+
+### Type Definition Organization
+
+**Inline Types**: Types that are specific to a module (e.g., parameters for functions or classes) are defined within that module. This ensures that related types are close to the code that uses them. Because it makes the code more readable and easier to understand. This is particularly useful for types that are specific to a particular module and not reused elsewhere.
+
+**Shared Types**: For types that need to be used across multiple classes, I create a separate file, usually named `types.ts`, within the same module. This file contains shared interfaces or utility types specific to that module (domain strictly). This prevents type definitions from cluttering the main module file and keeps related types organized.
+
+**Common/Global Types**: There are also common types used across all modules, such as utility types that are not specific to any business logic or module. These are placed in a common directory, making them accessible to any part of the project. This ensures that such utility types are easily accessible and do not need to be duplicated.
+
+### Type Declaration Files
+
+I recommend avoiding the use of `.d.ts` files unless absolutely necessary. They should be used sparingly, as global declarations can be difficult to manage and maintain as the project grows. Additionally, they can lead to discrepancies between compile-time and runtime types, causing more complexity. Instead, define types within modules and use import paths or wildcard imports (`import * as types from ...`) to manage type imports efficiently.
+
+However, `.d.ts` files can be very useful for defining global types, especially when working with third-party libraries or when extending built-in types. Completely avoiding `.d.ts` files might not be practical in all scenarios. It’s important to balance their usage with careful management to avoid issues.
+
+### Summary
+
+The principles for organizing types are similar to those for organizing JavaScript code: separate by domain, module, and business logic. If you're using a type-safe framework, the need to write type definitions may be significantly reduced, as these frameworks often infer types automatically. In such cases, you mainly need to define data interfaces to complement the framework's type inference.
+
+This approach ensures a clean, maintainable project structure that scales well as the project grows.
\ No newline at end of file
diff --git a/packages/auto-translation/main.ts b/packages/auto-translation/main.ts
new file mode 100644
index 0000000..50b17f7
--- /dev/null
+++ b/packages/auto-translation/main.ts
@@ -0,0 +1,54 @@
+export interface ChatGptMarkdownTranslatorOptions {
+  /**
+   * Model (`MODEL_NAME`)
+
+     This is the setting that has the greatest impact on translation accuracy (and price!). Set this to one of the [Chat models](https://platform.openai.com/docs/models/) accepted by the OpenAI API.
+
+     ```markdown
+     - Recommended:
+       - `gpt-4-turbo` (or using shortcut `4`)
+       - `gpt-3.5-turbo` (or using shortcut `3`)
+     - Legacy / No longer recommended:
+       - `gpt-4`
+       - `gpt-4-32k` (or using shortcut `4large`)
+       - `gpt-3.5-turbo-16k` (or using shortcut `3large`)
+     ```
+
+     Shortcuts (in brackets) are available. Starting from v1.7.0, the shortcut `4` points to `gpt-4-turbo` rather than `gpt-4`.
+
+     Although GPT-4 is much smarter, it is slower and much more expensive than GPT-3. Try using the GPT-3 model first, especially while you are experimenting with this tool. It's recommended to set the usage limit to a reasonable amount (e.g., $10) on the OpenAI's account management page.
+   */
+  model?: "3" | "4" | "gpt-3.5-turbo" | "gpt-4o";
+  inputPath: string;
+  outputPath: string;
+  cwd?: string;
+}
+
+async function chatGptMarkdownTranslator(options: ChatGptMarkdownTranslatorOptions) {
+  console.log(
+    `Starting translation with input file: "${options.inputPath}" and output file: "${options.outputPath}"...`
+  );
+
+  const model = options.model ?? "gpt-3.5-turbo";
+  console.log(`Translation starting with model: "${model}"...`);
+  console.log('Env: ', process.env.OPENAI_API_KEY)
+  Bun.spawn(
+    ["node_modules/.bin/chatgpt-md-translator", "--model", model, "--out", options.outputPath, options.inputPath],
+    {
+      cwd: options.cwd,
+      env: { ...process.env }, // specify environment variables
+      onExit(proc, exitCode, signalCode, error) {
+        // exit handler
+      },
+      stdout: "inherit",
+    }
+  );
+  console.log(`Translation completed`);
+}
+
+await chatGptMarkdownTranslator({
+  model: "gpt-3.5-turbo",
+  inputPath: `./input.md`,
+  outputPath: `./output.md`,
+  cwd: import.meta.dirname,
+});
diff --git a/packages/auto-translation/output-prompt-eng.md b/packages/auto-translation/output-prompt-eng.md
new file mode 100644
index 0000000..d6ad69d
--- /dev/null
+++ b/packages/auto-translation/output-prompt-eng.md
@@ -0,0 +1,45 @@
+# Project Setup and Structure
+
+## TypeScript Compiler Config
+
+The TypeScript compiler configuration file is `tsconfig.json`. This file is used to configure the TypeScript compiler. The TypeScript compiler uses this file to determine how to compile the project. Use `strict` mode to enable all strict type-checking options. This will help you catch more errors at compile time.
+
+```json
+{
+  "compilerOptions": {
+    "strict": true
+  }
+}
+```
+
+## Project Structure
+
+::: warning คำชี้แจงที่สำคัญ
+การจัดโครงสร้างโปรเจกต์และชนิดข้อมูลอาจแตกต่างกันไปขึ้นอยู่กับขนาดและความซับซ้อนของโปรเจกต์ จากประสบการณ์ของผม การออกแบบโครงสร้างโปรเจกต์ดังต่อไปนี้ทำงานได้ดีสำหรับโปรเจกต์ส่วนใหญ่ อย่างไรก็ตาม ความต้องการและบริบทเฉพาะของโปรเจกต์อาจจำเป็นต้องมีการเบี่ยงเบนจากแนวปฏิบัติเหล่านี้ ความยืดหยุ่นและการคิดวิเคราะห์เป็นกุญแจสำคัญในการนำหลักการเหล่านี้ไปใช้อย่างมีประสิทธิภาพ
+:::
+
+### Module Organization
+
+**โมดูล Approach**: ผมมักจะจัดโค้ดและชนิดข้อมูลของตัวเองในรูปแบบโมดูล ซึ่งหมายถึงการสร้างโมดูลขนาดเล็กที่มีความเป็นอิสระแทนที่จะมีทุกอย่างในไฟล์เดียว ฟังก์ชันหรือคลาสที่ทำงานร่วมกันบ่อยๆ จะถูกวางไว้ในโมดูลเดียวกัน
+
+แนวทางนี้สอดคล้องกับหลักการ Single Responsibility Principle (SRP) จากหลักการ SOLID ซึ่งสนับสนุนให้นักพัฒนาจัดโครงสร้างโค้ดของตัวเองให้แต่ละโมดูลหรือไฟล์มีความรับผิดชอบเดียว
+
+### Type Definition Organization
+
+**ชนิดข้อมูลแบบใกล้เคียง**: ชนิดข้อมูลที่เฉพาะเจาะจงกับโมดูล (เช่น พารามิเตอร์สำหรับฟังก์ชันหรือคลาส) จะถูกกำหนดภายในโมดูลนั้นๆ สิ่งนี้ทำให้ชนิดข้อมูลที่เกี่ยวข้องอยู่ใกล้กับโค้ดที่ใช้งานพวกมัน เพราะมันทำให้โค้ดอ่านง่ายและเข้าใจง่ายขึ้น สิ่งนี้มีประโยชน์โดยเฉพาะสำหรับชนิดข้อมูลที่เฉพาะเจาะจงกับโมดูลใดโมดูลหนึ่งและไม่ถูกใช้งานซ้ำที่อื่น
+
+**ชนิดข้อมูลที่ใช้ร่วมกัน**: สำหรับชนิดข้อมูลที่จำเป็นต้องใช้ในหลายคลาส ผมจะสร้างไฟล์แยกต่างหาก โดยปกติจะตั้งชื่อว่า `types.ts` ภายในโมดูลเดียวกัน ไฟล์นี้จะมี interface หรือชนิดข้อมูล utility ที่เฉพาะเจาะจงกับโมดูลนั้น (domain strictly) สิ่งนี้ป้องกันไม่ให้การประกาศชนิดข้อมูลทำให้ไฟล์โมดูลหลักรกและช่วยให้ชนิดข้อมูลที่เกี่ยวข้องถูกจัดระเบียบ
+
+**ชนิดข้อมูลทั่วไป/ใช้ร่วมกันทั้งโปรเจกต์**: มีชนิดข้อมูลทั่วไปที่ใช้ในทุกโมดูล เช่น ชนิดข้อมูลที่เป็น utility ที่ไม่เฉพาะเจาะจงกับ business logic หรือโมดูลใด ๆ ชนิดข้อมูลเหล่านี้จะถูกวางไว้ในไดเรกทอรีทั่วไป ทำให้สามารถเข้าถึงได้จากทุกส่วนของโปรเจกต์ ซึ่งช่วยให้ชนิดข้อมูล utility เหล่านี้สามารถเข้าถึงได้ง่ายและไม่จำเป็นต้องทำซ้ำ
+
+### ไฟล์การประกาศชนิดข้อมูล
+
+ผมแนะนำให้หลีกเลี่ยงการใช้ไฟล์ `.d.ts` เว้นแต่จำเป็นจริง ๆ ควรใช้ไฟล์เหล่านี้อย่างประหยัด เพราะการประกาศสำหรับใช้ร่วมกันทั้งโปรเจกต์อาจจะจัดการและดูแลรักษาได้ยากเมื่อโปรเจกต์เติบโตขึ้น นอกจากนี้ยังอาจทำให้เกิดความไม่สอดคล้องกันระหว่างชนิดข้อมูลในช่วงคอมไพล์และช่วงรันไทม์ ทำให้เกิดความซับซ้อนมากขึ้น แทนที่จะทำเช่นนั้น ควรประกาศชนิดข้อมูลภายในโมดูลและใช้ import paths หรือ wildcard imports (`import * as types from ...`) เพื่อจัดการการนำเข้าชนิดข้อมูลอย่างมีประสิทธิภาพ
+
+อย่างไรก็ตาม ไฟล์ `.d.ts` สามารถมีประโยชน์มากในการประกาศชนิดข้อมูลสำหรับใช้ร่วมกันทั้งโปรเจกต์ โดยเฉพาะเมื่อทำงานกับไลบรารีที่ติดตั้งจากภายนอกหรือเมื่อขยายชนิดข้อมูลที่มีมาให้ใช้งานเริ่มต้น การหลีกเลี่ยงไฟล์ `.d.ts` อย่างสมบูรณ์อาจไม่เป็นไปได้ในทุกสถานการณ์ สิ่งสำคัญคือการจัดการการใช้งานอย่างระมัดระวังเพื่อหลีกเลี่ยงปัญหา
+
+### สรุป
+
+หลักการในการจัดระเบียบชนิดข้อมูลคล้ายกับการจัดระเบียบโค้ด JavaScript: แยกตาม domain, โมดูล, และ business logic หากคุณใช้เฟรมเวิร์กชนิดข้อมูลแบบปลอดภัย ความจำเป็นในการเขียนการประกาศชนิดข้อมูลอาจลดลงอย่างมาก เนื่องจากเฟรมเวิร์กเหล่านี้มักจะคาดเดาชนิดข้อมูลโดยอัตโนมัติ ในกรณีเช่นนี้ คุณเพียงแค่ต้องประกาศ interface ของข้อมูลเพื่อเสริมการคาดเดาชนิดข้อมูลของเฟรมเวิร์ก
+
+วิธีการนี้ช่วยให้โครงสร้างโปรเจกต์สะอาดและดูแลรักษาง่าย ซึ่งสามารถขยายได้ดีเมื่อโปรเจกต์เติบโตขึ้น
diff --git a/packages/auto-translation/output.md b/packages/auto-translation/output.md
new file mode 100644
index 0000000..a8b89d4
--- /dev/null
+++ b/packages/auto-translation/output.md
@@ -0,0 +1,45 @@
+# การตั้งค่าและโครงสร้างโปรเจกต์
+
+## การตั้งค่าคอมไพเลอร์ TypeScript
+
+ไฟล์การตั้งค่าคอมไพเลอร์ TypeScript คือ `tsconfig.json` ไฟล์นี้ใช้สำหรับตั้งค่าคอมไพเลอร์ TypeScript คอมไพเลอร์ TypeScript จะใช้ไฟล์นี้เพื่อกำหนดวิธีการคอมไพล์โปรเจกต์ ใช้โหมด `strict` เพื่อเปิดใช้งานตัวเลือกการตรวจสอบชนิดข้อมูลแบบเข้มงวดทั้งหมด ซึ่งจะช่วยให้คุณเจอข้อผิดพลาดมากขึ้นในขณะคอมไพล์
+
+```json
+{
+  "compilerOptions": {
+    "strict": true
+  }
+}
+```
+
+## โครงสร้างโปรเจกต์
+
+::: warning คำชี้แจงที่สำคัญ
+การจัดโครงสร้างโปรเจกต์และชนิดข้อมูลอาจแตกต่างกันไปขึ้นอยู่กับขนาดและความซับซ้อนของโปรเจกต์ จากประสบการณ์ของผม การออกแบบโครงสร้างโปรเจกต์ดังต่อไปนี้ทำงานได้ดีสำหรับโปรเจกต์ส่วนใหญ่ อย่างไรก็ตาม ความต้องการและบริบทเฉพาะของโปรเจกต์อาจจำเป็นต้องมีการปรับเปลี่ยนจากแนวปฏิบัติเหล่านี้ ความยืดหยุ่นและการคิดวิเคราะห์เป็นกุญแจสำคัญในการนำหลักการเหล่านี้ไปใช้อย่างมีประสิทธิภาพ
+:::
+
+### การจัดการโมดูล
+
+**แนวทางโมดูล (Modular Approach)**: ผมมักจะจัดโค้ดและชนิดข้อมูลในลักษณะโมดูล ซึ่งหมายถึงการสร้างโมดูลขนาดเล็กที่มีความเป็นอิสระแทนที่จะมีทุกอย่างในไฟล์เดียว ฟังก์ชันหรือคลาสที่ทำงานร่วมกันบ่อยๆ จะถูกวางไว้ในโมดูลเดียวกัน
+
+แนวทางนี้สอดคล้องกับหลักการ Single Responsibility Principle (SRP) จากหลักการ SOLID ซึ่งสนับสนุนให้นักพัฒนาจัดโครงสร้างโค้ดของตนให้แต่ละโมดูลหรือไฟล์มีความรับผิดชอบเดียว
+
+### การจัดการการประกาศชนิดข้อมูล
+
+**ชนิดข้อมูลแบบใกล้เคียง (Inline Types)**: ชนิดข้อมูลที่เฉพาะเจาะจงกับโมดูล (เช่น พารามิเตอร์สำหรับฟังก์ชันหรือคลาส) จะถูกประกาศภายในโมดูลนั้นๆ เพื่อให้แน่ใจว่าชนิดข้อมูลที่เกี่ยวข้องอยู่ใกล้กับโค้ดที่ใช้งานพวกมัน เพราะมันทำให้โค้ดอ่านง่ายและเข้าใจง่ายขึ้น ซึ่งมีประโยชน์อย่างยิ่งสำหรับชนิดข้อมูลที่เฉพาะเจาะจงกับโมดูลใดโมดูลหนึ่งและไม่ถูกใช้งานที่อื่น
+
+**ชนิดข้อมูลที่ใช้ร่วมกัน (Shared Types)**: สำหรับชนิดข้อมูลที่ต้องใช้ในหลายคลาส ผมจะสร้างไฟล์แยกต่างหาก โดยปกติจะตั้งชื่อว่า `types.ts` ภายในโมดูลเดียวกัน ไฟล์นี้จะประกอบด้วย interface หรือชนิดข้อมูลยูทิลิตี้ที่ใช้ร่วมกันเฉพาะในโมดูลนั้น (domain strictly) ซึ่งจะช่วยป้องกันไม่ให้การประกาศชนิดข้อมูลทำให้ไฟล์โมดูลหลักรกและทำให้ชนิดข้อมูลที่เกี่ยวข้องถูกจัดระเบียบ
+
+**ชนิดข้อมูลทั่วไป/ใช้ร่วมกันทั้งโปรเจกต์**: มีชนิดข้อมูลทั่วไปที่ใช้ร่วมกันในทุกโมดูล เช่น ชนิดข้อมูลที่เป็น utility ที่ไม่เฉพาะเจาะจงกับ business logic หรือโมดูลใดๆ โดยจะถูกวางไว้ในไดเรกทอรีที่ใช้ร่วมกัน ทำให้สามารถเข้าถึงได้จากทุกส่วนของโปรเจกต์ ซึ่งจะช่วยให้ชนิดข้อมูลเหล่านี้สามารถเข้าถึงได้ง่ายและไม่จำเป็นต้องทำซ้ำ
+
+### ไฟล์การประกาศชนิดข้อมูล
+
+ผมแนะนำให้หลีกเลี่ยงการใช้ไฟล์ `.d.ts` เว้นแต่จำเป็นจริงๆ ควรใช้เท่าที่จำเป็นเท่านั้น เนื่องจากการประกาศสำหรับใช้ร่วมกันทั้งโปรเจกต์อาจจะจัดการและบำรุงรักษาได้ยากเมื่อโปรเจกต์เติบโตขึ้น นอกจากนี้ยังอาจทำให้เกิดความไม่สอดคล้องกันระหว่างชนิดข้อมูลในช่วงคอมไพล์และช่วงรันไทม์ ทำให้เกิดความซับซ้อนมากขึ้น แทนที่จะใช้ไฟล์ `.d.ts` ให้ประกาศชนิดข้อมูลภายในโมดูลและใช้ import paths หรือ wildcard imports (`import * as types from ...`) เพื่อจัดการการนำเข้าชนิดข้อมูลอย่างมีประสิทธิภาพ
+
+อย่างไรก็ตาม ไฟล์ `.d.ts` สามารถมีประโยชน์มากในการประกาศชนิดข้อมูลสำหรับใช้ร่วมกันทั้งโปรเจกต์ โดยเฉพาะเมื่อทำงานกับไลบรารีที่ติดตั้งจากภายนอกหรือเมื่อขยายชนิดข้อมูลที่มีมาให้ใช้งานเริ่มต้น การหลีกเลี่ยงไฟล์ `.d.ts` อย่างสมบูรณ์อาจไม่เป็นไปได้ในทุกสถานการณ์ จึงสำคัญที่จะต้องใช้ด้วยการจัดการอย่างระมัดระวังเพื่อหลีกเลี่ยงปัญหา
+
+### สรุป
+
+หลักการในการจัดการชนิดข้อมูลคล้ายกับการจัดการโค้ด JavaScript: แยกตาม domain, โมดูล, และ business logic หากคุณใช้เฟรมเวิร์กชนิดข้อมูลแบบปลอดภัย ความจำเป็นในการเขียนการประกาศชนิดข้อมูลอาจลดลงอย่างมาก เนื่องจากเฟรมเวิร์กเหล่านี้มักจะคาดเดาชนิดข้อมูลโดยอัตโนมัติ ในกรณีเช่นนี้ คุณเพียงแค่ต้องประกาศ interface ของข้อมูลเพื่อเสริมการคาดเดาชนิดข้อมูลของเฟรมเวิร์ก
+
+วิธีการนี้จะช่วยให้โครงสร้างโปรเจกต์สะอาดและบำรุงรักษาได้ง่าย ซึ่งสามารถขยายตัวได้ดีเมื่อโปรเจกต์เติบโตขึ้น
diff --git a/packages/auto-translation/prompt-gpt-3.5-turbo.md b/packages/auto-translation/prompt-gpt-3.5-turbo.md
new file mode 100644
index 0000000..4a0d3b6
--- /dev/null
+++ b/packages/auto-translation/prompt-gpt-3.5-turbo.md
@@ -0,0 +1,15 @@
+You must strictly follow the rules below to translate to Thai:
+
+- Never add extra html or Markdown markup structure.
+- Never change the Markdown markup structure. Don't add or remove links. Do not change any URL.
+- Never change the contents of code blocks even if they appear to have a bug.
+- Always preserve the original line breaks. Do not add or remove blank lines.
+- Never touch HTML-like tags such as `<Notes>`.
+- Never touch the Vitepress's Markdown syntax such as `::: tip`, `::: warning`, `::: details`, etc.
+- Always translate words that do not require parentheses with the original English term in the following the rules: `Example`, `Error`, `Contributing`, `Glossary`
+- Do not translate the following words: `Pull Request`, `Libraries`, `E-book`, `business logic`, `Domain`, `template literal types`, `Prompt`
+- Always choosing Thai words following the rules: The word `ฉัน` should be replaced with `ผม`. The word `ของตน` should be replaced with `ของตัวเอง`. The word `การอนุมาน` should be replaced with `การคาดเดา`.
+- Always choosing translations from English, where if a term is mentioned for the first time in the entire translated document, it should be followed by the original English term in parentheses in the following the rules: The term `Type-safe` should be translated as `ชนิดข้อมูลแบบปลอดภัย`. The term `Best Practice` should be translated as `แนวปฏิบัติที่ดีนำไปใช้งานได้จริง`. The term `Design Pattern` should be translated as `แนวทางการออกแบบ`. The term `Modular` should be translated as `โมดูล`. The term `Inline Types` should be translated as `ชนิดข้อมูลแบบใกล้เคียง`. The term `Shared Types` should be translated as `ชนิดข้อมูลที่ใช้ร่วมกัน`. The term `Common/Global Types` should be translated as `ชนิดข้อมูลทั่วไป/ใช้ร่วมกันทั้งโปรเจกต์`. The term `global declarations` should be translated as `การประกาศสำหรับใช้ร่วมกันทั้งโปรเจกต์`. The term `global types` should be translated as `ชนิดข้อมูลสำหรับใช้ร่วมกันทั้งโปรเจกต์`. The term `third-party libraries` should be translated as `ไลบรารีที่ติดตั้งจากภายนอก`. The term `built-in types` should be translated as `ชนิดข้อมูลที่มีมาให้ใช้งานเริ่มต้น`.
+- Always choosing translations from English in the following the rules: The term `Modern` should be translated as `สมัยใหม่`. The term `Prerequisites` should be translated as `สิ่งที่ควรเรียนรู้มาก่อน`. The term `Recommended Reading` should be translated as `หนังสือและเอกสารที่แนะนำให้อ่าน`. The term `Disclaimer` should be translated as `คำชี้แจงที่สำคัญ`. The phrase `open an issue ... on Github` should be translated as `เปิด Issue ... บน Github`. The term `Traditional Type` should be translated as `การประกาศชนิดข้อมูลแบบดั้งเดิม`. The term `type inference` should be translated as `การคาดเดาชนิดข้อมูล`. The term `type system` should be translated as `ระบบชนิดข้อมูล`. The terms `definition of types` or `type definition` should be translated as `การประกาศชนิดข้อมูล`. The phrase `Let's break down` should be translated as `ลองพยายามอธิบาย`. The term `Type loosing` should be translated as `การทำให้ชนิดข้อมูลหลวมลง`. The term `Type tightening` should be translated as `การทำให้ชนิดข้อมูลเข้มข้นขึ้น`. The term `codebase` should be translated as `โค้ด`. The term `TypeScript Libraries` should be translated as `ไลบรารี TypeScript`. The term `Glossary` should be translated as `คลังคำศัพท์`. The term `Project` should be translated as `โปรเจกต์`. The phrase `catch ... errors` should be translated as `เจอ ... ข้อผิดพลาด`. The term `data interfaces` should be translated as `interface ของข้อมูล`.
+- Always choosing words based on context, which may be translated differently in various places, in the following the rules: The term `Type` may be translated as `ชนิดข้อมูล` or `ประเภท` depending on the context.
+
diff --git a/packages/auto-translation/prompt-gpt-4o.md b/packages/auto-translation/prompt-gpt-4o.md
new file mode 100644
index 0000000..7fc9da0
--- /dev/null
+++ b/packages/auto-translation/prompt-gpt-4o.md
@@ -0,0 +1,57 @@
+Translate to Thai and you must strictly follow the rules below:
+
+- Never change the Markdown markup structure. Don't add or remove links. Do not change any URL.
+- Never change the contents of code blocks even if they appear to have a bug.
+- Always preserve the original line breaks. Do not add or remove blank lines.
+- Never touch the permalink such as `{/*examples*/}` at the end of each heading.
+- Never touch HTML-like tags such as `<Notes>`.
+- Never touch the Vitepress's Markdown syntax such as `::: tip`, `::: warning`, `::: details`, etc.
+- Always choosing Thai words following nested list below:
+    - The word `ฉัน` should be replaced with `ผม`.
+    - The word `ของตน` should be replaced with `ของตัวเอง`.
+    - The word `การอนุมาน` should be replaced with `การคาดเดา`.
+- Always choosing choosing translations from English, where if a term is mentioned for the first time in the entire translated document, it should be followed by the original English term in parentheses in the following nested list below:
+    - The term `Type-safe` should be translated as `ชนิดข้อมูลแบบปลอดภัย`.
+    - The term `Best Practice` should be translated as `แนวปฏิบัติที่ดีนำไปใช้งานได้จริง`.
+    - The term `Design Pattern` should be translated as `แนวทางการออกแบบ`.
+    - The term `Modular` should be translated as `โมดูล`.
+    - The term `Inline Types` should be translated as `ชนิดข้อมูลแบบใกล้เคียง`.
+    - The term `Shared Types` should be translated as `ชนิดข้อมูลที่ใช้ร่วมกัน`.
+    - The term `Common/Global Types` should be translated as `ชนิดข้อมูลทั่วไป/ใช้ร่วมกันทั้งโปรเจกต์`.
+    - The term `global declarations` should be translated as `การประกาศสำหรับใช้ร่วมกันทั้งโปรเจกต์`.
+    - The term `global types` should be translated as `ชนิดข้อมูลสำหรับใช้ร่วมกันทั้งโปรเจกต์`.
+    - The term `third-party libraries` should be translated as `ไลบรารีที่ติดตั้งจากภายนอก`.
+    - The term `built-in types` should be translated as `ชนิดข้อมูลที่มีมาให้ใช้งานเริ่มต้น`.
+- Words that do not require parentheses with the original English term in the following nested list below:
+    - `Example`
+    - `Error`
+    - `Contributing`
+    - `Glossary`
+- Choosing translations from English in the following nested list below:
+    - The term `Modern` should be translated as `สมัยใหม่`.
+    - The term `Prerequisites` should be translated as `สิ่งที่ควรเรียนรู้มาก่อน`.
+    - The term `Recommended Reading` should be translated as `หนังสือและเอกสารที่แนะนำให้อ่าน`.
+    - The term `Disclaimer` should be translated as `คำชี้แจงที่สำคัญ`.
+    - The phrase `open an issue ... on Github` should be translated as `เปิด Issue ... บน Github`.
+    - The term `Traditional Type` should be translated as `การประกาศชนิดข้อมูลแบบดั้งเดิม`.
+    - The term `type inference` should be translated as `การคาดเดาชนิดข้อมูล`.
+    - The term `type system` should be translated as `ระบบชนิดข้อมูล`.
+    - The terms `definition of types` or `type definition` should be translated as `การประกาศชนิดข้อมูล`.
+    - The phrase `Let's break down` should be translated as `ลองพยายามอธิบาย`.
+    - The term `Type loosing` should be translated as `การทำให้ชนิดข้อมูลหลวมลง`.
+    - The term `Type tightening` should be translated as `การทำให้ชนิดข้อมูลเข้มข้นขึ้น`.
+    - The term `codebase` should be translated as `โค้ด`.
+    - The term `TypeScript Libraries` should be translated as `ไลบรารี TypeScript`.
+    - The term `Glossary` should be translated as `คลังคำศัพท์`.
+    - The term `Project` should be translated as `โปรเจกต์`.
+    - The phrase `catch ... errors` should be translated as `เจอ ... ข้อผิดพลาด`.
+    - The term `data interfaces` should be translated as `interface ของข้อมูล`.
+- Choosing words based on context, which may be translated differently in various places, in the following nested list below:
+    - The term `Type` may be translated as `ชนิดข้อมูล` or `ประเภท` depending on the context.
+- Words that do not require translation, in the following nested list below:
+    - `Pull Request`
+    - `Libraries`
+    - `E-book`
+    - `business logic`
+    - `Domain`
+    - `template literal types`
diff --git a/packages/auto-translation/prompt.md b/packages/auto-translation/prompt.md
new file mode 100644
index 0000000..5cd6218
--- /dev/null
+++ b/packages/auto-translation/prompt.md
@@ -0,0 +1,50 @@
+แปลไทยโดยมีเงื่อนไขดังนี้
+
+- การเลือกใช้คำภาษาไทย
+  - คำว่า `ฉัน` ให้ใช้คำว่า `ผม` แทน
+  - คำว่า `ของตน` ให้ใช้คำว่า `ของตัวเอง` แทน
+  - คำว่า `การอนุมาน` ให้ใช้คำว่า `การคาดเดา` แทน
+- การเลือกคำแปลจาก ภาษาอังกฤษเป็นภาษาไทย โดยที่ถ้าพูดถึงคำนั้นครั้งแรกของเอกสารที่แปลทั้งหมด ให้ใส่วงเล็บเพื่อใส่ภาษาอังกฤษที่เป็นคำเดิมไว้ด้วย
+  - คำว่า `Type-safe` ให้แปลว่า `ชนิดข้อมูลแบบปลอดภัย`
+  - คำว่า `Best Practice` ให้แปลว่า `แนวปฏิบัติที่ดีนำไปใช้งานได้จริง`
+  - คำว่า `Design Pattern` ให้แปลว่า `แนวทางการออกแบบ`
+  - คำว่า `Modular` ให้แปลว่า `โมดูล`
+  - คำว่า `Inline Types` ให้แปลว่า `ชนิดข้อมูลแบบใกล้เคียง`
+  - คำว่า `Shared Types` ให้แปลว่า `ชนิดข้อมูลที่ใช้ร่วมกัน`
+  - คำว่า `Common/Global Types` ให้แปลว่า `ชนิดข้อมูลทั่วไป/ใช้ร่วมกันทั้งโปรเจกต์`
+  - คำว่า `global declarations` ให้แปลว่า `การประกาศสำหรับใช้ร่วมกันทั้งโปรเจกต์`
+  - คำว่า `global types` ให้แปลว่า `ชนิดข้อมูลสำหรับใช้ร่วมกันทั้งโปรเจกต์`
+  - คำว่า `third-party libraries` ให้แปลว่า `ไลบรารีที่ติดตั้งจากภายนอก`
+  - คำว่า `built-in types` ให้แปลว่า `ชนิดข้อมูลที่มีมาให้ใช้งานเริ่มต้น`
+- คำที่ไม่ต้องการให้มีวงเล็บภาษาอังกฤษที่เป็นคำเดิม
+  - `Example`
+  - `Error`
+  - `Contributing`
+  - `Glossary`
+- การเลือกคำแปลจาก ภาษาอังกฤษเป็นภาษาไทย
+  - คำว่า `Modern` ให้แปลว่า `สมัยใหม่`
+  - คำว่า `Prerequisites` ให้แปลว่า `สิ่งที่ควรเรียนรู้มาก่อน`
+  - คำว่า `Recommended Reading` ให้แปลว่า `หนังสือและเอกสารที่แนะนำให้อ่าน` 
+  - คำว่า `Disclaimer` ให้แปลว่า `คำชี้แจงที่สำคัญ`
+  - คำว่า `open an issue ... on Github` ให้แปลว่า `เปิด Issue ... บน Github`
+  - คำว่า `Traditional Type` ให้แปลว่า `การประกาศชนิดข้อมูลแบบดั้งเดิม`
+  - คำว่า `type inference` ให้แปลว่า `การคาดเดาชนิดข้อมูล`
+  - คำว่า `type system` ให้แปลว่า `ระบบชนิดข้อมูล`
+  - คำว่า `definition of types` หรือ `type definition` ให้แปลว่า `การประกาศชนิดข้อมูล`
+  - คำว่า `Let's break down` ให้แปลว่า `ลองพยายามอธิบาย`
+  - คำว่า `Type loosing` ให้แปลว่า `การทำให้ชนิดข้อมูลหลวมลง`
+  - คำว่า `Type tightening` ให้แปลว่า `การทำให้ชนิดข้อมูลเข้มข้นขึ้น`
+  - คำว่า `codebase` ให้แปลว่า `โค้ด`
+  - คำว่า `TypeScript Libraries` ให้แปลว่า `ไลบรารี TypeScript`
+  - คำว่า `Glossary` ให้แปลว่า `คลังคำศัพท์`
+  - คำว่า `Project` ให้แปลว่า `โปรเจกต์`
+  - คำว่า `catch ... errors` ให้แปลว่า `เจอ ... ข้อผิดพลาด`
+  - คำว่า `data interfaces` ให้แปลว่า `interface ของข้อมูล`
+- การเลือกคำคำที่มีบริบทข้างเคียง ซึ่งแต่ละที่อาจจะแปลไม่เหมือนกัน
+  - คำว่า `Type` อาจจะแปลว่า `ชนิดข้อมูล` หรือ `ประเภท` ให้พิจารณาจากบริบทข้างเคียง
+- คำที่ไม่ต้องการแปล
+  - `Pull Request` 
+  - `Libraries`
+  - `E-book`
+  - `business logic`
+  - `Domain`
\ No newline at end of file