현지화 스타일 가이드

개요

영어 문법과 표기 기준을 정하는 문서다. 원문을 어떻게 쓸지는 「UX Writing 원칙」이, 번역된 값의 표기는 「번역 String 값 표기 규칙」이, 키 구조는 「String Key 작성 가이드」가 다룬다.

적용 범위

축	적용 / 제약
언어	영어 원문
대상	제목·본문·UI 레이블·문서명
판단이 어려울 때	의심스러우면 Grammarly 를 참조한다. 다만 의사소통 목표와 텍스트 종류, 구체적인 상황을 늘 고려하고 필요하면 명확성을 위해 예외를 둔다

현재 상태 / 정의

일반 원칙

원칙	내용
Be kind and helpful	미리디는 성별·나이·배경과 무관하게 모든 사용자에게 열려 있다. 복잡한 과정을 단순하고 이해하기 쉽게 만드는 안내를 제공한다. 한 사람이 말하는 것처럼 일관된 톤과 스타일을 쓴다
Write on point and clearly	사용자가 필요한 정보를 빠르게 얻도록 간결하고 명확하게 쓴다
Write for a global audience	우리가 쓰는 것은 영어 외의 언어로 번역되거나, 영어가 모국어가 아닌 사용자가 읽는다. 현지화·번역·국제화를 염두에 두고 쓴다

상세 내용

1. 어조

• 기본적으로 능동태를 쓴다. 다만 주어가 누구인지 중요하지 않거나 목적어를 강조해야 할 때는 수동태를 쓴다. 예: This template is deleted. · The latest version was released on September 9.
• 격식체를 쓴다. 다만 언어는 현재의 흐름에 맞아야 하고, 제품에 비격식이 더 어울리면 비격식을 쓴다. 유럽 언어에서 특히 그렇다.

2. 대문자 사용

대상	규칙
제목·헤딩·버튼	Sentence case 를 쓴다. 첫 글자, 콜론 뒤 부제목의 첫 단어, 고유명사와 항상 특정 방식으로 대문자를 쓰는 용어만 대문자로 한다. Sentence case 를 쓰더라도 제목과 헤딩 끝에 마침표를 찍지 않는다
본문·설명	Sentence case 를 쓴다. 콜론 바로 뒤의 첫 단어는 소문자로 시작한다. 다만 고유명사(Open source software: Hadoop), 헤딩, 인용문, Caution·Note 같은 레이블 뒤의 텍스트는 예외다. 하이픈이 붙은 단어가 문장이나 헤딩의 첫 단어이면 첫 요소만 대문자로 하되, 뒤 요소가 고유명사나 고유형용사이면 그것도 대문자로 한다
UI 레이블	첫 글자를 대문자로 한다. 예: Go to My drive and …
서드파티 제품	원래 소문자로 시작하는 고유명사나 단어는 제목의 일부여도 소문자로 둔다. 연동된 서드파티 앱에서 가져온 문자열의 대소문자는 그대로 유지한다
파일 형식	약어는 전부 대문자로, 확장자는 소문자로 쓰고 점을 포함한다. PDF (.pdf) · JPG (.jpg). 문장 안에서는 확장자보다 약어를 쓰는 것을 권장하며, 확장자를 명시하거나 강조하고 싶을 때만 확장자를 쓴다
문서명	Terms of Use·Privacy Policy·License Policy 같은 문서 이름은 대문자로 쓴다

3. 복수형

• 복수와 단수 중 하나를 골라 문서 전체에서 일관되게 쓴다. 맥락상 둘 다 가능하면 복수를 쓴다.
• 괄호를 쓴 선택적 복수형은 불가피할 때만 쓴다. 프로그램 UI 에서 변수 뒤에 오는 경우가 그렇다. 예: %1 minute(s) ago · %1 item(s) selected.

4. 전치사

전치사는 가장 말이 되고 문장을 읽기 쉽게 만드는 자리에 둔다. 필요하면 문장 끝에 두어도 된다.

좋은 예	나쁜 예
Check the account that you are currently logged in with.	Check the account with which you are currently logged in.

명확성을 높이는 전치사는 포함하고, 불필요한 전치사는 빼며, 너무 많은 전치사로 문장을 어지럽히지 않는다.

5. 대명사

• 대명사가 가리키는 선행사가 분명해야 한다. 모호하고 혼동되는 참조를 피한다.

좋은 예	나쁜 예
… The name does not include parentheses or parameters.	… It does not include parentheses or parameters.
Set this value to true.	Set this to true.
Right-click the link that you want to open.	Right-click the link you want to open.

• 모호함을 피하려면 that 과 which 같은 선택적 대명사를 쓴다.

6. 인칭

• 독자를 you 로 부른다. we·our·us 대신 you 나 your 를 쓴다.
• 독자에게 무언가를 하라고 할 때는 명령형을 쓴다. you 는 생략된 것으로 본다.
• 1인칭 복수는 신중하게 쓴다. 문서의 저자로서 조직을 가리킬 때는 써도 되지만 선행사가 분명해야 한다. 예: We strongly recommend updating your GPU driver.
• 1인칭 단수(I·me·my)는 아껴 쓴다. 예: Notify me when this product is available. · I agree to the Terms and condition.
• 드물게, 같은 화면에 있는 다른 콘텐츠와 개인의 콘텐츠를 구분해야 하는 내비게이션이나 필터 레이블에서는 my 를 써도 된다. 예: My drive

7. 구두점

기호	규칙
마침표 .	정보나 주장을 전달하는 완전한 문장 끝에 쓴다. 앞에 공백을 두지 않고 뒤에 한 칸을 둔다. 제목·헤딩·슬로건·태그라인·브랜드 모토·불릿 항목 끝에는 문장 형태가 아닌 한 쓰지 않는다. 괄호 안의 텍스트가 앞 문장의 일부이거나 앞 단어에 대한 설명이면 마침표를 괄호 밖에 둔다. URL 링크로 끝나는 문장에는 링크가 텍스트에 삽입된 경우가 아니면 마침표를 쓰지 않는다
말줄임표 …	멈춤·생략·진행을 뜻한다. 일반적으로 사용을 피하는 것을 권장한다
느낌표 !	강조나 감정적인 톤이 메시지에 도움이 될 때만 아껴 쓴다. 한 단락 안의 여러 문장에서 연속으로 쓰지 않는다
쉼표 ,	항목을 나열할 때는 옥스퍼드 쉼표를 쓴다. 예: Our templates fit every size, screen, and need. Finally,·In this mode,·To do this, 같은 도입어 뒤에 쉼표를 쓴다. 독립절을 나누는 등위접속사 앞에 쉼표를 쓰되, 두 절이 아주 짧으면 생략한다. 한 주어에 걸리는 두 동사 사이에는 쉼표를 쓰지 않고, 가능하면 문장을 둘로 나눈다
콜론 :	뒤따르는 텍스트가 앞 내용을 부연하거나 설명할 때 쓴다. 앞에 공백을 두지 않고 뒤에 한 칸을 둔다
세미콜론 ;	사용을 피하며 특히 String 에서는 쓰지 않는다. 두 문장으로 나눈다
따옴표 " "	곧은 큰따옴표를 쓴다. 사용을 최소화하고 가능하면 다시 표현한다. 쉼표와 마침표는 항상 따옴표 안에 둔다. 물음표와 느낌표는 인용구의 일부이면 안에, 아니면 밖에 둔다. 버튼이나 기능을 가리킬 때는 따옴표로 감싼다(예: Click "Download" to save the current design.). Ctrl·Alt·Command 같은 키보드 키에는 쓰지 않는다. 제품명과 회사명에는 절대 쓰지 않는다
괄호 ( )	사용을 최소화한다. 문장 안의 괄호에 긴 텍스트를 넣지 말고 두 문장으로 나눈다
하이픈·엔대시·엠대시	길이로 구분되며 하이픈 - 보다 엔대시 – 가, 그보다 엠대시 — 가 길다. 하이픈과 엔대시만 쓴다. 엔대시를 하이픈으로 대체하지 않는다. 둘은 기능이 다르고 서로 다른 구두점으로 인식되어 중복 String 이 생길 수 있다
불릿 *	순서가 중요하지 않은 나열에 쓴다. 순서가 중요하면 번호를 쓴다
슬래시 /	대안을 나누거나 조합을 뜻할 때 쓰며 앞뒤에 공백이 없다. 다만 여러 단어로 된 용어나 복합어를 나눌 때는 앞뒤에 한 칸씩 둔다. 코드·파일 경로의 일부이거나 꼭 필요한 경우가 아니면 쓰지 않는다
앰퍼샌드 &	and 를 대신하는 기호이며 앞뒤에 한 칸씩 둔다. 공간 제약이나 자료 성격 때문에 불가피한 경우가 아니면 쓰지 않는다. 많은 언어가 앰퍼샌드를 and 의 의미로 쓰지 않는다

8. 이모지

과용하면 읽기 어려워지고 메시지의 힘이 약해지므로 절제해서 쓴다. 의도를 분명히 해 주면 써도 되지만, 모호하거나 상충하는 의미를 가지면 쓰지 않는다. 가능하면 게시물의 제목이나 짧은 문장으로 강한 주장을 해야 할 때 쓰고, 설명하거나 정보를 전달하는 텍스트에는 쓰지 않는다.

9. 날짜와 시간

시각

• 12시간제를 쓴다. 24시간제를 써야 하는 기능을 설명하는 경우는 예외이며, UI 나 명령어, 코드 샘플이 24시간 형식을 쓰면 그 페이지 전체에서 그 형식으로 통일한다.
• 가능하면 정확한 시각을 쓰되 noon 과 midnight 는 괜찮다.
• 시간 범위에는 하이픈을 쓰고 앞뒤에 공백을 두지 않는다. 예: 5-10 minutes ago.
• AM 과 PM 은 대문자로 쓰고 시각과 한 칸 띄운다. 예: 3:45 PM.
• 정각이면 분을 뺀다. 예: 3 PM.

시간대

• 꼭 필요하지 않으면 시간대를 쓰지 않는다.
• 독자의 현지 시각이면 그것을 알린다. 예: 10 AM your local time
• 시간대가 필요하면 UI 에 보이는 타임스탬프 형식을 쓴다.
• 특정 시간대를 쓸 때는 지역명을 풀어 쓰고 UTC 나 GMT 레이블을 괄호로 붙인다. 예: US and Canadian Pacific Standard Time (UTC-8)
• 시간대 이름을 줄여 쓰지 않는다.
• 일광절약시간으로 시각이 바뀌지 않는 드문 경우에는 UTC 참조 없이 특정 시간대만 쓴다.

날짜

• 날짜가 고정되어 바뀌지 않으면 풀어 써도 된다. 예: October 28, 2024
• 그렇지 않으면 {yyyy}·{mm}·{dd} 변수를 쓰고 번역자에게 각 언어의 올바른 순서로 배치해 달라고 요청한다.
• 숫자만으로 날짜를 표현해야 하면 YYYY-MM-DD 형식에 하이픈으로 구분한다. ISO 8601 국제 표준을 따르는 것이다. 예시를 만들 때는 월과 구분되도록 13일 이상의 날짜를 고른다. 2017-04-15 는 좋고 04/06/2017 은 나쁘다.
• 해당 언어가 이 형식을 따르지 않으면 그 언어의 형식(MM/DD/YYYY·DD-MM-YYYY)을 쓴다.
• 날짜와 시각을 함께 쓸 때는 날짜를 먼저 쓴다. 예: 2017-04-15 at 3 PM

연중 구분

계절을 언급하지 않는다. 북반구의 봄은 남반구의 가을이기 때문이다. 대신 월·분기·기온을 쓴다. During summer months 대신 During warmer months 로 쓴다.

확인 필요

항목	사유	확인 방법
효력 발생일	원문에 이 가이드가 언제부터 적용되는지가 없다	현지화 담당자에게 적용 시점을 확인한다
따옴표 절의 미완성 문장	원문에 「예시 작성하기,,,」라는 작성 중 표시가 남아 있다	해당 예시를 채울지 확인한다
엠대시를 쓰지 않는 규칙과 실제 String	하이픈과 엔대시만 쓰라고 규정하지만 기존 String 의 준수 여부는 확인되지 않았다	String 시트에서 엠대시 사용을 점검한다
문서명 대문자 규칙과 실제 문서명	Terms of Use 등을 대문자로 쓰라고 하는데, 현재 서비스의 문서명 표기와 대조하지 않았다	약관 페이지의 표기를 확인한다

관련 문서

대상	경로
미리캔버스 UX Writing 원칙	product-service/miricanvas/ux-writing-principles.md
번역 String 값 표기 규칙	product-service/miricanvas/string-notation-rule.md
String Key 작성 가이드	product-service/miricanvas/string-key-guide.md
String 업데이트 워크플로우	product-service/miricanvas/string-update-workflow.md