---

권장 단어 목록#

  기술 문서 작성 팀(Technical Writing team)은 문서의 일관성을 보장하기 위해 다음 단어 선택을 권장합니다. 또한:

• GitLab 핸드북에는 자주 잘못 사용되는 용어 목록이 포함되어 있습니다.

• 문서 스타일 가이드에는 언어 및 대문자 표기에 관한 세부 사항이 포함되어 있습니다.

• GitLab 핸드북은 제3자 상표 사용에 관한 지침을 제공합니다.

이 페이지에 없는 지침은 다음 스타일 가이드를 따릅니다:

• Microsoft Style Guide

• Google Developer Documentation Style Guide

--> -->

.gitlab-ci.yml file#

.gitlab-ci.yml 파일에는 백틱(backtick)과 소문자를 사용합니다.

가능하면 전체 표현을 사용하세요: the .gitlab-ci.yml file

사용자가 CI/CD 구성 파일에 다른 이름을 지정할 수 있지만, 대부분의 경우 the .gitlab-ci.yml file을 사용하세요.

& (앰퍼샌드)#

라틴 약어를 사용하지 마세요. &를 사용하는 UI 요소를 문서화하는 경우가 아니라면 and를 사용하세요.

@mention#

@mention은 가급적 사용하지 마세요. 대신 mention을 사용하고, mentions 항목으로 링크하는 것을 고려하세요. 백틱은 사용하지 마세요.

2FA, two-factor authentication#

첫 번째 사용 시와 항목 제목에서는 문장 형식으로 two-factor authentication을 풀어서 쓰고, 이후에는 2FA를 사용하세요. 문장의 첫 단어인 경우 factor 또는 authentication을 대문자로 쓰지 마세요. 예시:

• Two-factor authentication (2FA) helps secure your account. Set up 2FA when you first sign in.

ability, able#

ability 또는 able은 모호할 수 있으므로 가급적 사용하지 마세요. 이 단어들의 사용법은 allow 및 enable과 유사합니다.

사용자의 능력이나 제품의 기능에 대해 이야기하는 대신, 직접적이고 구체적으로 서술하세요.

단, 보안에 대해 이야기하거나 누군가가 UI에서 작업을 완료하지 못하도록 방지하는 경우에는 이 용어를 사용할 수 있습니다.

ability 또는 able을 permissions 또는 roles와 혼동하지 마세요.

사용:

• You cannot change this setting.

• To change this setting, you must have the Developer, Maintainer, or Owner role.

• Confirm you can sign in.

• The external load balancer cannot connect.

• Option to delete branches introduced in GitLab 17.1.

대신 다음 표현은 사용하지 마세요:

• You are not able to change this setting.

• You must have the ability to change this setting.

• Verify you are able to sign in.

• The external load balancer will not be able to connect.

• Ability to delete branches introduced in GitLab 17.1.

above#

문서 페이지의 예시나 테이블을 참조할 때 above는 가급적 사용하지 마세요. 꼭 필요한 경우 previous를 대신 사용하세요. 예시:

• 앞의 예에서, 개는 벼룩이 있었습니다.

제품 버전을 참조할 때 above를 사용하지 마십시오. 대신 later를 사용하십시오.

사용:

• In GitLab 14.4 and later…

대신:

• In GitLab 14.4 and above…

• In GitLab 14.4 and higher…

• In GitLab 14.4 and newer…

access level#

액세스 레벨은 역할 또는 권한과 다릅니다. 사용자를 생성할 때 액세스 레벨을 선택합니다: Regular, Auditor, 또는 Administrator.

UI를 참조할 때는 이 단어들을 대문자로 표기하십시오. 그 외에는 소문자를 사용하십시오.

특정 액세스 레벨이 필요한 경우 다음 패턴 중 하나를 사용하십시오:

• You must have at least the administrator access level.

• You must have the administrator access level or higher.

• You must be an administrator.

특정 액세스 레벨이 없는 경우 명사구로 minimum access level을 사용하십시오. 예:

• The minimum access level for push is the minimum role required to push a package.

계층 구조를 설명할 때는 higher와 lower를 사용하십시오:

• Higher access levels have more permissions.

• Administrator is a higher access level than regular.

• Regular is a lower access level than administrator.

add#

객체가 이미 존재할 때 add를 사용하십시오. 객체가 아직 존재하지 않는 경우, 대신 create를 사용하십시오. Add는 remove의 반대입니다.

예:

• Add a user to the list.

• Add an issue to the epic.

add와 create를 혼동하지 마십시오.

Add new를 사용하지 마십시오.

Admin area#

사용:

• Admin area, UI의 이 영역을 설명할 때.

• Admin, UI 버튼에.

대신:

• Admin area (두 단어 모두 볼드)

• Admin Area (Area가 대문자)

• Admin Area (Area가 대문자)

• administrator area

• 또는 다른 변형

Admin Mode#

Admin Mode에는 제목 대소문자를 사용하십시오. UI도 제목 대소문자를 사용합니다.

administrator#

administrator는 역할 또는 권한이 아닙니다. admin으로 줄여 쓰지 마십시오.

GitLab Self-Managed 및 GitLab Dedicated에서:

사용자는 관리자가 되어 인스턴스 전체 설정을 수정할 수 있습니다.

인스턴스 전체 설정에 대한 사용자의 액세스 레벨을 언급할 때는 다음 중 하나를 사용하십시오:

Administrator access.

• You must have administrator access.

대신:

• To do this thing, you must have the Admin role.

GitLab.com에서:

GitLab 팀원만 관리자가 되어 인스턴스 전체 설정을 수정할 수 있습니다.

다른 사용자는 GitLab.com 인스턴스의 관리자가 될 수 없습니다. 이들은 특정 그룹이나 프로젝트에 대한 완전한 제어권을 부여하는 Owner 권한을 가질 수 있습니다.

이러한 사용자가 GitLab.com 관리자와 비교하여 할 수 있거나 없는 작업에 대해 구체적으로 명시하십시오. 예:

For GitLab.com, you cannot add or edit MCP servers. Only GitLab.com administrators

MCP 서버를 추가하거나 편집할 수 있습니다.

advanced search#

advanced search는 소문자로 사용하여 GitLab 인스턴스 전체에서 더 빠르고 효율적인 검색을 지칭합니다.

agent for Kubernetes#

GitLab agent for Kubernetes를 지칭할 때는 소문자로 사용합니다. 예를 들면 다음과 같습니다:

• 클러스터를 GitLab에 연결하려면 GitLab agent for Kubernetes를 사용하세요.

• 클러스터에 agent를 설치하세요.

• 목록에서 agent를 선택하세요.

GitLab Agent 또는 GitLab Agent for Kubernetes와 같이 타이틀 케이스를 사용하지 마세요.

agent 단독으로는 의미가 명확하지 않을 때, 또는 다른 유형의 agent와 구분이 필요할 때는 GitLab agent for Kubernetes를 사용합니다.

기술적인 맥락에서 특정 컴포넌트를 지칭할 때는 백틱으로 감싼 agentk를 사용합니다.

agent for workspace#

워크스페이스 내에서 실행되며 워크스페이스에 접근하는 데 사용되는 컴포넌트를 지칭할 때는 소문자 agent for workspace를 사용합니다. Workspace를 타이틀 케이스로 사용하지 마세요. 예를 들면 다음과 같습니다:

• agent for workspace는 워크스페이스에서 GitLab 통합 작업을 처리합니다.

• 개발 환경을 연결하려면 agent for workspace를 구성하세요.

기술적인 맥락에서 특정 컴포넌트를 지칭할 때는 백틱으로 감싼 agentw를 사용합니다.

agent for Kubernetes와 혼동하지 마세요. agent 단독으로는 의미가 명확하지 않을 때, 또는 다른 유형의 agent와 구분이 필요할 때는 agent for workspace를 사용합니다.

agent access token#

agent for Kubernetes를 생성할 때 생성되는 토큰입니다. 다음 표현 대신 agent access token을 사용하세요:

• registration token

• secret token

• authentication token

Agentic Chat, GitLab Duo Agentic Chat#

GitLab Duo Agentic Chat은 GitLab Duo Agent Platform의 일부입니다.

사용 가능한 옵션은 다음과 같습니다:

• GitLab Duo Agentic Chat

• Agentic Chat

• GitLab Duo Chat - agentic과 non-agentic의 차이가 필요하지 않을 때 사용합니다.

• Chat - agentic과 non-agentic의 차이가 필요하지 않을 때 사용합니다.

다음 표현은 사용하지 마세요:

• Duo Agentic Chat (GitLab 없이 사용)

• GitLab Duo Chat (agentic) (괄호 표기)

agnostic#

agnostic 대신 platform-independent 또는 vendor-neutral을 사용하세요. (Vale 규칙: SubstitutionWarning.yml)

AI, artificial intelligence#

AI를 사용합니다. artificial intelligence를 풀어 쓰지 마세요.

AI agent#

AI에 대해 작성할 때 agent는 사용자를 대신해 작업을 수행하는 개체를 의미합니다.

agent 단독으로는 의미가 명확하지 않을 때, 또는 다른 유형의 agent와 구분이 필요할 때는 AI agent를 사용할 수 있습니다.

agent 단독으로는 소문자를 사용합니다. agent 이름에는 타이틀 케이스를 사용하며, 예를 들면 Code Review Agent와 같이 씁니다.

AI agent와 상호작용할 때 session이 실행됩니다. 사용자는 세션을 중지할 수 있습니다.

하나 이상의 AI agent는 flow의 일부가 될 수 있으며, 이 경우 함께 문제를 해결하도록 오케스트레이션됩니다.

foundational agents를 포함하여 다양한 유형의 agent가 존재합니다.

AI Catalog#

AI Catalog는 타이틀 케이스를 사용합니다. 소문자인 AI catalog는 사용하지 마세요. 하이픈도 사용하지 않습니다.

AI Gateway#

AI Gateway는 타이틀 케이스를 사용합니다. 소문자인 AI gateway는 사용하지 마세요. 하이픈도 사용하지 않습니다.

AI-powered, AI-native#

AI-powered 대신 AI-native를 사용합니다. 예를 들면 Code Suggestions is an AI-native feature와 같이 씁니다.

air gap, air-gapped#

인터넷 접근을 차단하거나 제한하는 물리적 장벽이나 보안 정책이 적용된 설치 환경을 설명할 때는 offline environment를 사용합니다. air gap, air gapped, air-gapped는 사용하지 마세요. 예를 들면 다음과 같습니다:

• offline environment의 방화벽 정책으로 인해 컴퓨터가 인터넷에 접근할 수 없습니다.

allow, enable#

보안 관련 기능이나 기능 플래그의 상태에 대해 이야기하는 경우가 아니라면 allow와 enable 사용을 피하세요.

다음과 같이 사용하세요:

• 리포지터리에 파일을 추가할 수 있습니다.

대신:

• This feature allows you to add a file to your repository.

• This feature enables users to add files to their repository.

이 표현은 기능을 구현한 사람의 관점이 아니라 사용자의 관점에서 작성된 보다 능동적인 표현입니다. 자세한 내용은 Microsoft 스타일 가이드를 참조하세요.

analytics#

analytics와 contribution analytics, issue analytics 같은 변형어는 소문자로 사용합니다. 단, UI에서 다른 대소문자를 사용하는 경우에는 문서가 UI와 일치하도록 작성합니다.

예를 들어:

• 프로젝트의 머지 리퀘스트 애널리틱스를 볼 수 있습니다. Merge Request Analytics 대시보드에 표시됩니다.

ancestor#

계층 구조에서 하나 이상 위에 있는 상위 항목을 가리킬 때는 ancestor를 사용합니다.

grandparent는 사용하지 않습니다.

예시:

• An ancestor group, a group in the project’s hierarchy.

• An ancestor epic, an epic in the issue’s hierarchy.

• A group and all its ancestors.

참조: child, descendant, subgroup.

and/or#

and/or 대신 or을 사용하거나, 두 가지 옵션을 모두 명시하도록 문장을 다시 작성합니다.

and so on#

and so on은 사용하지 않습니다. 대신 더 구체적으로 작성합니다. 자세한 내용은 Microsoft 스타일 가이드를 참조하세요.

area#

area 대신 section을 사용합니다. Admin area만 예외입니다.

as#

as를 because의 의미로 사용하지 않습니다.

사용:

• Because none of the endpoints return an ID…

대신:

• As none of the endpoints return an ID…

as well as#

as well as 대신 and를 사용합니다.

associate#

이슈를 에픽에 추가하거나 사용자를 이슈, 머지 리퀘스트, 에픽에 추가하는 것을 설명할 때 associate를 사용하지 않습니다.

대신 assign을 사용합니다. 예를 들어:

• Assign the issue to an epic.

• Assign a user to the issue.

authenticate#

authenticate를 동사로 사용할 때는 가장 적합한 전치사를 사용하도록 노력합니다.

토큰이나 OAuth 같은 서비스처럼 인증을 수행하는 시스템이나 제공자를 가리킬 때는 authenticate with를 사용합니다.

예를 들어:

• Authenticate with a deploy token.

• Authenticate with your credentials.

• Authenticate with OAuth.

• The runner uses an authentication token to authenticate with GitLab.

자격 증명이 검증을 위해 확인되는 리소스를 가리킬 때는 authenticate against를 사용합니다.

예를 들어:

• The client authenticates against the LDAP directory.

• The script authenticates against the local user database.

authenticated user#

signed in user 또는 logged in user 같은 다른 표현 대신 authenticated user를 사용합니다.

before you begin#

사용자가 튜토리얼을 완료하기 전에 완료해야 하는 작업이나 충족해야 하는 조건을 문서화할 때는 before you begin을 사용합니다. requirements 또는 prerequisites는 사용하지 않습니다.

자세한 내용은 튜토리얼 페이지 유형을 참조하세요.

태스크 토픽 유형에는 prerequisites를 대신 사용합니다.

below#

문서 페이지의 예시나 테이블을 가리킬 때 below는 가능하면 사용하지 않습니다. 필요한 경우 대신 following을 사용합니다. 예를 들어:

• In the following example, the dog has fleas.

beta#

beta는 소문자로 표기합니다. 예:

• The feature is in beta.

• This is a beta feature.

• This beta release is ready to test.

beta 기능을 작성할 때 이 항목을 링크로 연결할 수도 있습니다.

blacklist#

blacklist를 사용하지 마세요. 대신 denylist를 사용할 수 있습니다. (Vale 규칙: InclusiveLanguage.yml)

board#

boards, issue boards, epic boards는 소문자로 표기합니다.

box#

UI 필드를 지칭할 때는 text box를 사용하세요. field나 box는 사용하지 마세요. 예:

• In the Variable name text box, enter a value.

branch#

브랜치를 설명할 때는 branch를 단독으로 사용하세요. 특정 브랜치의 경우 다음 용어만 사용하세요:

• default branch: 리포지터리의 기본(primary) 브랜치입니다. 사용자는 UI를 통해 default branch를 설정할 수 있습니다. default branch를 사용하는 예시에서는 master 대신 main을 사용하세요.

• source branch: 머지 리퀘스트에서 병합의 출처가 되는 브랜치입니다.

• target branch: 머지 리퀘스트에서 병합의 대상이 되는 브랜치입니다.

• current branch: 현재 체크아웃된 브랜치입니다. 이 브랜치는 default branch, 직접 생성한 브랜치, 소스 브랜치, 또는 다른 브랜치일 수 있습니다.

feature branch 또는 merge request branch라는 용어는 사용하지 마세요. 가능한 한 구체적으로 표현하세요. 예:

• The branch you have checked out…

• The branch you added commits to…

bullet#

순서 있는 목록 또는 순서 없는 목록의 개별 항목을 bullets라고 하지 마세요. 대신 list item을 사용하세요. 더 명확하게 표현하려면 다음을 사용할 수 있습니다:

• Ordered list item: 순서 있는 목록의 항목.

• Unordered list item: 순서 없는 목록의 항목.

button#

button에 설명 수식어를 붙이지 마세요.

다음과 같이 사용하세요:

• Select Run pipelines.

다음과 같이 사용하지 마세요:

• Select the Run pipelines button.

canceled, cancelled#

cancelled(L 두 개) 대신 canceled(L 한 개)를 사용하세요.

마찬가지로 cancelling 대신 canceling을 사용하세요.

명사 cancellation은 L을 두 개 사용합니다.

(Vale 규칙: SubstitutionWarning.yml)

cannot, can not#

can not 대신 cannot을 사용하세요.

축약형도 참고하세요.

card#

UI 용어가 card일 수 있지만, 문서에서는 사용하지 마세요. 가능하면 수식어를 생략하세요.

다음과 같이 사용하세요:

• By Seat utilization, select Assign seats.

다음과 같이 사용하지 마세요:

• In the Seat utilization card, select Assign seats.

Chat, GitLab Duo Non-Agentic Chat#

GitLab Duo Non-Agentic Chat은 GitLab Duo Chat의 구버전입니다.

사용 가능한 표현:

• GitLab Duo Non-Agentic Chat.

• Non-Agentic Chat.

• GitLab Duo Chat - agentic과 non-agentic의 구분이 필요하지 않을 때 사용합니다.

• Chat - agentic과 non-agentic의 구분이 필요하지 않을 때 사용합니다.

사용하지 마세요:

• Duo Non-Agentic Chat (GitLab 없이 사용)

• GitLab Duo Chat (non-agentic) (괄호 표기)

• Classic Chat

checkbox#

checkbox는 한 단어로 사용합니다. check box는 사용하지 않습니다.

체크박스는 select(선택)하거나 clear(해제)합니다. check, enable, deselect, disable은 사용하지 않습니다. 예:

• Protect environment 체크박스를 선택합니다.

• Protect environment 체크박스를 해제합니다.

체크박스의 상태를 설명해야 할 경우, 선택됨(selected) 또는 해제됨(cleared)으로 표현할 수 있습니다. 예:

• Protect environment 체크박스가 해제되어 있는지 확인합니다.

• Protect environment 체크박스가 선택되어 있는지 확인합니다.

(deselect의 경우, Vale 규칙: SubstitutionWarning.yml)

checkout, check out#

동사로 사용할 때는 check out을 사용합니다. Git 명령어에는 checkout을 사용합니다.

• git checkout을 사용하여 브랜치를 로컬에 체크아웃합니다.

• 편집하려는 파일을 check out합니다.

cherry-pick, cherry pick#

하이픈이 있는 cherry-pick을 사용합니다. cherry pick은 사용하지 않습니다.

child#

항상 복합 명사로 사용합니다.

예시:

• child issue

• child epic

• child objective

• child key result

• child pipeline

참고: descendant, parent, subgroup.

CI, CD#

GitLab 기능에 대해 이야기할 때는 CI/CD를 사용합니다. CI 또는 CD를 단독으로 사용하지 않습니다.

CI/CD#

CI/CD는 항상 대문자로 표기합니다. 처음 사용할 때 풀어서 쓸 필요는 없습니다.

문맥이 명확한 경우, 특히 첫 번째 사용 이후에는 CI/CD를 생략할 수 있습니다. 예:

• CI/CD 파이프라인에서 코드를 테스트합니다. 머지 리퀘스트에 대해 실행되도록 파이프라인을 구성합니다.

• CI/CD 변수에 값을 저장합니다. 변수를 마스킹된 상태로 설정합니다.

CI/CD minutes#

CI/CD minutes는 사용하지 않습니다. 이 용어는 compute minutes로 이름이 변경되었습니다.

classic#

일부 GitLab Duo 기능은 비에이전트(non-agentic) 방식입니다. 이러한 기능을 classic이라고 지칭하지 않습니다.

click#

click은 사용하지 않습니다. 대신 버튼, 링크, 메뉴 항목, 목록에는 select를 사용합니다. Select는 더 다양한 디바이스에 적용되는 반면, click은 마우스에 더 특화된 표현입니다.

단, right-click과 click-through demo는 예외적으로 사용할 수 있습니다.

cloud licensing#

인터넷을 통해 활성화 코드를 동기화하는 과정을 설명해야 하는 경우를 제외하고, cloud licensing이라는 표현은 사용하지 않습니다.

가능하다면, 이 구독이 GitLab과 동기화된다는 사실에 초점을 맞춥니다.

예:

• 인스턴스가 GitLab과 구독 데이터를 동기화할 수 있어야 합니다.

cloud-native#

GitLab을 호스팅하기 위해 쿠버네티스 클러스터를 사용하는 것에 대해 이야기할 때, 이는 cloud-native version of GitLab을 의미합니다. 이 버전은 GitLab 배포에 사용되는 대규모의 모놀리식 Linux package와는 다릅니다.

약식으로 cloud-native GitLab을 사용할 수도 있습니다. 하이픈을 사용하고 소문자로 표기합니다.

code completion#

Code Suggestions는 두 가지 주요 기능을 포함하도록 발전했습니다:

• code completion

• code generation

code completion은 소문자로 사용합니다. GitLab Duo Code Completion은 사용하지 않습니다. GitLab Duo는 Code Suggestions 전용으로 예약되어 있습니다.

Code completion은 항상 단수형으로 사용해야 합니다.

예시:

• code completion을 사용하여 파일을 채웁니다.

Code Explanation#

Code Explanation은 제목 대소문자(title case)로 표기합니다.

페이지에서 처음 언급할 때는 GitLab Duo Code Explanation을 사용합니다. 이후에는 Code Explanation만 사용합니다.

code generation#

Code Suggestions는 두 가지 주요 기능을 포함하도록 발전했습니다:

• code completion

• code generation

code generation은 소문자로 사용합니다. GitLab Duo Code Generation은 사용하지 않습니다. GitLab Duo는 Code Suggestions 전용으로 예약되어 있습니다.

Code generation은 항상 단수 형태를 사용해야 합니다.

예시:

• 코드 주석을 기반으로 코드를 생성하려면 code generation을 사용합니다.

• 파일에 코드 주석을 추가하여 code generation 결과를 조정합니다.

Code Owner, code owner, CODEOWNER#

기능 이름 또는 개념을 지칭할 때는 Code Owners를 사용합니다. 예를 들어:

• Code Owners 승인 규칙을 사용하여 코드를 보호합니다.

코드 소유권 책임이 있는 개인 또는 그룹을 지칭할 때는 소문자로 code owner 또는 code owners를 사용합니다. 예를 들어:

• 프로젝트에 code owner를 지정합니다.

• 리뷰를 위해 code owner에게 문의합니다.

codeowner, CodeOwner, code-owner는 사용하지 않습니다.

파일 이름을 지칭할 때는 백틱을 사용하여 대문자로 CODEOWNERS를 표기합니다. 예를 들어:

• CODEOWNERS 파일을 편집하여 코드 소유권 규칙을 정의합니다.

Code Review Summary#

Code Review Summary는 타이틀 케이스를 사용합니다.

페이지의 첫 번째 언급에서는 GitLab Duo Code Review Summary를 사용합니다. 이후에는 Code Review Summary만 단독으로 사용합니다.

Code Suggestions#

Code Suggestions는 타이틀 케이스를 사용합니다. 페이지의 첫 번째 언급에서는 GitLab Duo Code Suggestions를 사용합니다.

기능을 가리키는 Code Suggestions는 항상 s로 끝나야 합니다. 단, 단수처럼 작성합니다. 예를 들어:

• Code Suggestions is turned on for the instance.

기능이 출력하는 제안을 일반적으로 지칭할 때는 소문자를 사용합니다.

예시:

• Use Code Suggestions to display suggestions as you type. (이 구절은 기능을 설명합니다.)

• As you type, suggestions are displayed. (이 구절은 일반적인 표현입니다.)

Code Suggestions는 두 가지 주요 기능을 포함하도록 발전했습니다:

• code completion

• code generation

collapse#

UI에서 섹션을 펼치거나 접는 경우를 설명할 때는 close 대신 collapse를 사용합니다.

command line#

명령어를 소개할 때는 From the command line을 사용합니다.

형용사로 사용할 때는 하이픈을 붙입니다. 예를 들어, a command-line tool.

compute#

러너가 CI/CD job을 실행하는 데 사용되는 리소스에는 compute를 사용합니다.

관련 용어:

• compute minutes: compute 사용량 계산 방법. 예: 400 compute minutes.

• compute quota: 네임스페이스가 매월 사용할 수 있는 compute minutes 한도.

• compute usage: 네임스페이스가 월간 할당량에서 사용한 compute minutes 수.

compute minutes#

다음(또는 유사한) 용어 대신 compute minutes를 사용합니다:

• CI/CD minutes

• CI minutes

• pipeline minutes

• CI pipeline minutes

• pipeline minutes

자세한 내용은 에픽 2150을 참조하세요.

configuration#

설정 모음을 편집할 때는 configuration이라고 부릅니다.

configure#

기능 또는 제품을 set up한 후에는 configure를 사용합니다. 예를 들어:

• Set up your installation.

• Configure your installation.

confirmation dialog#

어떤 작업을 확인하도록 요청하는 다이얼로그를 설명할 때는 confirmation dialog를 사용합니다. 예를 들어:

• 확인 대화 상자에서 OK를 선택합니다.

confirmation box 또는 confirmation dialog box는 사용하지 않습니다. dialog도 참조하세요.

container registry#

GitLab container registry 기능과 기능성을 문서화할 때는 소문자를 사용합니다.

사용:

• The GitLab container registry supports A, B, and C.

• You can push a Docker image to your project’s container registry.

create#

객체가 존재하지 않고 처음 생성하는 경우 create를 사용합니다. Create는 delete의 반대입니다.

예:

• Create an issue.

create와 add를 혼동하지 않습니다.

create new는 사용하지 않습니다. create라는 단어 자체가 객체가 새로운 것임을 의미하므로 추가 단어가 필요하지 않습니다.

credits, GitLab Credits#

사용량 기반 결제 기능을 지칭할 때는 GitLab Credits(대문자)를 사용합니다. 측정 단위를 지칭할 때는 credits(소문자)를 사용합니다.

예:

• GitLab Credits are the standardized consumption unit used for usage-based billing.

• You can view your credit usage in the GitLab Credits dashboard.

currently#

제품 또는 기능에 대해 이야기할 때 currently를 사용하지 않습니다. 문서는 오늘날의 제품을 기준으로 설명합니다. (Vale 규칙: CurrentStatus.yml)

custom role#

특정 맞춤 권한으로 생성된 권한을 지칭할 때는 custom role을 사용합니다.

맞춤형이 아닌 권한을 지칭할 때는 default role을 사용합니다.

Customers Portal#

Customers Portal은 GitLab의 구독 및 라이선스 관리 플랫폼의 이름입니다. 고유명사로 취급하며 관사 “the” 없이 사용합니다.

사용:

• Sign in to Customers Portal.

• View your subscription in Customers Portal.

대신:

• Sign in to the Customers Portal.

• View your subscription in the Customers Portal.

data#

data를 단수 명사로 사용합니다.

사용:

• Data is collected.

• The data shows a performance increase.

대신:

• Data are collected.

• The data show a performance increase.

deadline#

deadline은 사용하지 않습니다. 대신 due date를 사용합니다.

default role#

맞춤 권한이 추가되지 않은 다음과 같은 사전 정의된 권한을 지칭할 때는 default role을 사용합니다:

• Guest

• Planner

• Reporter

• Developer

• Maintainer

• Owner

• Minimal Access

static role, built-in role, 또는 predefined role은 사용하지 않습니다.

delete#

객체가 완전히 삭제될 때 delete를 사용합니다. Delete는 create의 반대입니다.

객체가 계속 존재하는 경우에는 대신 remove를 사용합니다. 예를 들어, 에픽에서 이슈를 제거할 수 있지만 이슈는 여전히 존재합니다.

Dependency Proxy#

GitLab Dependency Proxy에는 타이틀 케이스를 사용합니다.

deploy board#

deploy board에는 소문자를 사용합니다.

descendant#

계층 구조에서 한 단계 이상 아래에 있는 하위 항목을 나타낼 때는 descendant를 사용합니다.

grandchild는 사용하지 않습니다.

예시:

• A descendant project, a project in the group’s hierarchy.

• A descendant issue, an issue in the epic’s hierarchy.

• A group and all its descendants.

참고: ancestor, child, subgroup.

Developer#

Developer 권한에 대해 작성할 때는 대문자 D를 사용합니다.

다음과 같이 풀어 씁니다:

• 사용: if you are assigned the Developer role

• 대신: if you are a developer

Developer 권한이 최소 필수 권한인 경우 다음과 같이 사용합니다:

• the Developer, Maintainer, or Owner role

굵게 표시하지 않습니다.

Developer permissions는 사용하지 않습니다. Developer 권한을 할당받은 사용자에게는 관련 권한 집합이 부여됩니다.

dialog#

다음 대안 대신 dialog를 사용합니다:

• dialog box

• modal

• modal dialog

• modal window

• pop-up

• pop-up window

• window

confirmation dialog도 참고하세요. 자세한 내용은 Microsoft Style Guide를 참조하세요.

이 용어를 사용하기 전에 사용 사례에 맞는 용어가 dialog인지 drawer인지 확인합니다.

dialog가 액션의 위치인 경우 전치사로 in을 사용합니다. 예시:

• In the Grant permission dialog, select Group.

in, on도 참고하세요.

disable#

설정이나 기능을 사용 불가 상태로 만드는 것을 설명할 때 disable을 사용하지 않습니다. 대신 turn off, hide, make unavailable, remove 등의 대안을 사용합니다.

상태를 설명할 때는 off, inactive, unavailable을 사용합니다.

이 지침은 Microsoft Style Guide를 기반으로 합니다.

disallow#

disallow 대신 prevent를 사용합니다. (Vale 규칙: Substitutions.yml)

Discussion Summary#

Discussion Summary는 제목 표기법(title case)을 사용합니다.

페이지에서 처음 언급할 때는 GitLab Duo Discussion Summary를 사용합니다. 이후에는 Discussion Summary만 단독으로 사용합니다.

Docker-in-Docker, dind#

Docker executor를 사용하여 Docker 컨테이너를 실행하는 경우를 설명할 때 Docker-in-Docker를 사용합니다.

컨테이너 이름을 나타낼 때는 백틱으로 dind를 표기합니다: docker:dind. 그 외에는 풀어 씁니다.

downgrade#

보다 긍정적이고 정확한 표현을 위해 downgrade는 사용하지 않습니다. 대신 사용자가 수행하는 작업에 초점을 맞춥니다.

• 이전 GitLab 버전으로 변경하는 경우에는 roll back을 사용합니다.

• 낮은 GitLab 티어로 변경하는 경우에는 change the subscription tier를 사용합니다.

download#

데이터를 사용자 기기에 저장하는 것을 설명할 때 download를 사용합니다. 자세한 내용은 Microsoft 스타일 가이드를 참조하세요.

download와 export를 혼동하지 않도록 합니다.

drawer#

다음과 같은 특성을 가진 drawer UI 컴포넌트를 설명할 때 drawer를 사용합니다:

• 화면 오른쪽에서 나타납니다.

• 사용자가 현재 페이지를 벗어나지 않고도 맥락별 정보 또는 작업을 표시합니다.

drawer 예시를 확인하려면:

• Technical Writing Pipeline Editor로 이동한 후 Help ( information-o )를 선택합니다.

• GitLab Duo Chat을 엽니다.

이 용어를 사용하기 전에, 사용 사례에 맞는 올바른 용어가 drawer인지 dialog인지 확인하세요.

dropdown list#

UI 요소를 지칭할 때 dropdown list를 사용하세요. list 없이 dropdown만 단독으로 사용하지 마세요. drop-down(하이픈 포함), dropdown menu 또는 다른 변형은 사용하지 마세요.

예시:

• Visibility dropdown list에서 Public을 선택합니다.

earlier#

버전 번호에 대해 이야기할 때는 earlier를 사용하세요.

사용:

• In GitLab 14.1 and earlier.

대신 다음을 사용하지 마세요:

• In GitLab 14.1 and lower.

• In GitLab 14.1 and older.

easily#

easily를 사용하지 마세요. 사용자가 해당 과정을 쉽다고 느끼지 못하면 신뢰를 잃게 됩니다.

edit#

UI 문서 및 사용자 작업에는 edit를 사용하세요.

예시:

• 프로필 설정을 수정하려면 Edit를 선택합니다.

API 문서 및 프로그래밍 방식의 변경에는 **update**를 사용하세요.

editor extensions#

GitLab이 제공하는 확장 기능의 더 넓은 카테고리를 지칭할 때는 소문자 editor extensions를 사용하세요. 단, UI에 다른 대소문자 표기가 있는 경우 UI에 맞춰 문서를 작성하세요.

개별 확장 기능에는 고유한 이름이 있습니다. 예를 들어 GitLab for VS Code 및 GitLab Duo Plugin for JetBrains IDEs가 있습니다.

사용:

• IDE에서 GitLab editor extensions를 구성합니다.

• Code Suggestions는 다음 editor extensions에서 사용할 수 있습니다.

• 왼쪽 사이드바에서 Settings > General을 선택하고 Editor Extensions를 펼칩니다.

e.g.#

라틴어 약어를 사용하지 마세요. 대신 for example, such as, for instance, 또는 like를 사용하세요. (Vale 규칙: LatinTerms.yml)

ellipsis, ellipses#

가능하면 줄임표(ellipsis) 사용을 피하세요. 코드 블록이나 CLI 응답의 일부로 반드시 포함해야 하는 경우, … HTML 엔터티나 … HTML 코드 대신 공백 없이 마침표 세 개(...)를 사용하세요.

자세한 내용은 코드 블록을 참조하세요.

UI 텍스트를 문서화할 때는 줄임표를 포함하지 마세요. 예를 들어 다음을 사용하세요:

• Search or go to

다음 대신:

• Search or go to…

자세한 내용은 Microsoft Style Guide를 참조하세요.

email#

하이픈이 있는 e-mail은 사용하지 마세요. 복수형으로는 emails 또는 email messages를 사용하세요. (Vale 규칙: SubstitutionWarning.yml)

email address#

이메일에 사용되는 주소를 지칭할 때는 email address를 사용하세요. 메시지를 의미하는 email로 줄여 쓰지 마세요.

emoji#

emoji의 복수형을 지칭할 때는 emoji를 사용하세요.

enable#

설정이나 기능을 사용 가능하게 만드는 것을 설명할 때 enable을 사용하지 마세요. 대신 turn on을 사용하세요.

상태를 설명할 때는 on 또는 active를 사용하세요.

이 지침은 Microsoft Style Guide를 기반으로 합니다.

enter#

대부분의 경우 type 대신 enter를 사용하세요.

• Enter는 음성 및 키보드를 포함하여 정보를 입력하는 여러 방법을 포괄합니다.

• Enter는 사용자가 필드에 값을 입력한 후 커서를 필드 밖으로 이동(또는 Enter 키를 누름)하는 것을 의미합니다. Enter에는 내용 입력과 내용 유효성 검사 작업이 모두 포함됩니다.

예시:

• Variable name 텍스트 상자에 값을 입력합니다.

• Variable name 텍스트 상자에 my text를 입력합니다.

키보드의 키를 지칭하는 데 Enter를 사용할 때는 HTML <kbd> 태그를 사용하세요:

• 결과 목록을 보려면 Enter를 누르세요.

type도 참조하세요.

epic#

epic은 소문자를 사용합니다.

associate도 참조하세요.

epic board#

epic board는 소문자를 사용합니다.

etc.#

**etc.**는 가능한 한 사용하지 않습니다. 최대한 구체적으로 표현하세요. 대체어로 and so on을 사용하지 마세요.

사용:

• You can edit objects, like merge requests and issues.

사용하지 않음:

• You can edit objects, like merge requests, issues, etc.

expand#

UI에서 섹션을 펼치거나 접는 것을 설명할 때는 open 대신 expand를 사용합니다.

experiment#

experiment는 소문자를 사용합니다. 예를 들어:

• This feature is an experiment.

• These features are experiments.

• This experiment is ready to test.

필요한 경우 experimental을 사용할 수 있습니다.

실험 기능에 대해 작성할 때는 이 항목을 링크로 연결하는 것도 좋습니다.

export#

GitLab에서 파일로 표현되지 않는 원시 데이터를 표준 파일 형식으로 변환하는 것을 나타낼 때 export를 사용합니다.

export와 download의 차이점:

• 내보내기 옵션을 사용하여 출력 결과를 변경할 수 있는 경우가 많습니다.

• 내보낸 데이터가 반드시 사용자’s 기기에 다운로드되는 것은 아닙니다.

예를 들어:

• Export the contents of your report to CSV format.

download와 혼동하지 마세요.

FAQ#

사용자가 정보를 빠르게 찾을 수 있도록, FAQ라는 용어는 검색을 통해 잘 찾지 않습니다. FAQ에 포함된 정보는 검색 가능한 주제 제목 아래 유사한 다른 정보와 함께 배치해야 합니다.

feature#

feature라는 단어는 가능한 한 사용하지 않습니다. 대신 GitLab이 수행하는 작업을 설명하세요. 예를 들어 다음과 같이 사용합니다:

• Use merge requests to incorporate changes into the target branch.

다음과 같이 사용하지 않습니다:

• Use the merge request feature to incorporate changes into the target branch.

feature branch#

feature branch는 사용하지 않습니다. branch를 참조하세요.

field#

field 또는 box 대신 text box를 사용합니다.

사용:

• In the Variable name text box, enter my text.

사용하지 않음:

• In the Variable name field, enter my text.

단, 작업을 작성하면서 모든 필드를 한꺼번에 지칭하고자 할 때는 예외를 둘 수 있습니다. 예를 들어:

• In the top bar, select Search or go to.

• Select Settings > CI/CD.

• Expand General pipelines.

• Complete the fields.

여러 필드를 한꺼번에 문서화하는 방법에 대해 자세히 알아보세요.

filename#

filename은 한 단어로 사용합니다. filename을 변수로 사용할 때는 <filename>을 사용합니다.

(Vale rule: SubstitutionWarning.yml)

filter#

이슈나 머지 리퀘스트 같은 항목 목록을 볼 때, 사용 가능한 속성으로 목록을 필터링합니다. 예를 들어 담당자 또는 리뷰어로 필터링할 수 있습니다.

필터링은 searching과 다릅니다.

flows#

GitLab은 에이전트가 실행하는 여러 플로우를 제공합니다.

단독으로 사용할 때는 flow를 소문자로 씁니다.

플로우 이름은 타이틀 케이스를 사용합니다. 예: Convert to CI/CD Pipeline Flow.

agent flow는 사용하지 않습니다.

플로우를 선택합니다. 세션을 시작합니다.

foo#

제품 문서에는 foo를 사용하지 않습니다. API 및 기여자 문서에는 사용할 수 있지만, 가능하면 더 명확하고 의미 있는 예시를 사용하세요.

fork#

fork는 포킹 프로세스를 통해 업스트림 프로젝트에서 생성된 프로젝트입니다.

업스트림 프로젝트(또는 소스 프로젝트)와 fork는 fork 관계를 가지며 연결되어 있습니다.

fork 관계가 제거되면, fork는 업스트림 프로젝트에서 연결 해제됩니다.

foundational agent#

Foundational agent는 에이전트의 한 유형입니다.

일반적으로 foundational agents는 소문자로 씁니다.

• 문서에서는 에이전트 이름을 타이틀 케이스로 씁니다. 예: the Planner Agent.

• UI에서는 타이틀 케이스를 사용하되, Agent라는 단어는 포함하지 않습니다. 예: Planner.

Free#

구독 티어를 나타낼 때는 대문자로 Free를 사용합니다. 다른 구독 티어와 함께 Free를 언급할 때는 구독 티어 지침을 따르세요.

full screen#

full screen은 두 단어로 씁니다. (Vale 규칙: SubstitutionWarning.yml)

future tense#

가능하면 미래 시제 대신 현재 시제를 사용하세요. 예를 들어, after you execute this command, GitLab will display the result 대신 after you execute this command, GitLab displays the result를 사용하세요. (Vale 규칙: FutureTense.yml)

GB, GiB, gigabytes, gibibytes#

GB 및 GiB는 Microsoft 지침을 따르세요.

generally available, general availability#

generally available 및 general availability는 소문자로 씁니다. 예:

• This feature is generally available.

generally available을 더 자주 사용하세요. 예를 들어, 다음과 같이 쓰지 마세요:

• This feature has reached general availability.

general availability를 줄여 GA로 사용하지 마세요.

Geo#

Geo는 타이틀 케이스로 씁니다.

GitLab#

GitLab을 소유격으로 표현(GitLab’s)하지 마세요. 이 지침은 GitLab 상표 지침을 따릅니다.

GitLab을 다른 서드파티 도구나 브랜드 이름 옆에 붙여 쓰지 마세요. 예를 들어, 다음과 같이 사용하지 마세요:

• GitLab Chrome extension

• GitLab Kubernetes agent

대신 다음과 같이 사용하세요:

• GitLab extension for Chrome

• GitLab agent for Kubernetes

브랜드 이름을 나란히 붙이면 소유권 또는 파트너십을 암시할 수 있으므로, 법적 검토를 거쳐 파트너십을 홍보하도록 허가받은 경우가 아니라면 이를 피해야 합니다.

이 지침은 서드파티 상표 사용을 따릅니다.

GitLab CLI#

GitLab CLI를 사용하세요.

처음 언급한 이후에는 CLI만 사용할 수 있습니다. 단, GitLab Duo CLI와 구별해야 할 때는 전체 이름을 계속 사용하세요.

glab을 사용해도 됩니다.

GitLab-managed model#

고객이 Cloud Connector를 통해 GitLab AI Gateway에서 접근하는 대규모 언어 모델을 가리킬 때는 GitLab-managed model을 사용하세요.

고객이 자체 AI Gateway에 자체 호스팅하는 모델에는 이 용어를 사용하지 마세요.

GitLab AI vendor model은 사용하지 마세요.

GitLab Dedicated#

제품 오퍼링을 지칭할 때는 GitLab Dedicated를 사용하세요. GitLab이 고객을 위해 호스팅하고 관리하는 GitLab 인스턴스를 의미합니다.

GitLab Dedicated는 단일 테넌트 SaaS 서비스라고 부를 수 있습니다.

Dedicated만 단독으로 사용하지 마세요. 항상 GitLab Dedicated를 사용하세요.

GitLab Dedicated for Government#

정부 전용 오퍼링을 지칭할 때는 GitLab Dedicated for Government를 사용합니다. 이는 정부 기관 및 FedRAMP 컴플라이언스가 필요한 조직을 위해 GitLab이 호스팅 및 관리하는 GitLab 인스턴스를 의미합니다.

GitLab Dedicated for Government는 GitLab Dedicated와 유사하지만 정부 요건에 최적화된 단일 테넌트 SaaS 서비스입니다.

Dedicated for Government 단독으로는 사용하지 않습니다. 항상 GitLab Dedicated for Government를 사용합니다.

GitLab Duo#

Duo 단독으로는 사용하지 않습니다. 항상 GitLab Duo를 사용합니다.

페이지에서 처음 사용할 때는 GitLab Duo <featurename> 형식을 사용합니다. 2026년 1월 기준, 다음은 GitLab Duo 기능의 이름입니다:

• GitLab Duo Chat

• GitLab Duo Code Explanation

• GitLab Duo Code Review

• GitLab Duo Code Review Summary

• GitLab Duo Code Suggestions

• GitLab Duo Issue Description Generation

• GitLab Duo Issue Discussion Summary

• GitLab Duo Merge Commit Message Generation

• GitLab Duo Merge Request Summary

• GitLab Duo and SDLC trends

• GitLab Duo Product Analytics

• GitLab Duo Root Cause Analysis

• GitLab Duo Self-Hosted

• GitLab Duo Test Generation

• GitLab Duo Vulnerability Explanation

• GitLab Duo Vulnerability Resolution

GitLab Duo Self-Hosted를 제외하고, 첫 번째 사용 이후에는 GitLab Duo 없이 기능 이름만 사용합니다.

GitLab Duo Agent Platform#

GitLab Duo Agent Platform을 사용합니다. 첫 번째 사용 이후에는 Agent Platform을 사용합니다.

Duo Agent Platform 또는 DAP는 사용하지 않습니다.

GitLab Duo Agent Platform Self-Hosted#

GitLab Duo Agent Platform Self-Hosted를 사용합니다. 첫 번째 사용 이후에는 Agent Platform Self-Hosted를 사용합니다.

Duo Agent Platform Self-Hosted 또는 DAP Self-Hosted는 사용하지 않습니다.

GitLab Duo Core#

애드온을 지칭할 때는 GitLab Duo Core를 사용합니다. Duo Core 단독으로는 사용하지 않습니다.

the GitLab Duo Core add-on으로 사용할 수도 있지만, 가능하면 add-on은 생략합니다.

릴리즈 포스트나 블로그와 같은 마케팅 자료에서는 GitLab Duo Core 대신 Premium and Ultimate with GitLab Duo를 사용합니다. 예시:

• Blog: Unlocking AI for every GitLab Premium and Ultimate customer

• Release post: Group and project controls for Premium and Ultimate with GitLab Duo

GitLab Duo CLI#

GitLab Duo CLI를 사용합니다. Duo CLI 단독으로는 사용하지 않습니다.

섹션 내 첫 번째 사용 이후에는 CLI를 사용할 수 있습니다. 단, GitLab CLI와 구분해야 할 경우에는 계속해서 전체 이름을 사용합니다.

명령어를 언급할 때는 두 가지 설치 옵션을 모두 커버하기 위해 duo와 glab duo cli 버전을 모두 포함합니다. GitLab CLI 문서에서는 glab duo cli 버전의 명령어만 문서화합니다.

GitLab Duo Enterprise#

애드온에 대해 항상 GitLab Duo Enterprise를 사용합니다. 법무 승인이 없는 한 Duo Enterprise는 사용하지 않습니다.

the GitLab Duo Enterprise add-on(이 대소문자 형식으로)을 사용할 수 있지만, add-on을 반드시 포함할 필요는 없으며 가능하면 생략하는 것이 좋습니다.

GitLab Duo plugin for JetBrains IDEs#

확장 기능을 지칭할 때는 GitLab Duo plugin for JetBrains IDEs를 사용합니다. Plugins for JetBrains IDEs 또는 Plugins for JetBrains로도 사용할 수 있습니다.

GitLab plugin은 사용하지 않습니다. 이름에 반드시 GitLab Duo를 포함해야 합니다.

GitLab Duo Pro#

애드온에 대해 항상 GitLab Duo Pro를 사용합니다. 법무 승인이 없는 한 Duo Pro는 사용하지 않습니다.

the GitLab Duo Pro add-on(이 대소문자 형식으로)을 사용할 수 있지만, add-on을 반드시 포함할 필요는 없으며 가능하면 생략하는 것이 좋습니다.

GitLab Duo Self-Hosted#

기능을 지칭할 때는 항상 GitLab Duo Self-Hosted를 전체 이름으로 타이틀 케이스로 작성합니다. 단, GitLab이 아닌 고객이 호스팅하는 언어 모델을 지칭하는 경우는 예외입니다.

Self-Hosted 단독으로는 사용하지 않습니다.

GitLab Flavored Markdown#

가능하면 GitLab Flavored Markdown을 전체 이름으로 표기합니다.

약어를 사용해야 하는 경우, GFM은 사용하지 마세요. 대신 GLFM을 사용하세요.

GitLab for Eclipse plugin, Eclipse#

편집기 확장 기능을 지칭할 때는 GitLab for Eclipse plugin을 사용하세요.

IDE를 지칭할 때는 Eclipse를 사용하세요.

GitLab for VS Code extension#

확장 기능을 지칭할 때는 GitLab for VS Code를 사용하세요.

첫 번째 언급 이후에는 GitLab extension, the VS Code extension, 또는 간단히 extension을 사용할 수 있습니다.

확장 기능을 지칭할 때 GitLab Workflow for VS Code, GitLab Workflow, 또는 workflow는 사용하지 마세요.

VS Code의 용어는 VS Code 사용자 인터페이스를 참조하세요.

GitLab Helm chart, GitLab chart#

GitLab의 클라우드 네이티브 버전을 배포하려면 다음을 사용하세요:

• GitLab Helm chart (긴 형식)

• GitLab chart (짧은 형식)

the gitlab chart, the GitLab Chart, 또는 the cloud-native chart는 사용하지 마세요.

GitLab Helm chart를 사용하여 쿠버네티스 클러스터에 cloud-native GitLab을 배포합니다.

다양한 설치 방법을 설명하는 맥락에서 사용하는 경우 Helm chart (Kubernetes)를 사용하세요.

GitLab Operator#

GitLab을 설치하려면 GitLab Operator를 사용합니다.

the Operator 또는 Operator는 사용하지 마세요.

다양한 설치 방법을 설명하는 맥락에서 사용하는 경우 **GitLab Operator (Kubernetes)**를 사용하세요.

GitLab Pages#

일관성과 브랜딩을 위해 Pages 대신 GitLab Pages를 사용하세요.

단, 페이지의 첫 번째 언급 또는 UI에서 GitLab Pages를 사용한 경우, 이후에는 Pages를 사용할 수 있습니다.

GitLab Runner#

GitLab Runner는 타이틀 케이스로 표기하세요. 이것은 설치하는 제품입니다. 이 사용법에 대한 결정의 자세한 내용은 이 이슈를 참조하세요.

참조:

• runners

• runner managers

• runner workers

GitLab SaaS#

GitLab SaaS는 GitLab.com(멀티 테넌트 SaaS)과 GitLab Dedicated(싱글 테넌트 SaaS) 모두를 지칭합니다.

GitLab SaaS 사용을 피하고, 대신 특정 오퍼링을 지칭하세요.

GitLab Self-Managed#

고객이 직접 관리하는 GitLab 설치를 지칭할 때 GitLab Self-Managed를 사용하세요.

필요에 따라 instance 설명어를 사용하세요. installation은 사용하지 마세요.

사용할 표현:

• GitLab Self-Managed

• a GitLab Self-Managed instance

사용하지 말 것:

• A GitLab Self-Managed installation

• A Self-Managed GitLab installation

• A self-managed GitLab installation

• A GitLab instance that is GitLab Self-Managed

GitLab Self-Managed를 설명할 때 instance를 단독으로 사용할 수 있습니다. 예:

• On your instance, ensure the port is open.

• Verify that the instance is publicly accessible.

self-managed도 참조하세요.

GitLab.com#

URL 또는 제품 오퍼링을 지칭할 때 GitLab.com을 사용하세요. GitLab.com은 GitLab이 관리하는 인스턴스입니다.

GitLab Workflow extension for VS Code#

GitLab Workflow extension for VS Code, GitLab Workflow for VS Code 또는 GitLab Workflow는 사용하지 마세요.

이 확장 기능은 GitLab for VS Code로 이름이 변경되었습니다.

GraphiQL#

이 도구를 지칭할 때는 GraphiQL 또는 GraphQL explorer를 사용하세요.

대부분의 경우 설명어 없이 GraphiQL 단독으로 사용해야 합니다.

사용하지 말 것:

• GraphiQL explorer tool

• GraphiQL explorer

group access token#

group access token은 문장 대소문자(sentence case)를 사용합니다.

UI를 언급할 때는 첫 번째 단어를 대문자로 씁니다.

Guest#

Guest 권한에 대해 쓸 때는 대문자 G를 사용합니다.

풀어서 씁니다:

• 사용: if you are assigned the Guest role

• 대신: if you are a guest

Guest 권한이 최소 요구 권한일 때 다음과 같이 사용합니다:

• the Guest, Planner, Reporter, Security Manager, Developer, Maintainer, or Owner role

볼드를 사용하지 않습니다.

Guest permissions를 사용하지 않습니다. Guest 권한이 할당된 사용자에게는 관련 권한 집합이 있습니다.

guide#

사용자에게 직접 말하고 싶습니다. docs.gitlab.com에서는 페이지 제목의 일부로 guide를 사용하지 않습니다. 예를 들어, Snowplow Guide 대신 기능 자체와 사용 방법에 대해 설명하세요. 예: Use Snowplow to do xyz.

handy#

handy를 사용하지 않습니다. 사용자가 해당 기능이나 프로세스를 편리하다고 느끼지 않으면 신뢰를 잃게 됩니다. (Vale 규칙: Simplicity.yml)

high availability, HA#

GitLab 참조 아키텍처를 제외하고는 high availability 또는 HA를 사용하지 않습니다. 대신, 더 많은 사용자를 처리하도록 GitLab을 구성하는 방법에 대한 자세한 내용은 참조 아키텍처로 독자를 안내합니다.

다중 노드 환경을 의미하는 high availability setup과 같은 표현을 사용하지 않습니다. 대신 multi-node setup 또는 유사한 표현을 사용합니다.

higher#

버전 번호에 대해 말할 때 higher를 사용하지 않습니다.

사용:

• In GitLab 14.4 and later…

대신:

• In GitLab 14.4 and higher…

• In GitLab 14.4 and above…

hit#

press를 의미하는 hit을 사용하지 않습니다.

사용:

• Press ENTER.

대신:

• Hit the ENTER button.

I#

1인칭 단수를 사용하지 않습니다. 대신 you를 사용하거나 문장을 다시 씁니다.

i.e.#

라틴어 약어를 사용하지 않습니다. 대신 that is를 사용합니다. (Vale 규칙: LatinTerms.yml)

in, on#

UI 요소 위치를 설명할 때 전치사로 in을 사용합니다. 예:

• In the left sidebar, select Settings > CI/CD.

• In the Grant permission dialog, select Group.

• In the upper-right corner, select your avatar.

on은 다음 경우에만 사용합니다:

• 물리적 개체: Use the arrow keys on your keyboard.

• 표면으로서의 페이지: On the Settings page, you can configure multiple options.

from을 사용하지 않습니다.

in order to#

in order to를 사용하지 않습니다. 대신 to를 사용합니다. (Vale 규칙: Wordy.yml)

indexes, indices#

index의 복수형으로 indexes를 사용합니다.

단, Elasticsearch의 경우 indices를 사용합니다.

Installation from source#

자체 컴파일된 코드를 사용하는 설치 방법을 지칭할 때는 self-compiled를 사용합니다.

사용:

• For self-compiled installations…

대신:

• For installations from source…

자세한 내용은 다양한 설치 방법을 참조하세요.

-ing 형태의 단어#

가능하면 -ing 형태의 단어는 제거하세요. 번역하기 어려울 수 있으며, 보통 더 정확한 표현이 존재합니다. 예를 들어:

• The files using storage are deleted 대신 The files that use storage are deleted를 사용하세요.

• Delete files using the Edit button 대신 Use the Edit button to delete files를 사용하세요.

• Replicating your server is required 대신 You must replicate your server를 사용하세요.

IP address#

인터넷 프로토콜(IP)과 함께 사용하는 주소를 가리킬 때는 IP address를 사용하세요. IP 주소를 IP라고만 표기하지 마세요.

issue#

issue는 소문자로 표기하세요.

issue board#

issue board는 소문자로 표기하세요.

Issue Description Generation#

Issue Description Generation은 타이틀 케이스로 표기하세요.

페이지 내 첫 번째 언급 시에는 GitLab Duo Issue Description Generation을 사용하세요. 이후에는 Issue Description Generation만 단독으로 사용하세요.

Issue Discussion Summary#

Issue Discussion Summary는 타이틀 케이스로 표기하세요.

페이지 내 첫 번째 언급 시에는 GitLab Duo Issue Discussion Summary를 사용하세요. 이후에는 Issue Discussion Summary만 단독으로 사용하세요.

issue weights#

issue weights는 소문자로 표기하세요.

it#

it이라는 단어를 사용할 때는 it이 무엇을 가리키는지 명확해야 합니다. 명확하지 않다면 it 대신 해당 단어를 반복해서 사용하세요.

사용:

• The field returns a connection. The field accepts four arguments.

대신:

• The field returns a connection. It accepts four arguments.

this, these, that, those도 참고하세요.

job#

job과 동의어로 build를 사용하지 마세요. job은 .gitlab-ci.yml 파일에서 정의되며 파이프라인의 일부로 실행됩니다.

job과 CI를 함께 사용하려면 CI job 대신 CI/CD job을 사용하세요.

KB, KiB, kilobytes, kibibytes#

KB 및 KiB의 경우 Microsoft 가이던스를 따르세요.

Kubernetes executor#

GitLab Runner는 쿠버네티스 클러스터에서 job을 실행할 수 있습니다. 이를 위해 GitLab Runner는 Kubernetes executor를 사용합니다.

이 기능을 언급할 때는 다음을 사용하세요:

• Kubernetes executor for GitLab Runner

• Kubernetes executor

다음은 사용하지 마세요:

• GitLab Runner Kubernetes executor — 쿠버네티스 상표권을 침해할 수 있습니다.

language model, large language model#

언어 모델을 언급할 때는 정확하게 표현하세요. 모든 언어 모델이 대형(large)은 아니며, 모든 모델이 언어 모델인 것도 아닙니다. 확실하지 않을 때는 개발자나 PM에게 확인하세요.

LLM을 대형 언어 모델(large language model)의 약어로 사용할 수 있으며, 처음 등장 시 풀어서 표기하세요.

later#

버전 번호를 언급할 때는 later를 사용하세요.

사용:

• In GitLab 14.1 and later…

대신:

• In GitLab 14.1 and higher…

• In GitLab 14.1 and above…

• In GitLab 14.1 and newer…

level#

인스턴스, 프로젝트 또는 그룹의 맥락에서는 가능하면 level을 피하세요.

사용:

• This setting is turned on for the instance.

• This setting is turned on for the group and its subgroups.

• This setting is turned on for projects.

대신:

• This setting is turned on at the instance level.

• 이 설정은 그룹 수준에서 활성화됩니다.

• 이것은 프로젝트 수준 설정입니다.

license#

라이선스와 구독은 다릅니다.

• 라이선스는 사용자가 구매한 구독에 대한 접근 권한을 부여합니다. 라이선스에는 시트 수와 구독 날짜 같은 정보가 포함됩니다.

• 구독은 사용자가 구매하는 구독 티어입니다.

사용:

• 인스턴스에 라이선스를 추가합니다.

• 구독을 구매합니다.

다음 대신:

• 라이선스를 구매합니다.

• 라이선스를 구입합니다.

가능하면 cloud license 또는 cloud licensing 용어는 사용하지 마세요.

다음 용어는 UI 및 이메일에 표시됩니다. 필요한 경우 사용할 수 있습니다:

• Online license - GitLab과 동기화된 라이선스

• Offline license - GitLab과 동기화되지 않은 라이선스

• Legacy license - 동기화가 가능해지기 전에 생성된 라이선스

전반적인 라이선싱 및 동기화 프로세스의 일부로 고객이 이메일로 받는 파일을 설명할 때 legacy license file 및 offline license file 용어를 사용할 수도 있습니다.

단, 가능하다면 해당 용어에 의존하기보다는 더 구체적인 설명을 사용하세요.

lifecycle, life cycle, life-cycle#

lifecycle는 한 단어로 사용합니다. life cycle 또는 life-cycle은 사용하지 마세요.

(Vale 규칙: SubstitutionWarning.yml)

limitations#

Limitations를 주제 제목으로 사용하지 마세요. 자세한 내용은 참조 주제 제목을 참조하세요.

꼭 필요하다면 Known issues 제목을 사용할 수 있습니다.

list#

dropdown list를 가리킬 때 list를 사용하지 마세요. 대신 dropdown list 전체 표현을 사용하세요.

또한 페이지를 가리킬 때도 list를 사용하지 마세요. 예를 들어, Issues 페이지에는 이슈 목록이 채워집니다. 그러나 이것은 Issues 페이지라고 불러야 하며, Issues list라고 부르지 마세요.

log in, log on#

다음을 사용하지 마세요:

• log in.

• log on.

• login

대신 sign in을 사용하세요.

단, 사용자 인터페이스에 Log in이 표시된다면 UI와 일치시켜야 합니다.

limited availability#

limited availability는 소문자로 사용합니다. 예:

• 이 기능은 limited availability 상태입니다.

• Hosted runner는 limited availability 상태입니다.

다음을 사용하지 마세요:

• 이 기능은 limited availability에 도달했습니다.

limited availability를 약어 LA로 표기하지 마세요.

logged-in user, logged in user#

logged-in user 또는 logged in user 대신 authenticated user를 사용하세요.

lower#

버전 번호를 말할 때 lower를 사용하지 마세요.

사용:

• GitLab 14.1 이하 버전에서.

다음 대신:

• GitLab 14.1 and lower.

• GitLab 14.1 and older.

machine learning#

machine learning은 소문자로 사용합니다.

a machine learning model처럼 machine learning이 형용사로 사용될 때는 하이픈을 붙이지 않습니다. 하이픈이 문법적으로 더 정확할 수 있지만, 더 정밀하게 쓰려다 일관성이 없어질 위험이 있습니다.

Maintainer#

Maintainer 권한에 대해 쓸 때는 대문자 M을 사용합니다.

풀어서 작성하세요:

• 사용: if you are assigned the Maintainer role

• 대신: if you are a maintainer

Maintainer 권한이 최소 요구 권한인 경우 다음을 사용하세요:

• the Maintainer or Owner role

볼드체를 사용하지 마세요.

Maintainer permissions를 사용하지 마세요. Maintainer 권한을 할당받은 사용자는 관련된 권한 집합을 가집니다.

mankind#

mankind를 사용하지 마세요. 대신 people 또는 humanity를 사용하세요. (Vale 규칙: InclusiveLanguage.yml)

manpower#

manpower를 사용하지 마세요. workforce 또는 GitLab team members와 같은 단어를 사용하세요. (Vale 규칙: InclusiveLanguage.yml)

master#

master를 사용하지 마세요. 샘플 기본 브랜치 이름이 필요한 경우 main을 사용하세요. (Vale 규칙: InclusiveLanguage.yml)

may, might#

Might는 어떤 일이 발생할 가능성이 있음을 의미합니다. might는 트러블슈팅 문서에서 자주 사용됩니다.

May는 무언가를 해도 된다는 허가를 부여합니다. may 대신 can을 고려하세요.

이러한 용어를 사용하는 문구를 다른 방식으로 표현하는 것을 고려하세요. 이 용어들은 종종 가능성과 불확실성을 나타내는데, 기술 문서는 정확성을 추구합니다.

you can도 참조하세요.

사용:

• The committed_date and authored_date fields are generated from different sources, and might not be identical.

• A typical pipeline consists of four stages, executed in the following order:

대신:

• The committed_date and authored_date fields are generated from different sources, and may not be identical.

• A typical pipeline might consist of four stages, executed in the following order:

MB, MiB, megabytes, mebibytes#

MB 및 MiB의 경우 Microsoft 가이드를 따르세요.

member#

사용자 계정을 그룹 또는 프로젝트에 추가하면 해당 사용자 계정은 member가 됩니다.

Merge Commit Message Generation#

Merge Commit Message Generation에는 제목 표기를 사용하세요.

페이지에서 처음 언급할 때는 GitLab Duo Merge Commit Message Generation을 사용하세요. 이후에는 Merge Commit Message Generation만 사용하세요.

merge request branch#

merge request branch를 사용하지 마세요. branch를 참조하세요.

merge requests#

merge requests에는 소문자를 사용하세요. 약어 MR은 피하되, 반드시 사용해야 한다면 처음 사용 시 풀어서 쓰세요.

Merge Request Summary#

Merge Request Summary에는 제목 표기를 사용하세요.

페이지에서 처음 언급할 때는 GitLab Duo Merge Request Summary를 사용하세요. 이후에는 Merge Request Summary만 사용하세요.

milestones#

milestones에는 소문자를 사용하세요.

Minimal Access#

Minimal Access 권한에 대해 작성할 때:

• M과 A를 대문자로 사용하세요.

• 풀어서 작성하세요:

사용: if you are assigned the Minimal Access role

• 대신: if you are a Minimal Access user

• Minimal Access 권한이 최소 요구 권한인 경우:

사용: at least the Minimal Access role

• 대신: the Minimal Access role or higher

볼드체를 사용하지 마세요.

Minimal Access permissions를 사용하지 마세요. Minimal Access 권한을 할당받은 사용자는 관련된 권한 집합을 가집니다.

model registry#

GitLab model registry 기능 및 기능성을 문서화할 때는 소문자를 사용하세요.

사용:

• The GitLab model registry supports A, B, and C.

• You can publish a model to your project’s model registry.

models#

사용 방법은 language models를 참조하세요.

n/a, N/A, not applicable#

가능하면 not applicable을 풀어서 사용하세요. 단어를 전부 쓰면 영어가 모국어가 아닌 사용자에게 도움이 되고 대소문자 불일치 문제를 피할 수 있습니다.

namespace#

개인 네임스페이스와 그룹 네임스페이스를 구분할 때 namespace를 사용하세요. namespace를 group 또는 top-level group의 동의어로 사용하지 마세요.

GitLab.com에서 최상위 그룹 Owner는 자신의 그룹과 프로젝트를 완전히 제어할 수 있습니다. GitLab.com은 GitLab 팀이 관리하므로 일반 사용자는 관리자 액세스 권한을 가질 수 없습니다.

예시:

• 개인 네임스페이스 또는 그룹 네임스페이스에서 이 작업을 수행할 수 있습니다.

• 최상위 그룹에 대한 Owner 권한이 있어야 합니다.

navigate#

navigate를 사용하지 마세요. 대신 go를 사용하세요. 예시:

• Go to this webpage.

• Open a terminal and go to the runner directory.

(Vale rule: SubstitutionWarning.yml)

need to#

need to는 장황하므로 가능하면 사용하지 마세요.

예를 들어, 변수가 필수인 경우, You need to set the variable 대신 다음을 사용하세요:

• Set the variable.

• You must set the variable.

변수가 권장인 경우:

• You should set the variable.

변수가 선택 사항인 경우:

• You can set the variable.

new#

종종 new라는 단어는 피할 수 있습니다. 객체를 생성하면 그것은 새것이므로 이 추가 단어는 필요하지 않습니다.

create 및 add도 참조하세요.

newer#

버전 번호에 대해 이야기할 때 newer를 사용하지 마세요.

사용:

• In GitLab 14.4 and later…

대신 다음을 사용하지 마세요:

• In GitLab 14.4 and higher…

• In GitLab 14.4 and above…

• In GitLab 14.4 and newer…

node#

GitLab 사이트의 개별 서버입니다. 단일 사이트에는 여러 노드가 포함될 수 있습니다. 노드를 설명할 때 primary 또는 secondary를 사용하지 마세요. 대신 primary site 또는 secondary site를 사용하세요. (Vale rule: SubstitutionWarning.yml)

primary, secondary도 참조하세요.

normal, normally#

일반적이거나 전형적이거나 표준적인 방식을 의미하는 데 normal을 사용하지 마세요. 대신 해당 용어들을 사용하세요.

사용:

• Typically, you specify a certificate.

• Usually, you specify a certificate.

• Follow the standard Git workflow.

대신 다음을 사용하지 마세요:

• Normally, you specify a certificate.

• Follow the normal Git workflow.

(Vale rule: Normal.yml)

note that#

note that은 장황하므로 사용하지 마세요.

사용:

• You can change the settings.

대신 다음을 사용하지 마세요:

• Note that you can change the settings.

offerings#

현재 제품 오퍼링은 다음과 같습니다:

• GitLab.com

• GitLab Self-Managed

• GitLab Dedicated

• GitLab Dedicated for Government

가용성 세부 정보는 이러한 오퍼링을 반영합니다.

older#

버전 번호를 언급할 때 older를 사용하지 마세요.

사용:

• In GitLab 14.1 and earlier.

대신 사용하지 않을 표현:

• In GitLab 14.1 and lower.

• In GitLab 14.1 and older.

Omnibus GitLab#

Linux 패키지를 사용하는 설치 방법을 언급할 때는 Linux package로 표기합니다.

사용:

• For installations that use the Linux package…

대신 사용하지 않을 표현:

• For installations that use Omnibus GitLab…

자세한 내용은 다양한 설치 방법을 참고하세요.

once#

once는 한 번을 의미합니다. after 또는 when의 의미로 사용하지 마세요.

사용:

• When the process is complete…

대신 사용하지 않을 표현:

• Once the process is complete…

only#

only는 수식하는 단어 바로 옆에 위치시키세요.

다음 예시에서 only는 명사 projects를 수식합니다. 이는 하나의 프로젝트 유형(비공개 프로젝트)만 생성할 수 있다는 의미입니다.

• You can create only private projects.

다음 예시에서 only는 동사 create를 수식합니다. 이는 비공개 프로젝트를 삭제하거나 사용자를 추가하는 등 다른 작업은 수행할 수 없다는 의미입니다.

• You can only create private projects.

optional#

명령 인수, 파라미터 값, 파일 등 선택 사항이 있을 경우 Optional 뒤에 마침표를 붙여 사용합니다. 선택적 토픽의 경우 토픽 제목에 **(optional)**을 추가합니다.

예:

### This is a topic (optional)

- `value`: Optional. Use it to do something.

선택적 작업 단계에 대해서도 동일한 지침을 따르세요.

organizations#

organizations 최상위 엔티티를 언급할 때:

• 소문자를 사용합니다.

• 단어의 복수형을 사용합니다.

개별 조직을 언급할 때는 organization을 사용합니다.

예:

• Use organizations to manage users, projects, and groups.

• Add users to your organization.

override#

일시적인 대체를 나타낼 때 override를 사용합니다.

예를 들어, job이 실행될 때 값이 재정의될 수 있습니다. 원래 값은 변경되지 않습니다.

overwrite#

영구적인 대체를 나타낼 때 overwrite를 사용합니다.

예를 들어, 로그 파일이 같은 이름의 로그 파일을 덮어쓸 수 있습니다.

Owner#

Owner 권한에 대해 쓸 때는 대문자 O를 사용합니다.

다음과 같이 풀어서 씁니다:

• 사용: if you are assigned the Owner role

• 대신 사용하지 않을 표현: if you are an owner

굵게 표시하지 마세요.

Owner 권한은 사용하지 마세요. Owner 권한을 할당받은 사용자는 관련 권한 집합을 가집니다. Owner는 관리자를 제외하고 사용자가 가질 수 있는 가장 강력한 권한입니다.

package registry#

GitLab 패키지 레지스트리 기능과 기능성을 문서화할 때는 소문자를 사용하세요.

사용 예:

• GitLab package registry는 A, B, C를 지원합니다.

• 프로젝트의 package registry에 패키지를 게시할 수 있습니다.

page#

“Issues 페이지에서”와 같은 문구를 작성할 때는 해당 페이지로 이동하는 방법에 대한 단계가 근처에 있는지 확인하세요. 그렇지 않으면 사람들이 Issues 페이지가 무엇인지 모를 수 있습니다.

페이지 이름은 페이지 상단의 UI에서 확인할 수 있거나 이동 경로(breadcrumb)에 포함되어 있어야 합니다.

문서는 UI의 대소문자와 일치해야 하며, 페이지 이름은 굵게 표시되어야 합니다. 예를 들면:

• Test cases 페이지에서 …

panel#

화면 측면에 고정되지 않은 GitLab UI의 주요 영역을 지칭할 때는 panel을 사용하세요. panel의 콘텐츠는 컨텍스트에 따라 달라집니다.

참조: UI 요소 이름, top bar 및 sidebar.

parent#

항상 복합 명사로 사용하세요.

direct ancestor 또는 ascendant는 사용하지 마세요.

예시:

• parent directory

• parent group

• parent project

• parent commit

• parent issue

• parent item

• parent epic

• parent objective

• parent pipeline

참조: child, subgroup.

per#

per는 여러 가지 의미를 가질 수 있으므로 사용하지 마세요.

대신 구체적인 전치사구를 사용하세요:

• for each

• through

• by

• every

• according to

permissions#

특정 작업에 필요한 권한을 비교할 때는 more 또는 fewer를 사용하세요. 예를 들면:

• Guest 권한은 Developer 권한보다 fewer permissions를 가집니다.

• 더 많은 권한을 얻으려면 다른 역할이 있어야 합니다.

• Owner 권한은 가장 많은 permissions를 가집니다.

roles와 permissions를 혼용하지 마세요. 각 사용자에게는 역할이 할당됩니다. 각 역할에는 권한 집합이 포함됩니다.

Permissions는 access levels와 동일하지 않습니다.

personal access token#

personal access token에는 문장 형식 대소문자(sentence case)를 사용하세요.

UI를 참조할 때는 첫 번째 단어를 대문자로 작성하세요.

Planner#

Planner 권한에 대해 작성할 때는 대문자 P를 사용하세요.

다음과 같이 풀어서 작성하세요:

• 사용: if you are assigned the Planner role

• 대신 사용하지 않음: if you are a planner

Planner 권한이 최소 요구 권한인 경우 다음을 사용하세요:

• the Planner, Reporter, Security Manager, Developer, Maintainer, or Owner role

굵게 표시하지 마세요.

Planner permissions는 사용하지 마세요. Planner 권한을 할당받은 사용자는 관련 권한 집합을 가집니다.

please#

제품 문서에서 please는 사용하지 마세요.

UI 텍스트에서는 사용자에게 불편을 끼쳤을 때 please를 사용하세요. 자세한 내용은

Microsoft 스타일 가이드를 참조하세요.

preferences#

사용자별 테마 및 레이아웃과 같은 시스템 수준 설정을 설명할 때는 preferences를 사용합니다.

Premium#

구독 티어를 나타낼 때는 대문자로 Premium을 사용합니다. 다른 구독 티어와 함께 Premium을 언급할 때는 구독 티어 지침을 따르세요.

prerequisites#

사용자가 작업을 완료하기 전에 반드시 수행해야 하는 작업이나 충족해야 하는 조건을 문서화할 때는 prerequisites를 사용합니다. requirements는 사용하지 마세요.

Prerequisites는 항목이 하나뿐이더라도 항상 복수형을 사용해야 합니다.

자세한 내용은 task 주제 유형을 참조하세요.

튜토리얼 페이지 유형에서는 prerequisites 대신 before you begin을 사용합니다.

press#

키보드 키에 대해 이야기할 때는 press를 사용합니다. 예:

• 명령을 중지하려면 Control+C를 누르세요.

primary, secondary#

혼동을 줄이기 위해 명사가 아닌 형용사로 사용합니다. 예:

• primary database, secondary database

• primary site, secondary site (Geo의 경우)

primary node 또는 secondary node를 참조하세요.

profanity#

욕설을 사용하지 마세요. 욕설은 다른 사용자와 기여자에게 부정적인 영향을 줄 수 있으며, 이는 GitLab의 다양성, 포용, 소속감 가치에 반합니다.

project#

repository, project를 참조하세요.

project access token#

project access token은 문장 형식으로 표기합니다.

UI를 언급할 때는 첫 번째 단어를 대문자로 씁니다.

provision#

클라우드 인프라 프로비저닝에 대해 언급할 때는 provision이라는 용어를 사용합니다. 인프라를 프로비저닝한 다음 애플리케이션을 배포합니다.

예를 들어, 다음과 같이 작성할 수 있습니다:

• Provision an AWS EKS cluster and deploy your application to it.

push rules#

push rules는 소문자로 표기합니다.

quite#

quite는 장황하므로 사용하지 마세요.

README file#

the README file 또는 the README.md file에는 백틱과 소문자를 사용합니다.

가능하면 전체 문구를 사용합니다: the README file

복수형은 README files를 사용합니다.

recommend, we recommend#

we recommend 대신 you should를 사용합니다. 사용자에게 동료에게 말하는 것처럼 이야기하고, we와 them의 구분을 피하려고 합니다.

• You should set the variable. (권장 사항입니다.)

• Set the variable. (필수 사항입니다.)

• You can set the variable. (선택 사항입니다.)

recommended steps도 참조하세요.

register#

register 또는 sign up 대신 create a user account를 사용합니다.

reindex#

검색에 대해 이야기할 때는 re-index 대신 reindex를 사용합니다.

remove#

객체가 계속 존재하는 경우 remove를 사용합니다. 예를 들어, 에픽에서 이슈를 제거할 수 있지만 이슈는 여전히 존재합니다.

객체가 완전히 삭제되는 경우에는 대신 delete를 사용합니다.

Reporter#

Reporter 권한에 대해 작성할 때는 대문자 R을 사용합니다.

풀어서 작성합니다:

• 사용: if you are assigned the Reporter role

• 대신에: if you are a reporter

Reporter 권한이 최소 요구 권한인 경우 다음을 사용합니다:

• the Reporter, Security Manager, Developer, Maintainer, or Owner role

굵게 표시하지 마세요.

Reporter permissions는 사용하지 마세요. Reporter 권한을 할당받은 사용자는 관련 권한 집합을 가집니다.

repository, project#

GitLab 프로젝트에는 Git 리포지터리를 비롯한 다양한 요소가 포함됩니다.

커밋, 브랜치, 태그, 그리고 클로닝, 페칭, 푸싱, 풀링 등의 Git 특화 작업과 Git 데이터를 언급할 때는 repository를 사용합니다.

리포지터리, 위키, 이슈, 포크, 설정 및 기타 기능을 관리하는 GitLab 사용자 인터페이스를 언급할 때는 project를 사용합니다.

예시:

• 변경 내용을 업스트림 리포지터리에 푸시합니다.

• 업스트림 프로젝트의 포크를 생성합니다.

• 리포지터리에서 기본 브랜치 이름을 변경합니다.

• 프로젝트를 다른 그룹으로 이전합니다.

Repository Mirroring#

Repository Mirroring은 제목 표기(title case)를 사용합니다.

requirements#

사용자가 단계를 완료하기 전에 반드시 수행해야 하는 작업이나 충족해야 하는 조건을 문서화할 때:

• 작업의 경우 prerequisites를 사용합니다. 자세한 내용은 태스크 토픽 유형을 참조합니다.

• 튜토리얼의 경우 before you begin을 사용합니다. 자세한 내용은 튜토리얼 페이지 유형을 참조합니다.

requirements는 사용하지 않습니다.

reset#

항목을 새 상태로 초기화하는 작업을 설명할 때 reset을 사용합니다.

resolution, resolve#

문제 해결 방법이 이슈를 영구적으로 수정하는 경우 resolution을 사용합니다. resolution은 일반적으로 문제를 수정하기 위한 파일 및 코드 변경을 수반합니다. 예시:

• 이 이슈를 해결하려면 .gitlab-ci.yml 파일을 편집합니다.

• 한 가지 해결 방법은 .gitlab-ci.yml 파일을 편집하는 것입니다.

workaround도 참조합니다.

respectively#

respectively는 사용하지 말고 더 명확하게 표현합니다.

사용할 표현:

• 사용자를 생성하려면 Create user를 선택합니다. 기존 사용자의 경우 Save changes를 선택합니다.

사용하지 않을 표현:

• 새 사용자를 생성했거나 기존 사용자를 편집했다면 각각 Create user 또는 Save changes를 선택합니다.

restore#

restore에 관한 지침은 Microsoft 스타일 가이드를 참조합니다.

review app#

review app은 소문자를 사용합니다.

roles#

사용자는 프로젝트 또는 그룹에 대한(for) 권한을 보유합니다.

사용할 표현:

• 해당 그룹에 대한 Owner 권한이 있어야 합니다.

사용하지 않을 표현:

• 그룹의(of) Owner 권한이 있어야 합니다.

작업을 수행하기 위해 사용자가 보유해야 하는 권한을 언급할 때는 최소 권한부터 시작하여 해당되는 모든 권한을 나열합니다:

• Developer, Maintainer, 또는 Owner 권한이 있어야 합니다.

roles와 permissions을 같은 의미로 사용하지 않습니다. 각 사용자에게는 권한(role)이 할당됩니다. 각 권한(role)에는 일련의 퍼미션(permission) 세트가 포함됩니다.

권한(role) 유형에는 사용자 정의(custom)와 기본(default) 두 가지가 있습니다.

권한(role)은 access levels와 동일하지 않습니다.

roll back#

GitLab 버전을 이전 버전으로 변경할 때 roll back을 사용합니다.

라이선스나 구독에는 roll back을 사용하지 않습니다. 대신 change the subscription tier를 사용합니다.

Root Cause Analysis#

Root Cause Analysis는 제목 표기(title case)를 사용합니다.

페이지에서 처음 언급할 때는 GitLab Duo Root Cause Analysis를 사용합니다. 이후에는 Root Cause Analysis만 사용합니다.

runner, runners#

runners는 소문자를 사용합니다. 러너는 CI/CD job을 실행하는 에이전트입니다. GitLab Runner 및 이 이슈도 참조합니다.

러너를 언급할 때, 러너가 고객의 GitLab 인스턴스에 설치되어 있음을 명시해야 하는 경우 self-hosted 대신 self-managed를 사용합니다.

러너의 범위를 언급할 때는 다음을 사용합니다:

• project runner: 특정 프로젝트와 연결됩니다.

• group runner: 그룹 내 모든 프로젝트와 하위 그룹에서 사용 가능합니다.

• instance runner: GitLab 인스턴스 내 모든 그룹과 프로젝트에서 사용 가능합니다.

runner manager, runner managers#

runner manager는 소문자로 표기합니다. 이는 오토스케일링을 위해 여러 러너를 생성할 수 있는 러너 유형입니다. GitLab Runner도 참조하세요.

runner worker, runner workers#

runner worker는 소문자로 표기합니다. 이는 러너가 호스트 컴퓨팅 플랫폼에서 job을 실행하기 위해 생성하는 프로세스입니다. GitLab Runner도 참조하세요.

runner authentication token#

runner token, authentication token, token 등의 변형 대신 runner authentication token을 사용합니다. 러너는 생성될 때 runner authentication token을 할당받으며, job을 실행할 때 GitLab에 인증하는 데 이를 사용합니다.

Runner SaaS, SaaS runners#

Runner SaaS 또는 SaaS runners는 사용하지 않습니다.

GitLab.com 및 GitLab Dedicated에서 호스팅되는 러너를 설명하는 주요 기능 이름으로 GitLab-hosted runners를 사용합니다.

오퍼링과 운영 체제를 지정할 때는 다음을 사용합니다:

• hosted runners for GitLab.com

• hosted runners for GitLab Dedicated

• hosted runners on Linux for GitLab.com

• hosted runners on Windows for GitLab.com

GitLab- 접두사 없이, 또는 오퍼링이나 운영 체제 없이 hosted runners를 단독으로 사용하지 않습니다.

rules#

규칙과 그 동작을 설명할 때는 다음을 사용합니다:

• Restrictive: 작업을 제한하거나 제약하는 규칙을 설명합니다.

• Permissive: 작업을 허용하거나 활성화하는 규칙을 설명합니다.

예시:

• 이 규칙은 기본 설정보다 더 restrictive합니다.

• Permissive 규칙은 더 넓은 접근을 허용합니다.

• 여러 규칙이 일치하면 가장 restrictive한 규칙이 적용됩니다.

(s)#

단어를 선택적으로 복수형으로 만들기 위해 **(s)**를 사용하지 않습니다. 이는 이해 속도를 늦출 수 있습니다. 예시:

다음을 사용하세요:

• Select the jobs you want.

대신 다음을 사용하지 마세요:

• Select the job(s) you want.

무언가를 여러 개 선택할 수 있다면 단어를 복수형으로 작성하세요.

sanity check#

sanity check는 사용하지 않습니다. 대신 check for completeness를 사용하세요. (Vale rule: InclusiveLanguage.yml)

scalability#

추가 사용자를 위한 GitLab 성능 향상에 대해 이야기할 때 scalability를 사용하지 않습니다. scale 또는 scaling이라는 단어는 때로 허용되지만, 추가 사용자를 위한 GitLab 성능 향상에 관한 내용은 독자를 GitLab reference architectures 페이지로 안내해야 합니다.

search#

검색할 때는 상단 바의 검색 상자에 문자열을 입력합니다. 검색 결과는 검색 페이지에 표시됩니다.

검색은 filtering과 다릅니다.

seats#

구독 청구 모델을 참조할 때:

• GitLab.com의 경우 seats를 사용합니다. 고객은 seat를 구매합니다. 사용자가 그룹에 초대되면 일부 예외를 제외하고 seat를 점유합니다.

• GitLab Self-Managed의 경우 users를 사용합니다. 고객은 지정된 수의 users에 대한 구독을 구매합니다.

section#

페이지의 영역을 설명할 때 section을 사용합니다. 예를 들어, 페이지에 UI를 별도 영역으로 구분하는 선이 있는 경우 이 영역을 section이라고 합니다.

확장/축소 가능한 영역을 section으로 생각하는 경우가 많습니다. section의 확장 또는 축소를 참조할 때 section이라는 단어를 포함하지 않습니다.

다음을 사용하세요:

• Expand Auto DevOps.

대신 다음을 사용하지 마세요:

• Do not: Expand the Auto DevOps section.

select#

버튼, 링크, 메뉴 항목, 목록에는 select를 사용합니다. Select는 더 많은 기기에 적용되는 반면, click은 마우스에 더 특화되어 있습니다.

단, right-click과 click-through demo의 경우 예외를 둘 수 있습니다.

self-hosted model#

고객이 호스팅하는 언어 모델(GitLab이 아닌)을 지칭할 때 self-hosted model(소문자)을 사용합니다.

언어 모델은 LLM(대규모 언어 모델)일 수 있지만, 그렇지 않을 수도 있습니다.

Self-Hosted#

GitLab Self-Managed와의 혼동을 피하기 위해, GitLab Duo Self-Hosted 기능을 지칭할 때 Self-Hosted만 단독으로 사용하지 마세요.

고객이 호스팅하는 언어 모델(GitLab이 호스팅하는 것이 아닌)을 지칭하는 경우가 아니라면, 항상 GitLab Duo Self-Hosted를 제목 대소문자 형식으로 전체 표기하세요.

self-managed#

고객의 GitLab 설치를 지칭할 때는 GitLab Self-Managed를 사용하세요.

• self-hosted는 사용하지 마세요.

GitLab Self-Managed를 참조하세요.

Service Desk#

Service Desk는 제목 대소문자 형식으로 표기하세요.

session#

에이전트가 플로우를 처리 중일 때 세션이 실행됩니다. 세션은 시작하고 종료할 수 있습니다.

AI session 또는 agent session은 사용하지 마세요.

settings#

**설정(setting)**은 제품의 기본 동작을 변경합니다. 설정은 키/값 쌍으로 구성되며, 일반적으로 하나 이상의 옵션이 있는 레이블로 표현됩니다.

setup, set up#

setup은 명사로, set up은 동사로 사용하세요. 예:

• Your remote office setup is amazing.

• To set up your remote office correctly, consider the ergonomics of your work area.

set up과 configure를 혼동하지 마세요. Set up은 처음으로 무언가를 수행하는 것을 의미합니다. 예:

• Set up your installation.

• Configure your installation.

sidebar, top bar#

GitLab UI의 좌우 고정 영역을 지칭할 때는 sidebar를 사용하세요. 검색 상자와 사용자 아바타가 포함된 상단 고정 영역을 지칭할 때는 top bar를 사용하세요.

상황에 따라 변경되는 주요 영역에는 panel을 사용하세요.

참조: UI 요소 명칭.

sign in, sign-in#

로그인 동작을 설명할 때는 다음을 사용하세요:

• sign in.

• 동사로는 sign in to. 예: Use your password to sign in to GitLab.

다음도 사용할 수 있습니다:

• single sign-on.

다음은 사용하지 마세요:

• sign on.

• sign into.

• log on, log in, 또는 log into.

사용자 인터페이스에 다른 단어가 표시되는 경우 해당 단어를 사용할 수 있습니다.

sign up#

계정 생성을 이야기할 때는 register 또는 sign up 대신 create a user account를 사용하세요.

a sign-up 대신 a new user account를 사용하세요.

기타 변형:

• sign-up restrictions 대신 new user account restrictions을 사용하세요.

• sign-up enabled 대신 allow new user accounts를 사용하세요.

signed-in user, signed in user#

signed-in user 또는 signed in user 대신 authenticated user를 사용하세요.

simply, simple#

simply 또는 simple은 사용하지 마세요. 사용자가 해당 과정을 간단하게 느끼지 못하면 신뢰를 잃게 됩니다. (Vale 규칙: Simplicity.yml)

since#

since는 시간적 맥락을 나타냅니다. 예: Since 1984, Bon Jovi has existed. because의 의미로 since를 사용하지 마세요.

사용:

• Because you have the Developer role, you can delete the widget.

대신 다음을 피하세요:

• Since you have the Developer role, you can delete the widget.

slashes#

and/or 대신 or를 사용하거나 문장을 다시 작성하세요. 이 규칙은 follow/unfollow와 같은 다른 슬래시에도 적용됩니다. 일부 예외(CI/CD 등)는 허용됩니다. (Vale 규칙: WordSlashWord.yml)

slave#

slave는 사용하지 마세요. 대안으로 secondary를 사용할 수 있습니다. (Vale 규칙: InclusiveLanguage.yml)

storages#

다음의 맥락에서:

• Gitaly의 경우, 스토리지는 물리적이며 반드시 storage라고 표기해야 합니다.

• Gitaly Cluster(Praefect)의 경우, 스토리지는 다음 중 하나일 수 있습니다:

가상 스토리지이며 반드시 virtual storage라고 표기해야 합니다.

• 물리적 스토리지이며 반드시 physical storage라고 표기해야 합니다.

Gitaly 스토리지는 물리적 경로를 가지고, 가상 스토리지는 가상 경로를 가집니다.

subagents#

sub-agents 대신 subagents(하이픈 없음)를 사용하세요.

subgroup#

sub-group 대신 subgroup(하이픈 없음)을 사용하세요. 또한, child group 또는 low-level group과 같은 하위 그룹의 대체 용어는 사용하지 마세요.

(Vale rule: SubstitutionWarning.yml)

subscription tier#

subscription 또는 subscription tier를 **license**와 혼동하지 마세요. 사용자는 subscription을 구매합니다. 해당 구독에는 tier가 있습니다.

티어를 설명하는 방법:

Suggested Reviewers#

Suggested Reviewers는 제목 표기(title case)를 사용하세요.

Suggested Reviewers는 항상 복수형으로 사용해야 하며, 일반적인 맥락에서 쓰이더라도 대문자로 표기합니다.

예시:

• Suggested Reviewers can recommend a person to review your merge request. (이 문구는 기능을 설명합니다.)

• As you type, Suggested Reviewers are displayed. (이 문구는 일반적인 맥락이지만 여전히 대문자를 사용합니다.)

TB, TiB, terabytes, tebibytes#

TB 및 TiB의 경우, Microsoft 가이드라인을 따르세요.

tab#

탭 이름에는 볼드체를 사용하세요. 예를 들어:

• The Pipelines tab

• The Overview tab

terminal#

terminal은 소문자로 사용하세요. 예를 들어:

• Open a terminal.

• From a terminal, run the docker login command.

Terraform Module Registry#

GitLab Terraform Module Registry는 제목 표기(title case)를 사용하되, 특정하지 않은 모듈에 대해 이야기할 때는 소문자 m을 사용하세요. 예를 들어:

• You can publish a Terraform module to your project’s Terraform Module Registry.

Test Generation#

Test Generation은 제목 표기(title case)를 사용하세요.

페이지에서 처음 언급할 때는 GitLab Duo Test Generation을 사용하세요. 이후에는 Test Generation만 단독으로 사용하세요.

text box#

UI 요소를 지칭할 때 field 또는 box 대신 text box를 사용하세요.

that#

명사를 설명할 때 that을 사용하지 마세요. 예를 들어:

다음과 같이 사용하세요:

• The file you save…

대신 다음은 사용하지 마세요:

• The file that you save…

this, these, that, those도 참조하세요.

there is, there are#

there is와 there are는 가능한 한 사용하지 마세요. 이 표현들은 주어를 숨깁니다.

다음과 같이 사용하세요:

• The bucket has holes.

대신 다음은 사용하지 마세요:

• There are holes in the bucket.

they#

특정 인물을 지칭하는 경우가 아니라면 성별 특정 대명사 사용을 피하세요. 성별 중립 대명사로 단수 they를 사용하세요.

this, these, that, those#

이 단어들 뒤에는 항상 명사를 함께 사용하세요. 예를 들면:

• 사용: This setting improves performance.

• 대신: This improves performance.

• 사용: These pants are the best.

• 대신: These are the best.

• 사용: That droid is the one you are looking for.

• 대신: That is the one you are looking for.

• 사용: Those settings must be configured. (또는 더 나은 표현: Configure those settings.)

• 대신: Those need to be configured.

to which, of which#

to which와 of which는 가급적 사용하지 말고, 전치사를 문장 끝에 오도록 하세요. 예시는 전치사를 참조하세요.

to-do item#

to-do item은 소문자로 쓰고 하이픈으로 연결하세요. (Vale 규칙: ToDo.yml)

To-Do List#

To-Do List는 제목 표기법(Title Case)을 사용하세요. (Vale 규칙: ToDo.yml)

toggle#

토글은 turn on 또는 turn off합니다. 예를 들면:

• Turn on the blah toggle.

top-level group#

top-level group은 소문자로 쓰고 하이픈으로 연결하세요.

root group은 사용하지 마세요.

TFA, two-factor authentication#

대신 2FA 및 two-factor authentication을 사용하세요.

turn on, turn off#

enable 또는 disable 대신 turn on과 turn off를 사용하세요.

자세한 내용은 Microsoft 스타일 가이드를 참조하세요.

enable 및 disable도 참조하세요.

type#

커서가 입력 위치에 그대로 유지될 때 type을 사용하세요. 예를 들어, 검색 창에서 입력을 시작하면 검색 결과가 나타납니다. 이때 검색 창에서 클릭으로 이동하지 않습니다.

예를 들면:

• Alex라는 이름의 모든 사용자를 보려면 Al을 입력하세요.

• 문서 팀의 모든 라벨을 보려면 doc을 입력하세요.

• 빠른 작업 목록을 보려면 /를 입력하세요.

enter도 참조하세요.

Ultimate#

구독 티어를 지칭할 때는 대문자로 Ultimate를 사용하세요. 다른 구독 티어와 함께 Ultimate를 언급할 때는 구독 티어 안내를 따르세요.

undo#

undo에 대한 안내는 Microsoft 스타일 가이드를 참조하세요.

units of measurement#

숫자와 측정 단위 사이에 공백을 사용하세요. 예를 들어, 128 GB. (Vale 규칙: Units.yml)

자세한 내용은 Microsoft 스타일 가이드를 참조하세요.

update#

소프트웨어의 최신 패치 버전을 설치하거나, API 및 프로그래밍 방식의 변경 사항을 문서화할 때 update를 사용하세요.

예를 들면:

• Update GitLab from 14.9 to 14.9.1.

• Use this endpoint to update user permissions.

다른 경우에는 update를 사용하지 마세요. 대신 upgrade 또는 **edit**를 사용하세요.

upgrade#

다음의 경우에 upgrade를 사용하세요:

• 더 높은 구독 티어(Premium 또는 Ultimate)를 선택하는 경우.

• GitLab의 최신 메이저(13.0) 또는 마이너(13.2) 버전을 설치하는 경우.

예를 들면:

• Upgrade to GitLab Ultimate.

• Upgrade GitLab from 14.0 to 14.1.

• Upgrade GitLab from 14.0 to 15.0.

다른 텍스트 없이 Upgrade GitLab이라는 문구를 사용할 때는 주의하세요.

제품 버전을 이야기하는 것인지, 구독 티어를 이야기하는 것인지를 주변 텍스트에서 명확히 하세요.

다운그레이드 및 롤백도 참조하세요.

upper left, upper right#

UI에서 방향을 안내할 때는 upper-left corner와 upper-right corner를 사용하세요. UI 요소가 모서리에 없는 경우에는 upper left와 upper right를 사용하세요.

top left와 top right는 사용하지 마세요.

자세한 내용은 Microsoft 스타일 가이드를 참조하세요.

useful#

useful은 사용하지 마세요. 사용자가 해당 프로세스를 유용하지 않다고 느끼면 신뢰를 잃게 됩니다. (Vale 규칙: Simplicity.yml)

user account#

user account를 생성합니다. user account에는 액세스 수준이 있습니다. user account를 그룹이나 프로젝트에 추가하면 해당 user account는 member가 됩니다.

using#

대부분의 경우 using은 피하세요. 주어를 숨기고 문장을 번역하기 어렵게 만듭니다. by using, that use를 사용하거나 문장을 다시 작성하세요.

예를 들어:

• 대신: The files using storage…

• 사용: The files that use storage…

• 대신: Change directories using the command line.

• 사용: Change directories by using the command line. 또는 더 좋은 표현: To change directories, use the command line.

utilize#

utilize는 사용하지 마세요. 대신 use를 사용하세요. 더 간결하고 비영어권 사용자도 이해하기 쉽습니다. (Vale 규칙: SubstitutionWarning.yml)

version, v#

GitLab의 버전을 설명할 때는 GitLab <버전 번호> 형식을 사용하세요. 예를 들어:

• You must have GitLab 16.0 or later.

다른 소프트웨어를 설명할 때는 해당 소프트웨어의 문서와 동일한 스타일을 사용하세요. 예를 들어:

• In Kubernetes 1.4, you can…

v 문자 옆의 공백에 주의하세요. 시맨틱 버저닝에서는 v 뒤에 공백이 없습니다. 예를 들어:

• v1.2.3

via#

라틴어 약어는 사용하지 마세요. 대신 with, through, 또는 by using을 사용하세요. (Vale 규칙: LatinTerms.yml)

virtual registry#

virtual registry는 소문자로 표기하세요.

페이지에서 처음 언급할 때는 GitLab virtual registry를 사용하세요. 이후에는 virtual registry만 사용하세요.

사용:

• The GitLab virtual registry supports A, B, and C.

• You can configure your applications to use one virtual registry instead of multiple upstream registries.

VS Code user interface#

VS Code와 Web IDE의 사용자 인터페이스를 설명할 때는 VS Code 문서의 사용법과 대소문자 표기를 따르세요. Command Palette와 Primary Side Bar 등이 그 예입니다.

Vulnerability Explanation#

Vulnerability Explanation은 타이틀 케이스로 표기하세요.

페이지에서 처음 언급할 때는 GitLab Duo Vulnerability Explanation을 사용하세요. 이후에는 Vulnerability Explanation만 사용하세요.

Vulnerability Resolution#

Vulnerability Resolution은 타이틀 케이스로 표기하세요.

페이지에서 처음 언급할 때는 GitLab Duo Vulnerability Resolution을 사용하세요. 이후에는 Vulnerability Resolution만 사용하세요.

we#

we는 가급적 사용하지 않고, 대신 사용자가 GitLab에서 어떻게 작업을 수행할 수 있는지에 초점을 맞추세요.

사용:

• Use widgets when you have work you want to organize.

대신:

• We created a feature for you to add widgets.

Web IDE user interface#

VS Code user interface를 참조하세요.

while#

while은 시간적으로 동시에 발생하는 상황을 나타낼 때만 사용하세요. 예를 들어, Leave the window open while the process runs.

비교를 나타낼 때는 while을 사용하지 마세요. 예를 들어, 다음과 같이 사용하세요:

• Job 1 can run quickly. However, job 2 is more precise.

다음 표현 대신:

• While job 1 can run quickly, job 2 is more precise.

자세한 내용은 Microsoft 스타일 가이드를 참조하세요.

whilst#

whilst는 사용하지 마세요. 대신 while을 사용하세요. while이 더 간결하며 영어가 모국어가 아닌 사람들이 이해하기 쉽습니다.

whitelist#

whitelist는 사용하지 마세요. 대안으로 allowlist를 사용할 수 있습니다. (Vale 규칙: InclusiveLanguage.yml)

within#

가능한 경우 within을 사용하지 마세요. 시간 프레임, 한도, 또는 경계를 언급하는 경우가 아니라면 대신 in을 사용하세요. 예를 들어:

• The upgrade occurs within the four-hour maintenance window.

• The Wi-Fi signal is accessible within a 30-foot radius.

(Vale 규칙: SubstitutionWarning.yml)

workaround#

트러블슈팅 해결 방법이 임시 수정인 경우 workaround를 사용하세요. workaround는 보통 즉각적인 수정이며 지속적인 문제가 있을 수 있습니다. 예를 들어:

• The workaround is to temporarily pin your template to the deprecated version.

resolution도 참조하세요.

workspace#

GitLab workspaces(개발을 위한 가상 샌드박스 환경)를 언급할 때만 workspace를 사용하세요. GitLab 기능과의 혼동을 피하기 위해 다른 개념을 지칭할 때 workspace를 단독으로 사용하지 마세요.

대신 다음을 사용하세요:

• GitLab 프로젝트를 의미하는 경우 project. 예를 들어, workspace-level skills 대신 project-level skills.

• IDE 워크스페이스를 언급하는 경우 IDE workspace 또는 IDE workspace folder.

• 터미널의 디렉터리와 폴더를 언급하는 경우 current working directory.

• IDE 워크스페이스 폴더 또는 현재 작업 디렉터리에 적용되는 MCP 클라이언트 구성 파일을 언급하는 경우 workspace configuration.

yet#

제품이나 기능에 대해 이야기할 때 yet을 사용하지 마세요. 문서는 오늘날의 제품 상태를 그대로 설명합니다.

태스크를 작성할 때 yet을 사용하고 싶을 수도 있습니다. yet을 사용하는 경우, 주변 구절이 현재 시제, 능동태로 작성되었는지 확인하세요.

미래 버전의 기능에 대해 작성하는 방법 안내 보기.

you, your, yours#

the user, the administrator 또는 the customer 대신 you를 사용하세요. 문서는 제품을 설치하거나, 구성하거나, 관리하거나, 사용하는 사용자 등 어떤 사용자이든 직접 말을 걸어야 합니다.

다음을 사용하세요:

• You can configure a pipeline.

• You can reset a user’s password. (관리자 대상 콘텐츠의 경우)

다음 표현 대신:

• Users can configure a pipeline.

• Administrators can reset a user’s password.

you can#

가능한 경우 you can 대신 능동 동사로 문장을 시작하세요.

예를 들어:

• Use code review analytics to view merge request data.

• Create a board to organize your team tasks.

• Configure variables to restrict pushes to a repository.

• Add links to external accounts you have, like Discord and X (formerly Twitter).

선택적인 작업에 you can을 사용하세요. 예를 들어:

• Use code review analytics to view metrics for each merge request. You can also use the API.

• Enter the name and value pairs. You can add up to 20 pairs for each streaming destination.