[ko] showDirectoryPicker, showOpenFilePicker, showSaveFilePicker 번역

[alattalatta]

Description

File System API의 메서드들인 showDirectoryPicker(), showOpenFilePicker(), showSaveFilePicker()를 추가합니다.

Motivation

미번역

Additional details

-

Related issues and pull requests

Relates to #23898

[github-actions]

Preview URLs

• /ko/docs/Web/API/Window/showDirectoryPicker
• /ko/docs/Web/API/Window/showOpenFilePicker
• /ko/docs/Web/API/Window/showSaveFilePicker

Flaws (13)

URL: /ko/docs/Web/API/Window/showDirectoryPicker
Title: Window: showDirectoryPicker() 메서드
Flaw count: 5

• macros:
  • /ko/docs/Web/API/FileSystemDirectoryHandle does not exist but fell back to /en-US/docs/Web/API/FileSystemDirectoryHandle
  • /ko/docs/Web/API/DOMException does not exist but fell back to /en-US/docs/Web/API/DOMException
  • /ko/docs/Web/API/PermissionStatus/state does not exist but fell back to /en-US/docs/Web/API/PermissionStatus/state
  • /ko/docs/Web/API/DOMException does not exist but fell back to /en-US/docs/Web/API/DOMException
  • /ko/docs/Web/API/FileSystemDirectoryHandle does not exist but fell back to /en-US/docs/Web/API/FileSystemDirectoryHandle

---

URL: /ko/docs/Web/API/Window/showOpenFilePicker
Title: Window: showOpenFilePicker() 메서드
Flaw count: 4

• macros:
  • /ko/docs/Web/API/FileSystemFileHandle does not exist but fell back to /en-US/docs/Web/API/FileSystemFileHandle
  • /ko/docs/Web/API/DOMException does not exist but fell back to /en-US/docs/Web/API/DOMException
  • /ko/docs/Web/API/DOMException does not exist but fell back to /en-US/docs/Web/API/DOMException
• broken_links:
  • Can't resolve /ko/docs/Web/HTTP/Basics_of_HTTP/MIME_types/Common_types

---

URL: /ko/docs/Web/API/Window/showSaveFilePicker
Title: Window: showSaveFilePicker() 메서드
Flaw count: 4

• macros:
  • /ko/docs/Web/API/FileSystemFileHandle does not exist but fell back to /en-US/docs/Web/API/FileSystemFileHandle
  • /ko/docs/Web/API/DOMException does not exist but fell back to /en-US/docs/Web/API/DOMException
  • /ko/docs/Web/API/DOMException does not exist but fell back to /en-US/docs/Web/API/DOMException
• broken_links:
  • Can't resolve /ko/docs/Web/HTTP/Basics_of_HTTP/MIME_types/Common_types

External URLs (3)

URL: /ko/docs/Web/API/Window/showDirectoryPicker
Title: Window: showDirectoryPicker() 메서드

• https://developer.chrome.com/docs/capabilities/web-apis/file-system-access (1 time) (Note! This may be a new URL 👀)

---

URL: /ko/docs/Web/API/Window/showOpenFilePicker
Title: Window: showOpenFilePicker() 메서드

• https://developer.chrome.com/docs/capabilities/web-apis/file-system-access (1 time) (Note! This may be a new URL 👀)

---

URL: /ko/docs/Web/API/Window/showSaveFilePicker
Title: Window: showSaveFilePicker() 메서드

• https://developer.chrome.com/docs/capabilities/web-apis/file-system-access (1 time) (Note! This may be a new URL 👀)

(comment last updated: 2024-10-13 10:46:32)

[1ilsang]

@alattalatta 님 안녕하세요. 기여해주셔서 감사합니다! 💯

몇 가지 코멘트 남겨두었습니다.

확인하시고 다시 리뷰 요청 부탁드리겠습니다. 🙇

질문이나 도움이 필요하시다면 언제든 멘션 부탁드리겠습니다.

[alattalatta]

안녕하세요 @1ilsang 님, @hochan222 님, 줄 수 관련 피드백 반영 전에, 영어 문서의 인위적인 개행에 맞춰 국문의 줄 수를 강제하는 것이 의미가 있는지 의문이기에 먼저 말씀드리겠습니다.

참고: "인위적인 개행"이라 함은 저자가 의도를 갖고 문장의 끝에 추가한 개행이 아니라, 중간에 갑작스럽게 발생한 개행을 말합니다.

• Follows the format of the content repo first.
  • Contributors are guided in the direction of maintaining the number of lines without any special standards for dividing lines.

라는 부분은 보았습니다만, 결국 mdn/content의 방침 또한 인위적인 개행은 하지 않겠다는 것이 방향입니다. 따라서 현재 원문에 있는 저 개행들은 80자 강제 개행을 했던 사람의, 또는 시절의, 흔적에 가깝고 현재 권장되는 방식은 아닐 것입니다.

• many (most?) people would like to avoid breaking in the middle of a sentence
• sometimes people fix formatting issues like this when they are making a PR to the file anyway (for example, if they are fixing a bug they might reformat the file at the same time). I know for instance hamishwillee does this. And I think this is fine.

제가 mdn/content에서 해당 문서들의 개행을 제거하는 PR을 발행 후 이 PR로 돌아오면 위 리뷰들은 유효하지 아니한 것이 됩니다. 하지만 굳이 그렇게까지 해야 할까 싶습니다.

또한 문서의 변경점 추적 면에서도, 영문과 국문의 문법적 차이로 인해 한 문장 내에서 개행의 위치가 항상 현저히 다를 것이기에 어떤 이점이 있을지 의문입니다. 이미 리뷰 주신 부분에서도 원문과 개행된 줄의 내용이 맞지 않습니다.

An optional description of the category of files
types allowed. Default to be an empty string.

위 텍스트를 보아도 벌써 of 때문에 국문에서는 어순을 뒤집어야 합니다. 파일 유형이 개행돼있으니 파일 유형을 개행 뒤에 배치한다면 아래와 같이 윗줄이 지나치게 짧아질거고,

사용 가능한 파일
유형에 대한 설명입니다. 기본 값은 빈 문자열입니다.

아래 두 개와 같이 하면 줄 수와 문자 수는 얼추 맞겠지만 변경 대조에는 장점이 없습니다. 원문과 개행 위치가 크게 다르기 때문입니다.

사용 가능한 파일 유형에 대한
설명입니다. 기본 값은 빈 문자열입니다.

사용 가능한 파일 유형에 대한 설명입니다.
기본 값은 빈 문자열입니다.

그렇다면 원문의 임의 개행을 따르는 것에는 장점이 없다는 게 제 의견입니다. 재고해주세요.

[1ilsang]

@alattalatta 님 좋은 의견 감사합니다.

질문에 대한 답변을 드리려고 합니다.

mdn/content에서 해당 문서들의 개행을 제거하는 PR을 발행 후 이 PR로 돌아오면 위 리뷰들은 유효하지 아니한 것이 됩니다.

이 부분이 중요한 포인트라 생각합니다. 현재 모든 번역 페이지는 sourceCommit을 이용하여 원문의 형태를 기억하고, "그 순간"의 모습을 온전히 담기 위해 노력하고 있습니다.

그렇기 때문에 개행을 제거하는 PR을 반영한다 하여도 위 리뷰들이 유효하지 않은건 아닙니다. 새로운 PR이 원문에 반영되어도 지금 순간의 스냅샷(커밋해시)은 영원이 존재하기 때문입니다.

이는 번역 문서의 최신화 여부를 확인할 뿐만 아니라 해당 커밋에 상응하는 원문의 모습을 그대로 반영하기 위한 노력의 일환입니다.

따라서 원문의 형상이 그렇다면 번역 문서도 그렇게 가려고 합니다.

문서의 변경점 추적 면에서도, 영문과 국문의 문법적 차이로 인해 한 문장 내에서 개행의 위치가 항상 현저히 다를 것이기에 어떤 이점이 있을지 의문입니다.

여기서 두 가지 꼭지점이 있습니다.

1. 의견 주신 것 처럼 개행 위치가 항상 다르다는 점은 사실 "독자에겐 무관하다"는 점이 있습니다.
2. "줄 수가 많은, 긴 문서일수록 라인의 비교로 변경점을 빠르게 찾을 수 있다"는 장점이 있습니다.

첫 번째 꼭지점부터 이야기 드리겠습니다.

의견 주신 내용과 같이 문법적 차이로 인해 발생하는 개행 위치의 상이함과 거기에서 오는 "줄의 내용"의 매칭이 완벽하지 않다는 것은 인지하고 있습니다.

다만, 마크다운 문서의 특성상 실제 MDN 문서를 읽게 되는 독자는 개행과 무관하게 읽을 수 있습니다.

안녕
하
세요

위와 같은 형태는 결국 안녕하세요로 표현됩니다. 그렇다면 개행 여부에 따른 원문과의 매칭은 "문서 작성자" 혹은 "문서 유지보수자"를 위해 존재한다고 봐도 무방할 것입니다.

이는 두 번째 꼭지점으로 이어집니다.

줄 수가 많은, 긴 문서일수록 라인의 비교로 변경점을 빠르게 찾을 수 있습니다. 단순 한 줄 내의 변경점을 찾는게 아닌 문서 전체적인 틀을 한눈에 본다는 점에서의 이점입니다.

원문과 줄 수가 동일한 번역 문서라면 이후 원문에서의 문단 추가, 변경점의 위치를 직관적으로 파악할 수 있습니다.

약 700줄 가량의 원문에서 400-410줄이 추가되고 600-610, 612-620줄이 삭제되었고 611줄이 변경된 시나리오를 그려보겠습니다.

만약 해당 번역 문서가 원문과 달리 400줄로 번역되어 있었다면, 이후 최신화 번역 PR의 diff 위치는 상당히 깨져있을 것입니다. 긴 한 줄 내에서 변경 점을 찾아야 하며 정합이 맞는지 보기 위해 리뷰어는 한 번 더 문서의 구조를 확인해야 할 것입니다.

반면 번역 문서가 원문과 동일했다면 변경된 줄만 확인하면 됩니다.

리뷰어는 현재 번역된 문서(1)와 최신 번역 PR(2) 그리고 원문(3) 3가지를 모두 비교하며 문서를 확인하고 있습니다. 라인으로 변경점을 바로 알 수 있다는 점은 문서를 유지보수하는 메인테이너의 시간을 아낄 수 있고 더 양질의 리뷰를 드릴 수 있는 발판이라 생각합니다.

따라서, 제 의견을 요약드리면 아래와 같습니다.

1. 번역 문서는 원문과 형상을 맞춘다. 번역 문서만의 형태가 되면 안된다.
2. 동일한 형상은 문서 관리를 쉽게 한다. 큰 틀이 동일하므로 이후 리뷰어가 더 직관적으로 파악할 수 있다.

답변이 도움이 되었길 바랍니다.

감사합니다.

cc. @mdn/yari-content-ko

[alattalatta]

파일 탭에서 배치 적용 가능한줄 모르고 하나씩 하다가 3개 남았을 때야 알아차렸네요. 불필요한 알림 발생 죄송합니다.

여전히 납득할 수는 없습니다. 포매터의 출력물은 기계출력이고, 사람이 기계출력을 따라하는 건 가능할지언정 효율성으로는 현실적이지 않으며 도구가 인간을 위할 것인데 인간이 도구를 따라가는 모습이기 때문입니다.

도구의 의의란 서식화처럼 상대적으로 부수적인 작업을 무의식의 영역으로 밀어낸 뒤 의식은 제일 중요한 작업에 투입하기 위함이라 생각하는데, 예컨대 영문에서 80/80/80 3줄 문단을 번역했더니 120자로 짧아졌다면, 그 줄 수를 맞추기 위해 40/40/40 (+-) 의 훨씬 짧은 줄 너비로 맞춰주기 위해서는 어디서 개행을 어떻게 분배할지 번역자가 의식적인 결정을 해야 하기 때문이고 이는 그 의의를 뒤집은 것이기 때문입니다.

하지만 관리 측면에서 말씀해주셨으니 존중하겠습니다.

[1ilsang]

고생하셨습니다. LGTM