문서의 일관성을 유지하기 위해 Technical Writing 팀은 다음 단어 선택을 권장합니다. 추가로 참고할 자료는 다음과 같습니다.

• GitLab 핸드북에는 자주 잘못 쓰이는 용어 목록이 있습니다.
• 문서 스타일 가이드에 언어와 대문자 표기에 관한 세부 내용이 있습니다.
• GitLab 핸드북은 제3자 상표 사용에 관한 지침을 제공합니다.

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

• Microsoft Style Guide
• Google Developer Documentation Style Guide

.gitlab-ci.yml file#

the .gitlab-ci.yml file에는 백틱과 소문자를 사용합니다.

가능하면 전체 표현인 the .gitlab-ci.yml file을 사용합니다.

사용자가 CI/CD 구성 파일에 다른 이름을 지정할 수 있더라도, 대부분의 경우 the .gitlab-ci.yml file을 대신 사용합니다.

& (ampersand)#

라틴어 약어를 사용하지 않습니다. &를 사용하는 UI 요소를 문서화하는 경우가 아니라면 대신 and를 사용합니다.

@mention#

@mention은 가급적 사용하지 않습니다. 대신 mention이라고 쓰고, 멘션 항목으로 링크하는 것을 고려합니다. 백틱은 사용하지 않습니다.

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를 사용합니다. 예를 들면 다음과 같습니다.

• In the previous example, the dog had fleas.

제품 버전을 가리킬 때는 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#

액세스 수준은 roles, permissions와 다릅니다. 사용자를 만들 때 액세스 수준으로 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는 제목 표기 형식(title case)을 사용합니다. UI가 title case를 사용하기 때문입니다.

administrator#

administrator는 role이나 permission이 아닙니다. admin으로 줄여 쓰지 않습니다.

GitLab Self-Managed와 GitLab Dedicated에서는 다음과 같습니다.

• 사용자는 administrator가 되어 인스턴스 전체 설정을 변경할 수 있습니다.

• 인스턴스 전체 설정에 대한 사용자의 액세스 수준을 말할 때는 다음 중 하나를 사용합니다.

  • Administrator access.
  • You must have administrator access.

  다음과 같이 쓰지 않습니다.

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

GitLab.com에서는 다음과 같습니다.

• GitLab 팀원만 administrator가 되어 인스턴스 전체 설정을 변경할 수 있습니다.

• 다른 사용자는 GitLab.com 인스턴스의 administrator가 될 수 없습니다. 대신 특정 그룹이나 프로젝트를 완전히 제어할 수 있는 Owner 권한을 가질 수 있습니다.

• 이런 사용자가 GitLab.com administrator와 비교해 할 수 있는 일과 할 수 없는 일을 구체적으로 적습니다. 예를 들면 다음과 같습니다.

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

advanced search#

GitLab 인스턴스 전체를 더 빠르고 효율적으로 검색하는 기능을 가리킬 때는 advanced search를 소문자로 씁니다.

agent for Kubernetes#

GitLab agent for Kubernetes를 가리킬 때는 소문자를 사용합니다. 예를 들면 다음과 같습니다.

• To connect your cluster to GitLab, use the GitLab agent for Kubernetes.
• Install the agent in your cluster.
• Select an agent from the list.

GitLab Agent나 GitLab Agent for Kubernetes처럼 title case를 사용하지 않습니다.

agent만으로는 의미가 분명하지 않거나 다른 종류의 에이전트와 구분해야 할 때는 GitLab agent for Kubernetes를 사용합니다.

기술적인 맥락에서 해당 구성 요소를 가리킬 때는 백틱으로 감싼 agentk를 사용합니다.

agent for workspace#

워크스페이스 안에서 실행되며 워크스페이스에 접근하는 데 쓰이는 구성 요소를 가리킬 때는 소문자 agent for workspace를 사용합니다. Workspace에 title case를 사용하지 않습니다. 예를 들면 다음과 같습니다.

• The agent for workspace handles GitLab integration tasks in the workspace.
• Configure the agent for workspace to connect your development environment.

기술적인 맥락에서 해당 구성 요소를 가리킬 때는 백틱으로 감싼 agentw를 사용합니다.

agent for Kubernetes와 혼동하지 않습니다. agent만으로는 의미가 분명하지 않거나 다른 종류의 에이전트와 구분해야 할 때는 agent for workspace를 사용합니다.

agent access token#

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 - 에이전틱과 비에이전틱의 차이를 구분할 필요가 없을 때 사용합니다.
• Chat - 에이전틱과 비에이전틱의 차이를 구분할 필요가 없을 때 사용합니다.

다음은 사용하지 않습니다.

• 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만으로는 의미가 분명하지 않거나 다른 종류의 에이전트와 구분해야 할 때는 AI agent를 사용할 수 있습니다.

agent 단독으로는 소문자를 사용합니다. 에이전트 이름에는 title case를 사용합니다. 예: Code Review Agent.

AI 에이전트와 상호작용하는 동안에는 session이 실행 중입니다. 사용자는 세션을 중지할 수 있습니다.

하나 이상의 AI 에이전트가 flow에 속해, 하나의 문제를 함께 해결하도록 조율될 수 있습니다.

foundational agents를 포함해 여러 종류의 에이전트가 있습니다.

AI Catalog#

AI Catalog는 title case를 사용합니다. AI catalog(소문자)는 사용하지 않으며, 하이픈을 넣지 않습니다.

AI Gateway#

AI Gateway는 title case를 사용합니다. AI gateway(소문자)는 사용하지 않으며, 하이픈을 넣지 않습니다.

고객의 GitLab Dedicated 환경 안에서 실행되는 AI Gateway를 가리킬 때는 AI Gateway for GitLab Dedicated를 사용합니다. Dedicated-hosted AI Gateway나 GitLab Dedicated-hosted 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는 사용하지 않습니다. 예를 들면 다음과 같습니다.

• The firewall policies in an offline environment prevent the computer from accessing the internet.

allow, enable#

보안 관련 기능이나 기능 플래그의 상태를 설명하는 경우가 아니라면 allow와 enable은 가급적 사용하지 않습니다.

권장 표현:

• You can add a file to your repository.

피할 표현:

• This feature allows you to add a file to your repository.
• This feature enables users to add files to their repository.

이 표현은 기능을 구현한 사람이 아니라 사용자의 관점에서 쓰이므로 더 능동적입니다. 자세한 내용은 Microsoft Style Guide를 참고합니다.

allowlist#

동사로 사용하지 않습니다. 명사로만 사용합니다.

권장 표현:

• Add variables to an allowlist.

피할 표현:

• Allowlist variables.

analytics#

analytics와 contribution analytics, issue analytics 같은 변형은 소문자로 씁니다. 다만 UI의 대문자 표기가 다르면 문서를 UI에 맞춥니다.

예를 들면 다음과 같습니다.

• You can view merge request analytics for a project. They are displayed in the Merge Request Analytics dashboard.

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 Style Guide를 참고합니다.

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.

베타 기능을 다룰 때는 이 항목으로 링크하는 것도 좋습니다.

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: 리포지터리의 기본 브랜치입니다. 사용자는 UI에서 기본 브랜치를 설정할 수 있습니다. 기본 브랜치를 사용하는 예시에는 master 대신 main을 사용합니다.
• source branch: 머지하는 쪽의 브랜치입니다.
• target branch: 머지되는 쪽의 브랜치입니다.
• current 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 - 에이전틱과 비에이전틱의 차이를 구분할 필요가 없을 때 사용합니다.
• Chat - 에이전틱과 비에이전틱의 차이를 구분할 필요가 없을 때 사용합니다.

다음은 사용하지 않습니다.

• Duo Non-Agentic Chat (GitLab 없이)
• GitLab Duo Chat (non-agentic) (괄호 표기)
• Classic Chat

checkbox#

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

체크박스는 select(check나 enable 아님)하고 clear(deselect나 disable 아님)합니다. 예를 들면 다음과 같습니다.

• Select the Protect environment checkbox.
• Clear the Protect environment checkbox.

체크박스 자체를 가리켜야 한다면 선택됨 또는 해제됨 상태라고 말할 수 있습니다. 예를 들면 다음과 같습니다.

• Ensure the Protect environment checkbox is cleared.
• Ensure the Protect environment checkbox is selected.

(deselect에 대한 Vale 규칙: SubstitutionWarning.yml)

checkout, check out#

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

• Use git checkout to check out a branch locally.
• Check out the files you want to edit.

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를 생략할 수 있습니다. 예를 들면 다음과 같습니다.

• Test your code in a CI/CD pipeline. Configure the pipeline to run for merge requests.
• Store the value in a CI/CD variable. Set the variable to masked.

CI/CD minutes#

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

classic#

일부 GitLab Duo 기능은 비에이전틱입니다. 이런 기능을 classic이라고 부르지 않습니다.

click#

click은 사용하지 않습니다. 버튼, 링크, 메뉴 항목, 목록에는 대신 select를 사용합니다. Select는 더 다양한 기기에 적용되는 반면, click은 마우스에 한정됩니다.

다만 right-click과 click-through demo는 예외로 둘 수 있습니다.

cloud licensing#

인터넷을 통해 활성화 코드를 동기화하는 과정을 설명해야 하는 경우가 아니라면 cloud licensing이라는 표현을 피합니다.

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

예를 들면 다음과 같습니다.

• Your instance must be able to synchronize your subscription data with GitLab.

cloud-native#

Kubernetes 클러스터를 사용해 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은 항상 단수형이어야 합니다.

예:

• Use code completion to populate the file.

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은 항상 단수형이어야 합니다.

예:

• Use code generation to create code based on your comments.
• Adjust your code generation results by adding code comments to your file.

Code Owner, code owner, CODEOWNER#

기능 이름이나 개념을 가리킬 때는 Code Owners를 사용합니다. 예를 들면 다음과 같습니다.

• Use the Code Owners approval rules to protect your code.

코드 소유 책임이 있는 사람이나 그룹을 가리킬 때는 소문자로 code owner 또는 code owners를 사용합니다. 예를 들면 다음과 같습니다.

• Assign a code owner to the project.
• Contact the code owner for a review.

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

파일 이름을 가리킬 때는 대문자로 백틱에 감싼 CODEOWNERS를 사용합니다. 예를 들면 다음과 같습니다.

• Edit the CODEOWNERS file to define the code ownership rules.

Code Review Summary#

Code Review Summary는 title case를 사용합니다.

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

Code Suggestions#

Code Suggestions는 title case를 사용합니다. 페이지에서 처음 언급할 때는 GitLab Duo Code Suggestions를 사용합니다.

기능 이름인 Code Suggestions는 항상 s로 끝나야 합니다. 다만 문장에서는 단수처럼 씁니다. 예를 들면 다음과 같습니다.

• Code Suggestions is turned on for the instance.

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

예:

• Use Code Suggestions to display suggestions as you type. (This phrase describes the feature.)
• As you type, suggestions are displayed. (This phrase is generic.)

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

• code completion
• code generation

collapse#

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

command line#

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

형용사로 쓸 때는 하이픈을 넣습니다. 예: a command-line tool.

compute#

러너가 CI/CD 잡을 실행하는 데 쓰는 리소스에는 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를 사용합니다. 예를 들면 다음과 같습니다.

1. Set up your installation.
2. Configure your installation.

confirmation dialog#

작업 확인을 요청하는 대화 상자를 설명할 때는 confirmation dialog를 사용합니다. 예를 들면 다음과 같습니다.

• In the confirmation dialog, select 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에는 title case를 사용합니다.

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를 사용합니다.

풀어서 씁니다.

• Use: if you are assigned the Developer role
• Instead of: if you are a developer

Developer 권한이 필요한 최소 권한일 때는 다음과 같이 씁니다.

• the Developer, Maintainer, or Owner role

굵게 표시하지 않습니다.

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

dialog#

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

• dialog box
• modal
• modal dialog
• modal window
• pop-up
• pop-up window
• window

confirmation dialog도 참고합니다. 자세한 내용은 Microsoft Style Guide를 참고합니다.

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

대화 상자가 작업이 이루어지는 위치일 때는 전치사 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를 사용합니다.

컨테이너 이름(docker:dind)을 설명할 때는 백틱으로 감싼 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 등 다른 변형은 사용하지 않습니다.

예를 들면 다음과 같습니다.

• From the Visibility dropdown list, select 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을 사용합니다.

예를 들면 다음과 같습니다.

• To edit your profile settings, select Edit.

API 문서와 프로그래밍 방식의 변경에는 **update**를 사용합니다.

editor extensions#

GitLab이 제공하는 확장 프로그램의 넓은 범주를 가리킬 때는 소문자 editor extensions를 사용합니다. 다만 UI의 대문자 표기가 다르면 문서를 UI에 맞춥니다.

개별 확장 프로그램에는 각자의 이름이 있습니다. 예를 들어 GitLab for VS Code와 GitLab Duo Plugin for JetBrains IDEs가 있습니다.

권장 표현:

• Configure GitLab editor extensions in your IDE.
• Code Suggestions is available in the following editor extensions.
• In the left sidebar, select Settings > General, and then expand Editor Extensions.

e.g.#

라틴어 약어를 사용하지 않습니다. 대신 for example, such as, for instance, like를 사용합니다. (Vale 규칙: LatinTerms.yml)

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에는 내용을 입력하는 동작과 그 내용을 확정하는 동작이 모두 포함됩니다.

예를 들면 다음과 같습니다.

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

키보드의 키를 가리키기 위해 Enter를 사용할 때는 HTML <kbd> 태그를 사용합니다.

• To view the list of results, press 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는 다음 이유로 구분할 수 있습니다.

• 대개 내보내기 옵션으로 출력을 바꿀 수 있습니다.
• 내보낸 데이터가 반드시 사용자의 기기로 다운로드되는 것은 아닙니다.

예를 들면 다음과 같습니다.

• 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.

다만 태스크를 작성하면서 모든 필드를 한꺼번에 가리키려는 경우에는 예외로 둘 수 있습니다. 예를 들면 다음과 같습니다.

1. In the top bar, select Search or go to.
2. Select Settings > CI/CD.
3. Expand General pipelines.
4. Complete the fields.

여러 필드를 한꺼번에 문서화하는 방법을 자세히 알아봅니다.

filename#

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

(Vale 규칙: SubstitutionWarning.yml)

filter#

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

필터링은 검색과 다릅니다.

flows#

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

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

flow 이름에는 title case를 사용합니다. 예: Convert to CI/CD Pipeline Flow.

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

flow를 선택하고 session을 시작합니다.

foo#

제품 문서에서는 foo를 사용하지 않습니다. API 문서와 기여자 문서에서는 사용할 수 있지만, 더 명확하고 의미 있는 예시를 쓰도록 합니다.

fork#

fork는 포크 절차를 통해 upstream project에서 만들어진 프로젝트입니다.

upstream project(source project라고도 함)와 fork는 fork relationship을 가지며 서로 linked 상태입니다.

fork relationship을 제거하면 fork는 upstream project와 unlinked 상태가 됩니다.

foundational agent#

Foundational agent는 agent의 한 종류입니다.

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

• 문서에서는 에이전트 이름에 title case를 사용합니다. 예: the Planner Agent.
• UI에서는 title case를 사용하되 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는 title case를 사용합니다.

GitLab#

GitLab을 소유격(GitLab's)으로 쓰지 않습니다. 이 지침은 GitLab 상표 지침을 따릅니다.

GitLab을 다른 제3자 도구나 브랜드의 이름 옆에 두지 않습니다. 예를 들어 다음과 같이 쓰지 않습니다.

• GitLab Chrome extension
• GitLab Kubernetes agent

대신 다음과 같이 씁니다.

• GitLab extension for Chrome
• GitLab agent for Kubernetes

브랜드 이름을 나란히 두면 소유 관계나 파트너십을 암시할 수 있습니다. 법무 검토를 거쳐 파트너십을 홍보하라는 안내를 받은 경우가 아니라면 이는 피해야 합니다.

이 지침은 제3자 상표 사용을 따릅니다.

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를 사용합니다. GitLab이 정부 기관과 FedRAMP 준수가 필요한 조직을 위해 호스팅하고 관리하는 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를 전체 이름과 title case로 씁니다. 다만 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#

cloud-native 버전의 GitLab을 배포할 때는 다음을 사용합니다.

• The GitLab Helm chart (긴 표기)
• The GitLab chart (짧은 표기)

the gitlab chart, the GitLab Chart, the cloud-native chart는 사용하지 않습니다.

Kubernetes 클러스터에 cloud-native GitLab을 배포하려면 GitLab Helm chart를 사용합니다.

다양한 설치 방법을 설명하는 맥락에서 사용할 때는 Helm chart (Kubernetes)를 사용합니다.

GitLab Operator#

GitLab을 설치할 때는 GitLab Operator를 사용합니다.

the Operator나 Operator는 사용하지 않습니다.

다양한 설치 방법을 설명하는 맥락에서 사용할 때는 **GitLab Operator (Kubernetes)**를 사용합니다.

GitLab Orbit#

GitLab Orbit를 사용합니다.

섹션에서 처음 사용한 이후에는 Orbit를 사용할 수 있습니다.

GitLab Orbit Remote#

GitLab Orbit Remote를 사용합니다.

섹션에서 처음 사용한 이후에는 Orbit Remote를 사용할 수 있습니다.

GitLab Orbit Local#

GitLab Orbit Local을 사용합니다.

섹션에서 처음 사용한 이후에는 Orbit Local을 사용할 수 있습니다.

GitLab Orbit CLI#

GitLab Orbit CLI를 사용합니다.

섹션에서 처음 사용한 이후에는 Orbit CLI를 사용할 수 있습니다.

명령을 언급할 때는 설치와 명령 실행 옵션을 모두 다루도록 orbit와 glab orbit cli 버전을 함께 적습니다. GitLab CLI 문서에서는 명령의 glab orbit cli 버전만 문서화합니다.

GitLab Pages#

일관성과 브랜딩을 위해 Pages 대신 GitLab Pages를 사용합니다.

다만 페이지나 UI에서 처음 언급할 때 GitLab Pages를 사용했다면 이후에는 Pages를 사용할 수 있습니다.

GitLab Runner#

GitLab Runner는 title case를 사용합니다. 설치하는 제품입니다. 이 표기를 정한 배경은 이 이슈를 참고합니다.

함께 참고:

• 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를 사용합니다.

풀어서 씁니다.

• Use: if you are assigned the Guest role
• Instead of: if you are a guest

Guest 권한이 필요한 최소 권한일 때는 다음과 같이 씁니다.

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

굵게 표시하지 않습니다.

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

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 words#

가능하면 -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은 title case를 사용합니다.

페이지에서 처음 언급할 때는 GitLab Duo Issue Description Generation을 사용합니다. 이후에는 Issue Description Generation만 단독으로 사용합니다.

Issue Discussion Summary#

Issue Discussion Summary는 title case를 사용합니다.

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

issue weights#

issue weights는 소문자로 씁니다.

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#

build를 job과 같은 뜻으로 사용하지 않습니다. job은 .gitlab-ci.yml 파일에 정의되며 파이프라인의 일부로 실행됩니다.

job이라는 단어에 CI를 붙이려면 CI job 대신 CI/CD job을 사용합니다.

KB, KiB, kilobytes, kibibytes#

KB와 KiB는 Microsoft 지침을 따릅니다.

Kubernetes executor#

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

이 기능을 가리킬 때는 다음을 사용합니다.

• Kubernetes executor for GitLab Runner
• Kubernetes executor

다음은 사용하지 않습니다.

• GitLab Runner Kubernetes executor: Kubernetes 상표를 침해할 수 있기 때문입니다.

language model, large language model#

언어 모델을 가리킬 때는 정확하게 씁니다. 모든 언어 모델이 대규모인 것은 아니며, 모든 모델이 언어 모델인 것도 아닙니다. 확실하지 않으면 개발자나 PM에게 확인을 요청합니다.

처음 사용할 때 풀어 쓴다면 대규모 언어 모델을 가리키는 데 LLM을 사용할 수 있습니다.

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.
• This setting is turned on at the group level.
• This is a project-level setting.

license#

라이선스는 구독과 다릅니다.

• 라이선스는 사용자가 구매한 구독에 대한 액세스를 부여합니다. 라이선스에는 시트 수와 구독 기간 같은 정보가 포함됩니다.
• 구독은 사용자가 구매하는 구독 티어입니다.

권장 표현:

• Add a license to your instance.
• Purchase a subscription.

피할 표현:

• Buy a license.
• Purchase a 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 list가 아니라 Issues 페이지라고 불러야 합니다.

log in, log on#

다음은 사용하지 않습니다.

• log in.
• log on.
• login

대신 sign in을 사용합니다.

다만 사용자 인터페이스에 Log in이 있다면 UI에 맞춥니다.

limited availability#

limited availability는 소문자로 씁니다. 예를 들면 다음과 같습니다.

• This feature has limited availability.
• Hosted runners are in limited availability.

다음은 사용하지 않습니다.

• This feature has reached limited availability.

limited availability의 약어로 LA를 사용하지 않습니다.

logged-in user, logged in user#

logged-in user나 logged in user 대신 authenticated user를 사용합니다.

lower#

버전 번호를 말할 때는 lower를 사용하지 않습니다.

권장 표현:

• In GitLab 14.1 and earlier.

피할 표현:

• In GitLab 14.1 and lower.
• In GitLab 14.1 and older.

machine learning#

machine learning은 소문자로 씁니다.

a machine learning model처럼 machine learning을 형용사로 쓸 때는 하이픈을 넣지 않습니다. 하이픈을 넣는 편이 문법적으로 더 맞을 수 있지만, 더 정확하게 쓰려다 일관성을 잃을 위험이 있습니다.

Maintainer#

Maintainer 권한을 언급할 때는 대문자 M을 사용합니다.

풀어서 씁니다.

• Use: if you are assigned the Maintainer role
• Instead of: if you are a maintainer

Maintainer 권한이 필요한 최소 권한일 때는 다음과 같이 씁니다.

• the Maintainer or Owner role

굵게 표시하지 않습니다.

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

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은 title case를 사용합니다.

페이지에서 처음 언급할 때는 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는 title case를 사용합니다.

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

milestones#

milestones는 소문자로 씁니다.

Minimal Access#

Minimal Access 권한을 언급할 때 지킬 사항은 다음과 같습니다.

• 대문자 M과 대문자 A를 사용합니다.
• 풀어서 씁니다.
  • Use: if you are assigned the Minimal Access role
  • Instead of: if you are a Minimal Access user
• Minimal Access 권한이 필요한 최소 권한일 때:
  • Use: at least the Minimal Access role
  • Instead of: the Minimal Access role or higher

굵게 표시하지 않습니다.

Minimal Access permissions는 사용하지 않습니다. Minimal Access 권한이 할당된 사용자에게는 관련된 권한(permission) 집합이 있습니다.

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 팀이 관리하므로 일반 사용자는 administrator 액세스를 가질 수 없습니다.

예를 들면 다음과 같습니다.

• You can do this thing in a personal namespace or a group namespace.
• You must have the Owner role for the top-level group.

navigate#

navigate는 사용하지 않습니다. 대신 go를 사용합니다. 예를 들면 다음과 같습니다.

• Go to this webpage.
• Open a terminal and go to the runner directory.

(Vale 규칙: 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 규칙: 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 규칙: 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라는 단어는 one time을 뜻합니다. "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를 사용합니다.

풀어서 씁니다.

• Use: if you are assigned the Owner role
• Instead of: if you are an owner

굵게 표시하지 않습니다.

Owner permissions는 사용하지 않습니다. Owner 권한이 할당된 사용자에게는 관련된 권한(permission) 집합이 있습니다. Owner는 administrator를 제외하고 사용자가 가질 수 있는 가장 강력한 권한입니다.

package registry#

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

권장 표현:

• The GitLab package registry supports A, B, and C.
• You can publish a package to your project's package registry.

page#

"On the Issues page,"와 같은 표현을 쓴다면 그 페이지로 이동하는 방법이 가까이에 있도록 합니다. 그렇지 않으면 Issues 페이지가 무엇인지 알 수 없을 수 있습니다.

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

문서는 UI의 대소문자를 따라야 하며 페이지 이름은 굵게 표시합니다. 예를 들면 다음과 같습니다.

• On the Test cases page, ...

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를 사용합니다. 예를 들면 다음과 같습니다.

• The Guest role has fewer permissions than the Developer role.
• To get more permissions, you must have a different role.
• The Owner role has the most permissions.

roles와 permissions를 서로 바꿔 쓰지 않습니다. 각 사용자에게는 하나의 role이 할당됩니다. 각 role에는 permissions 집합이 포함됩니다.

Permissions는 access levels와 같지 않습니다.

personal access token#

personal access token은 sentence case를 사용합니다.

UI를 가리킬 때는 첫 단어를 대문자로 씁니다.

Planner#

Planner 권한을 언급할 때는 대문자 P를 사용합니다.

풀어서 씁니다.

• Use: if you are assigned the Planner role
• Instead of: if you are a planner

Planner 권한이 필요한 최소 권한일 때는 다음과 같이 씁니다.

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

굵게 표시하지 않습니다.

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

please#

제품 문서에서는 please를 사용하지 않습니다.

UI 텍스트에서는 사용자에게 불편을 끼쳤을 때 please를 사용합니다. 자세한 내용은 Microsoft Style Guide를 참고합니다.

preferences#

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

Premium#

구독 티어에는 대문자로 Premium을 사용합니다. 다른 구독 티어와 함께 Premium을 언급할 때는 구독 티어 지침을 따릅니다.

prerequisites#

사용자가 태스크를 완료하기 전에 끝내야 하는 작업이나 충족해야 하는 조건을 문서화할 때는 prerequisites를 사용합니다. requirements는 사용하지 않습니다.

Prerequisites는 목록에 항목이 하나뿐이더라도 항상 복수형이어야 합니다.

자세한 내용은 태스크 주제 유형을 참고합니다.

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

press#

키보드 키를 말할 때는 press를 사용합니다. 예를 들면 다음과 같습니다.

• To stop the command, press Control+C.

primary, secondary#

혼동을 줄이기 위해 명사가 아니라 형용사로 사용합니다. 예를 들면 다음과 같습니다.

• primary database, secondary database
• primary site, secondary site (for Geo)

primary node나 secondary node를 참고합니다.

profanity#

욕설을 사용하지 않습니다. 다른 사용자와 기여자에게 부정적인 영향을 줄 수 있으며, 이는 GitLab의 다양성, 포용성, 소속감 가치에 어긋납니다.

project#

repository, project를 참고합니다.

project access token#

project access token은 sentence case를 사용합니다.

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. (It's recommended.)
• Set the variable. (It's required.)
• You can set the variable. (It's optional.)

권장 단계도 참고합니다.

register#

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

reindex#

검색을 다룰 때는 re-index 대신 reindex를 사용합니다.

remove#

객체가 계속 존재할 때 remove를 사용합니다. 예를 들어 에픽에서 이슈를 제거해도 이슈는 그대로 존재합니다.

객체가 완전히 삭제될 때는 대신 delete를 사용합니다.

Reporter#

Reporter 권한을 언급할 때는 대문자 R을 사용합니다.

풀어서 씁니다.

• Use: if you are assigned the Reporter role
• Instead of: if you are a reporter

Reporter 권한이 필요한 최소 권한일 때는 다음과 같이 씁니다.

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

굵게 표시하지 않습니다.

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

repository, project#

GitLab 프로젝트에는 여러 요소와 함께 Git 리포지터리가 들어 있습니다.

커밋, 브랜치, 태그 같은 Git 데이터와 Git 고유의 작업, 그리고 클론, 페치, 푸시, 풀 같은 동작을 가리킬 때는 repository를 사용합니다.

리포지터리, 위키, 이슈, 포크, 설정 등 여러 기능을 관리하는 GitLab 사용자 인터페이스를 가리킬 때는 project를 사용합니다.

예를 들면 다음과 같습니다.

• Push your changes to the upstream repository.
• Create a fork of the upstream project.
• Rename the default branch in the repository.
• Transfer the project to a different group.

Repository Mirroring#

Repository Mirroring은 title case를 사용합니다.

requirements#

사용자가 단계를 완료하기 전에 끝내야 하는 작업이나 충족해야 하는 조건을 문서화할 때는 다음을 따릅니다.

• 태스크에는 prerequisites를 사용합니다. 자세한 내용은 태스크 주제 유형을 참고합니다.
• 튜토리얼에는 before you begin을 사용합니다. 자세한 내용은 튜토리얼 페이지 유형을 참고합니다.

requirements는 사용하지 않습니다.

reset#

항목을 새 상태로 되돌리는 동작을 설명할 때는 reset을 사용합니다.

resolution, resolve#

문제 해결 방안이 문제를 영구적으로 고칠 때 resolution을 사용합니다. resolution에는 대개 문제를 바로잡기 위한 파일과 코드 변경이 따릅니다. 예를 들면 다음과 같습니다.

• To resolve this issue, edit the .gitlab-ci.yml file.
• One resolution is to edit the .gitlab-ci.yml file.

workaround도 참고합니다.

respectively#

respectively는 피하고 대신 더 정확하게 씁니다.

권장 표현:

• To create a user, select Create user. For an existing user, select Save changes.

피할 표현:

• Select Create user or Save changes if you created a new user or edited an existing one respectively.

restore#

restore에 관한 지침은 Microsoft Style Guide를 참고합니다.

review app#

review app은 소문자로 씁니다.

roles#

사용자는 프로젝트나 그룹에 대한 역할(role)을 가집니다.

권장 표현:

• You must have the Owner role for the group.

피할 표현:

• You must have the Owner role of the group.

사용자가 작업을 수행하는 데 필요한 role을 가리킬 때는 해당하는 모든 role을 최소 권한부터 나열합니다.

• You must have the Developer, Maintainer, or Owner role.

roles와 permissions를 서로 바꿔 쓰지 않습니다. 각 사용자에게는 하나의 role이 할당됩니다. 각 role에는 permissions 집합이 포함됩니다.

role에는 사용자 지정과 기본 두 가지 유형이 있습니다.

Roles는 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 managers는 소문자로 씁니다. 오토스케일링을 위해 여러 러너를 만들 수 있는 러너의 한 유형입니다. GitLab Runner도 참고합니다.

runner worker, runner workers#

runner workers는 소문자로 씁니다. 러너가 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.

예를 들면 다음과 같습니다.

• This rule is more restrictive than the default setting.
• Permissive rules allow broader access.
• When multiple rules match, the most restrictive rule applies.

(s)#

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

권장 표현:

• Select the jobs you want.

피할 표현:

• Select the job(s) you want.

무언가를 여러 개 선택할 수 있다면 그 단어를 복수형으로 씁니다.

sanity check#

sanity check는 사용하지 않습니다. 대신 check for completeness를 사용합니다. (Vale 규칙: InclusiveLanguage.yml)

scalability#

추가 사용자를 위해 GitLab 성능을 높이는 것을 말할 때는 scalability를 사용하지 않습니다. scale이나 scaling이라는 단어는 간혹 쓸 수 있지만, 추가 사용자를 위해 GitLab 성능을 높이는 내용은 독자가 GitLab 참조 아키텍처 페이지를 보도록 안내해야 합니다.

search#

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

검색은 필터링과 다릅니다.

seats#

구독 과금 모델을 가리킬 때는 다음을 따릅니다.

• GitLab.com에서는 seats를 사용합니다. 고객은 시트를 구매합니다. 사용자는 그룹에 초대될 때 시트를 차지하며, 일부 예외가 있습니다.
• GitLab Self-Managed에서는 users를 사용합니다. 고객은 지정된 users 수만큼 구독을 구매합니다.

section#

페이지의 영역을 설명할 때는 section을 사용합니다. 예를 들어 페이지에 UI를 여러 영역으로 나누는 선이 있다면 이 영역을 section이라고 부릅니다.

펼치거나 접을 수 있는 영역을 흔히 sections로 생각합니다. 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 Duo Self-Hosted를 전체 이름과 title case로 씁니다. 다만 GitLab이 아니라 고객이 호스팅하는 언어 모델을 가리키는 경우는 예외입니다.

self-managed#

고객의 GitLab 설치를 가리킬 때는 GitLab Self-Managed를 사용합니다.

• self-hosted는 사용하지 않습니다.

GitLab Self-Managed를 참고합니다.

Service Desk#

Service Desk는 title case를 사용합니다.

session#

에이전트가 flow에서 작업하는 동안에는 session이 실행 중입니다. session은 시작하고 중지할 수 있습니다.

AI session이나 agent session은 사용하지 않습니다.

settings#

setting은 제품의 기본 동작을 변경합니다. 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은 무언가를 처음 한다는 뜻을 담고 있습니다. 예를 들면 다음과 같습니다.

1. Set up your installation.
2. Configure your installation.

ship#

ship은 모호하므로 사용하지 않습니다. 기능을 릴리스한다는 뜻일 때도 있고 구성 요소를 포함한다는 뜻일 때도 있습니다. 다음을 사용합니다.

• 기능이나 버전이 릴리스될 때:
  • release
  • available in
  • 예: This feature is available in 19.2.
• 제품이 구성 요소를 기본으로 포함할 때:
  • include
  • come with
  • provide
  • 예: Siphon does not include its own table list.

다음은 사용하지 않습니다.

• Siphon does not ship its own table list.
• This feature ships in 17.4.

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#

다음 맥락에서 storage를 가리키는 방법은 다음과 같습니다.

• Gitaly에서 storage는 물리적이며 storage라고 불러야 합니다.
• Gitaly Cluster(Praefect)에서 storage는 다음 중 하나입니다.
  • 가상이며 virtual storage라고 불러야 합니다.
  • 물리적이며 physical storage라고 불러야 합니다.

Gitaly storage에는 물리적 경로가 있고 virtual storage에는 가상 경로가 있습니다.

subagents#

sub-agents 대신 subagents(하이픈 없음)를 사용합니다.

subgroup#

sub-group 대신 subgroup(하이픈 없음)을 사용합니다. 또한 child group이나 low-level group 같은 subgroup의 대체 용어는 피합니다.

(Vale 규칙: SubstitutionWarning.yml)

subscription tier#

subscription이나 subscription tier를 **license**와 혼동하지 않습니다. 사용자는 subscription을 구매합니다. 그 subscription에는 tier가 있습니다.

티어를 설명하는 방법은 다음과 같습니다.

Suggested Reviewers#

Suggested Reviewers는 title case를 사용합니다.

Suggested Reviewers는 항상 복수형이어야 하며, 일반적인 의미로 쓰더라도 대문자로 씁니다.

예:

• Suggested Reviewers can recommend a person to review your merge request. (This phrase describes the feature.)
• As you type, Suggested Reviewers are displayed. (This phrase is generic but still uses capital letters.)

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#

이 단어들 뒤에는 항상 명사를 붙입니다. 예를 들면 다음과 같습니다.

• Use: This setting improves performance.
• Instead of: This improves performance.
• Use: These pants are the best.
• Instead of: These are the best.
• Use: That droid is the one you are looking for.
• Instead of: That is the one you are looking for.
• Use: Those settings must be configured. (Or even better, Configure those settings.)
• Instead of: 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을 사용합니다. 예를 들어 검색 상자에서 입력을 시작하면 검색 결과가 나타납니다. 검색 상자 밖을 클릭하지 않습니다.

예를 들면 다음과 같습니다.

• To view all users named Alex, type Al.
• To view all labels for the documentation team, type doc.
• For a list of quick actions, type /.

enter도 참고합니다.

Ultimate#

구독 티어에는 대문자로 Ultimate를 사용합니다. 다른 구독 티어와 함께 Ultimate를 언급할 때는 구독 티어 지침을 따릅니다.

undo#

undo에 관한 지침은 Microsoft Style Guide를 참고합니다.

units of measurement#

숫자와 측정 단위 사이에는 공백을 둡니다. 예: 128 GB. (Vale 규칙: Units.yml)

자세한 내용은 Microsoft Style Guide를 참고합니다.

update#

소프트웨어의 더 새로운 patch 버전을 설치하는 경우나 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의 더 새로운 major(13.0) 또는 minor(13.2) 버전을 설치하는 경우.

예를 들면 다음과 같습니다.

• Upgrade to GitLab Ultimate.
• Upgrade GitLab from 14.0 to 14.1.
• Upgrade GitLab from 14.0 to 15.0.

다른 텍스트 없이 Upgrade GitLab만 쓸 때는 주의합니다. 주변 텍스트가 제품 버전을 말하는지 구독 티어를 말하는지 분명히 밝혀야 합니다.

downgrade와 roll back도 참고합니다.

upper left, upper right#

UI에서 방향을 안내할 때는 upper-left corner와 upper-right corner를 사용합니다. UI 요소가 모서리에 있지 않다면 upper left와 upper right를 사용합니다.

top left와 top right는 사용하지 않습니다.

자세한 내용은 Microsoft Style Guide를 참고합니다.

useful#

useful은 사용하지 않습니다. 사용자가 그 과정이 유용하다고 느끼지 못하면 신뢰를 잃게 됩니다. (Vale 규칙: Simplicity.yml)

user account#

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

using#

대부분의 경우 using은 피합니다. 주어를 감추고 문장을 번역하기 더 어렵게 만듭니다. by using, that use를 사용하거나 문장을 다시 씁니다.

예를 들면 다음과 같습니다.

• Instead of: The files using storage...
• Use: The files that use storage...
• Instead of: Change directories using the command line.
• Use: Change directories by using the command line. Or even better: To change directories, use the command line.

utilize#

utilize는 사용하지 않습니다. 대신 use를 사용합니다. 더 간결하고 영어가 모국어가 아닌 독자가 이해하기 더 쉽습니다. (Vale 규칙: SubstitutionWarning.yml)

version, v#

GitLab의 버전을 설명할 때는 **GitLab <version number>**를 사용합니다. 예를 들면 다음과 같습니다.

• 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의 사용자 인터페이스를 설명할 때는 Command Palette와 Primary Side Bar처럼 VS Code 문서의 용례와 대문자 표기를 따릅니다.

Vulnerability Explanation#

Vulnerability Explanation은 title case를 사용합니다.

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

Vulnerability Resolution#

Vulnerability Resolution은 title case를 사용합니다.

페이지에서 처음 언급할 때는 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 Style Guide를 참고합니다.

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 워크스페이스를 가리킬 때만 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. (In content for an administrator)

피할 표현:

• 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.