docs: types page translated into Korean

[Gaic4o]

Background

I have translated the examples Authentication page into Korean.

If you think there are aspects that need improvement, please let me know, and I would be happy to make the adjustments. Thank you!

[netlify]

👷 Deploy request for pr-fsd accepted.

Name	Link
🔨 Latest commit	6b45813
🔍 Latest deploy log	https://app.netlify.com/sites/pr-fsd/deploys/671fac2c0e72c700080d873b

[movie42]

번역 감사합니다.

해당 부분 읽으면서 타입 위치에 대한 인사이트를 얻어갑니다. (제가 이해를 잘못한것도 있더군요ㅎㅎ ㅜㅠ)

Reqeust Change는 오타와 로마자 한국어 표기법에 대한 규칙(논의가 필요합니다.) 그리고 typescript 용어 표기(Generic Type)에 대한 부분 때문에 넣었습니다.

나머지 사항은 조금 번거로우시겠지만 Gaic4o님과 활발한 토론을 기대합니다.

[movie42]

temptation이라는 단어가 문장에 포함되어있어 '세그먼트를 추가하고 싶겠지만 하지 마세요.'의 늬앙스가 더 강조되면 좋을 것 같습니다.

하지만 저의 의견은 제가 그냥 그런 늬앙스를 느낀것을 말씀 드린 뿐 수정 요청을 드리는건 아닙니다.

[Gaic4o]

피드백 해 주신 데로 원본 문장을 좀 더 반영해서 수정 해 봤어요!
shared/types 폴더를 생성하거나 각 슬라이스에 types라는 세그먼트를 추가하고 싶은 마음이 들 수 있지만, 그렇게 하지 않는 것이 좋습니다.types라는 카테고리는 components나 hooks와 마찬가지로 내용이 무엇인지를 설명할 뿐, 코드의 목적을 명확히 설명하지 않습니다. 슬라이스는 해당 코드의 목적을 정확히 설명할 수 있어야 합니다. 이런 식으로 수정했습니다!

[movie42]

Suggested change

	2. **croess-import (공용 API를 사용해 관리하기)**
	2. **Cross-import (공용 API를 사용해 관리하기)**

오타가 있네요. 수정해주세용!

[Gaic4o]

감사합니다!

[movie42]

Suggested change

	### mappers의 위치
	mappers는 DTO를 받아 변환하는 역할을 하므로, DTO 정의와 가까운 위치에 두는 것이 좋습니다. 만약 요청과 DTO가 `shared/api`에 정의되어 있다면, mappers도 그곳에 위치하는 것이 적절합니다.
	### Mappers의 위치
	Mappers는 DTO를 받아 변환하는 역할을 하므로, DTO 정의와 가까운 위치에 두는 것이 좋습니다. 만약 요청과 DTO가 `shared/api`에 정의되어 있다면, mappers도 그곳에 위치하는 것이 적절합니다.

한국어 표기법에서 mappers가 문장 시작에 대문자로 표기되어야한다는 규칙이 있는지 잘은 모르겠지만

문화 관광부에서 배포한 공공 용어의 외국어 번역 및 표기 지침의 제2장 기본지침 제4조 1항 2번 규칙을 차용하는 것을 제안드립니다.

[Gaic4o]

좋은 피드백 해주셔서 감사합니다! 반영 해 놓겠습니다.

[movie42]

이런 상황에서는 entities 간의 상호 참조를 피하기 어렵습니다.
라고 번역하신 문장에서
(unless we want to discard the data or have a firm conversation with the backend team)
이 문장이 생략되어있는데 포함하는 것이 더 좋을 것 같습니다.

[Gaic4o]

포함하는 게 이러한 경우 ...부터 문장 흐름이 잘 와닿고 이해가 가는 것 같아요. 피드백 해주셔서 감사합니다.
데이터를 지우거나 백엔드 팀과 협의하지 않는 한, 이러한 경우에는 슬라이스 간 간접적인 연결 대신 명시적인 교차 참조를 사용하는 것이 좋습니다. 이를 위해 @x 표기법을 활용할 수 있으며, 다음은 Redux Toolkit을 사용한 예시입니다: 수정해서 반영했습니다!

[movie42]

Suggested change

	1. 애플리케이션 특성이 없는 일반 타입
	1. 애플리케이션 특성이 없는 제네릭 타입

일반 타입을 제네릭 타입이라고 제안드리는 이유는 typescript 공식 문서에서 제네릭 타입이라고 명시하고 있고 Generic types를 일반적으로 제네릭 타입이라고 부르기 때문입니다.

[Gaic4o]

좋은 피드백 해주셔서 감사합니다.

[movie42]

Suggested change

	첫 번째 경우에는 관련 타입을 적절한 세그먼트의 Shared 폴더에 배치하면 됩니다. 예를 들어, 분석 전역 변수를 위한 인터페이스가 있다면 `shared/analytics`에 두는 것이 좋습니다.
	첫 번째 경우에는 관련 타입을 Shared 폴더 안에 적절한 세그먼트로 배치하면 됩니다. 예를 들어, 분석 전역 변수를 위한 인터페이스가 있다면 `shared/analytics`에 두는 것이 좋습니다.

적절한 세그먼트의 Shared 폴더에 라는 문장이 조금 생각해야 이해할 수 있는듯 하여 순서와 조사를 변경하여 번역하는 것을 제안드립니다.

[Gaic4o]

알려주신 내용이 좀 더 잘 와닿는 것 같아요. 제가 세그먼트와 Shared 순서가 약간 엇갈리게 번역해서 작성한 것 같네요. 감사합니다.

[movie42]

이 부분도 위에서 언급드린 '폴더 생성을 하지 마세요'라는 늬앙스를 번역에 표현하는 것을 제안드립니다.

[Gaic4o]

감사합니다 경고: shared/types 폴더를 생성하지 않는 것이 좋습니다. "타입"이라는 공통된 속성으로 관련 없는 항목들을 그룹화하면, 프로젝트에서 코드를 검색할 때 효율성이 떨어질 수 있습니다. 문장으로 다시 수정해서 올렸습니다!

[movie42]

Suggested change

	[검증 스키마는 데이터를 파싱하며, 파싱에 실패하면 오류를 발생시킵니다](#data-transfer-objects-and-mappers). 가장 일반적인 검증 사례 중 하나는 백엔드에서 오는 데이터에 대한 것입니다. 데이터가 스키마와 일치하지 않는 경우 요청을 실패시키기를 원하기 때문에, 보통 `api` 세그먼트에 스키마를 두는 것이 좋습니다.
	검증 스키마는 데이터를 파싱하며, 파싱에 실패하면 오류를 발생시킵니다.([Data transfoer objects and mappers](#data-transfer-objects-and-mappers) 토론을 참조하세요.)
	가장 일반적인 검증 사례 중 하나는 백엔드에서 오는 데이터에 대한 것입니다. 데이터가 스키마와 일치하지 않는 경우 요청을 실패시키기를 원하기 때문에, 보통 `api` 세그먼트에 스키마를 두는 것이 좋습니다.

축약한 것은 번역과 원문의 의미에도 별다른 차이는 없지만 원문에서 단락으로 나눈 것을 그대로 반영하고 링크는 원문 표현을 조금더 반영하면 좋을 것 같아 위와 같이 제안드립니다.

[Gaic4o]

좋은 피드백 해주셔서 감사합니다. 반영 해 놓았습니다!

[Chun-gu]

Suggested change

	## 비즈니스 entities 및 상호 참조 관계
	## 비즈니스 엔티티 및 상호 참조 관계

여기 이후로 나오는 "entities" 중 레이어 이름을 지칭하는 게 아닌 것들은 기존 번역인 "세그먼트"와 "슬라이스"에 맞춰 '엔티티'로 번역하시는 게 어떤가요?

한국어 문법은 단복수 호응이 엄격하지 않아서 원문이 복수형이라도 꼭 '-들'을 붙일 필요는 없다고 합니다(의미를 해치지 않을 때 한정). 그래서 '엔티티들'이 아니라 '엔티티'가 어떨지 의견 드립니다.

[Gaic4o]

저두 이 부분에서 문서화를 할 때 마다 고민이 들었는데, 피드백 해 주셔서 확고 해진 것 같아요. 감사합니다.

[Chun-gu]

Suggested change

	2. **croess-import (공용 API를 사용해 관리하기)**
	2. **Cross-import (공개 API를 사용해 관리하기)**

"public"은 "공용"이 아닌 '공개'로 번역하는 게 적합해 보입니다.

public API는 특정 슬라이스나 세그먼트 내부 모듈을 드러내어 외부 모듈들이 가져다 사용할 수 있게 하는 창구입니다. 하지만 import 규칙에 따라 모든 외부 모듈이 그럴 수 있는 건 아닙니다. 즉, '공개'되었지만 '공용'은 아닙니다.

기존 번역도 이를 고려해 "공개 API"로 한 것 같으니 '공개'로 수정하시는 건 어떨까요?

[Gaic4o]

좋아요! 좋은 피드백 해주셔서 감사합니다. 반영 해 놓겠습니다.

[Chun-gu]

리뷰 반영 확인했습니다. 고생하셨어요!