권장 단어 목록

기술 문서 작성팀이 일관성을 유지하기 위해 다음과 같은 단어를 권장합니다. 더불어:

이 페이지에 없는 지침은 다음 스타일 가이드를 참조하세요:

.gitlab-ci.yml 파일

.gitlab-ci.yml 파일을 위해 백틱과 소문자를 사용하세요.

가능한 경우, 전체 구문인 .gitlab-ci.yml 파일을 사용하세요.

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

& (ampersand)

라틴 약어를 사용하지 마세요. 문서화 중인 UI 요소가 &를 사용하는 경우를 제외하고 and를 대신 사용하세요.

@mention

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

위

문서 페이지에서 예제나 테이블을 참조할 때 위를 사용하는 것을 피하세요. 필요한 경우 previous를 대신 사용하세요. 예:

  • 이전 예시에서 강아지에는 벼룩이 있었습니다.

제품의 버전을 참조할 때 위를 사용하지 마세요. 대신 later를 사용하세요.

아래처럼 사용하세요:

  • GitLab 14.4 이상에서…

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

  • GitLab 14.4 및 이상…
  • GitLab 14.4 및 높음…
  • GitLab 14.4 및 더 높음…

액세스 레벨

액세스 레벨은 역할이나 권한과 다릅니다. 사용자를 생성할 때 액세스 레벨인 Regular, Auditor, 또는 Administrator를 선택하세요.

UI를 참조할 때에는 이러한 단어들을 대문자로 쓰고, 그 외에는 소문자를 사용하세요.

추가

객체가 이미 있는 경우 add를 사용하세요. 객체가 아직 존재하지 않는 경우 create를 대신 사용하세요. Add은 remove의 반대입니다.

예시:

  • 사용자를 목록에 추가하세요.
  • 이슈를 에픽에 추가하세요.

Add을 create와 혼동하지 마세요.

Add new를 사용하지 마세요.

관리자 영역

다음을 사용하세요:

  • UI의 해당 영역을 설명하는 Admin 영역.
  • UI 버튼을 위한 Admin.

다음을 사용하지 마세요:

  • 두 단어를 모두 볼드체로 하는 Admin area
  • Admin Area (Area를 대문자로)
  • Admin Area (Area를 대문자로)
  • administrator area
  • 또는 기타 다른 변형

관리자 모드

Admin Mode에 대해 제목 케이스를 사용하세요. UI에서 제목 케이스를 사용합니다.

관리자

사용자의 액세스 레벨을 언급할 때 admin 대신 administrator access를 사용하세요.

admin access level

다음을 사용하세요:

  • 이 작업을 하려면 관리자여야 합니다.
  • 이 작업을 하려면 관리자 액세스 권한이 있어야 합니다.

다음을 사용하지 말아주세요:

  • 이 작업을 하려면 관리자 역할이 있어야 합니다.

고급 검색

전체 GitLab 인스턴스 전반에 걸쳐 빠르고 효율적인 검색을 참조할 때 advanced search에 소문자를 사용하세요.

에이전트

Kubernetes용 GitLab 에이전트를 참조할 때 소문자를 사용하세요. 예:

  • 귀하의 클러스터를 GitLab에 연결하려면 GitLab 에이전트를 사용하세요.
  • 클러스터에 에이전트를 설치하세요.
  • 목록에서 에이전트를 선택하세요.

GitLab 에이전트 또는 Kubernetes용 GitLab 에이전트에 대해 제목 케이스를 사용하지 마세요.

에이전트 액세스 토큰

Kubernetes용 에이전트를 생성할 때 생성된 토큰을 의미합니다. agent access token을 사용하고 다음을 사용하지 마세요:

  • registration token
  • secret token
  • authentication token

객관적인

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

AI, 인공지능

AI를 사용하세요. artificial intelligence을 전체로 쓰지 마세요.

AI 영향 대시보드

AI Impact Dashboard에 제목 케이스를 사용하세요.

페이지에서 처음 언급할 때는 GitLab Duo AI Impact Dashboard를 사용하세요. 그 이후에는 AI Impact Dashboard를 사용하세요.

인공지능 기반 DevSecOps 플랫폼

GitLab 이전에 사용되는 경우 Platform를 대문자로 써야 합니다. 예를 들어, GitLab 인공지능 기반 DevSecOps Platform.

에어갭, 에어갭

물리적 장벽이나 인터넷 액세스를 방지하거나 제한하는 보안 정책이 있는 설치에 대해 offline environment을 사용하세요. 에어갭, 에어갭, 또는 에어갭을 사용하지 마세요. 예시:

  • 오프라인 환경의 방화벽 정책은 컴퓨터가 인터넷에 액세스하는 것을 방지합니다.

허용, 활성화

허용 및 활성화를 사용하지 마세요. 보안 관련 기능에 대해 이야기하는 경우를 제외하고 사용을 피하세요.

사용하세요:

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

다음을 사용하지 마세요:

  • 이 기능을 사용하여 리포지토리에 파일을 추가할 수 있습니다.
  • 사용자가 리포지토리에 파일을 추가할 수 있도록 하는 이 기능.

이 표현은 보다 더 활동적이며 기능을 구현한 사람이 아닌 사용자의 관점에서 나온 것입니다. 더 많은 정보는 Microsoft 스타일 가이드를 참조하세요.

분석

Analytics 및 contribution analytics 및 issue analytics와 같은 변형에는 소문자를 사용합니다. 그러나 UI에서 대문자 사용이 다르면 문서도 UI와 일치하도록합니다.

예:

  • 프로젝트에서 병합 요청 분석을 볼 수 있습니다. 이것들은 병합 요청 분석 대시 보드에 표시됩니다.

선조

상속 계층구조에서 한 수준 이상 위의 상위 항목을 가리키는 경우, ancestor를 사용합니다.

할아버지를 사용하지 마십시오.

예:

  • 선조 그룹, 프로젝트 계층구조의 그룹
  • 조상 이픽, 이슈 계층구조의 이픽
  • 그룹과 모든 선조

또한 child, descendant 및 subgroup를 참조하십시오.

and/or

and/or 대신 or를 사용하거나 두 옵션을 명확히 설명하는 문장으로 재 작성하십시오.

등

등(and so on**을 사용하지 않습니다. 더 구체적으로 설명하십시오. 자세한 정보는 Microsoft Style Guide를 참조하십시오.

영역

영역 대신 section을 사용하십니다. Admin 영역은 유일한 예외입니다.

as

as가 because를 의미하는 데 사용되지 않습니다.

사용하기:

  • 단말기 중 어느 것도 ID를 반환하지 않기 때문에…

대신에:

  • 어떤 단말기도 ID를 반환하지 않기 때문에…

as well as

as well as 대신 and를 사용하십시오.

associate

이슈를 에픽에 추가하거나, 사용자를 이슈, 병합 요청 또는 이픽에 추가하는 경우 associate를 사용하지 마십시오.

대신 assign을 사용하십시오. 예:

  • 이슈를 에픽에 할당합니다.
  • 사용자를 이슈에 할당합니다.

인증 된 사용자

다른 변형인 signed in user 또는 logged in user 대신 authenticated user를 사용합니다.

시작하기 전에

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

더 많은 정보는 튜토리얼 페이지 유형을 참조하십시오.

작업 유형의 경우 prerequisites을 사용하십시오.

아래

문서 페이지에서 예제 또는 표를 참조할 때 아래를 피하려고 하십니다. 필요한 경우 following을 사용하십시오. 예를 들어:

  • 다음 예에서 강아지는 벼룩이 있습니다.

beta

베타(beta)를 사용합니다. 예:

  • 이 기능은 베타 상태입니다.
  • 이것은 베타 기능입니다.
  • 이 베타 릴리스는 테스트 준비가 되었습니다.

베타 기능에 대해 작성할 때 이 주제에 링크하려 할 수 있습니다.

denylist

blacklist를 사용하지 마십시오. 다른 옵션은 denylist입니다.(Vale 규칙: InclusiveLanguage.yml)

board

boards, issue boards, 및 epic boards를 작은 문자로 사용하십시오.

box

UI 필드를 참조할 때 text box를 사용하십시오. field 또는 box를 사용하지 마십시오. 예:

  • Variable name 텍스트 상자에 값을 입력하십시오.

branch

브랜치를 설명할 때 branch를 사용하십시오. 특정 브랜치에 대해서는 다음 용어만 사용하십시오:

  • default branch: 저장소의 기본 브랜치입니다. 사용자는 UI를 사용하여 기본 브랜치를 설정할 수 있습니다. 기본 브랜치를 사용하는 예에서는 master 대신 main을 사용하십니다.
  • source branch: 합병하는 브랜치
  • target branch: 병합하는 브랜치
  • current branch: 현재 선택한 브랜치 이 브랜치는 기본 브랜치, 작성한 브랜치, 소스 브랜치 또는 기타 어떤 브랜치라도 될 수 있습니다.

feature branch 또는 merge request branch를 사용하지 마십시오. 가능한 한 구체적으로 설명하십시오. 예를 들어:

  • 선택한 브랜치…
  • 커밋을 추가한 브랜치…

bullet

정렬된 목록이나 정렬되지 않은 목록의 개별 항목을 bullets로 지칭하지 마십시오. 대신 list item를 사용하십시오. 좀 더 모호하지 않도록 하려면 다음과 같이 사용할 수 있습니다:

  • 정렬된 목록 항목에 대해서는 Ordered list item
  • 정렬되지 않은 목록 항목에 대해서는 Unordered list item

button

button에 설명과 함께 기술하지 마십시오.

사용:

  • Run pipelines을 선택하십시오.

대신에:

  • Run pipelines 버튼을 선택하십시오.

cannot, can not

can not 대신에 cannot를 사용하십시오.

축약에 대해서는 contractions를 참조하십시오.

Chat, GitLab Duo Chat

Chat는 대문자 c로 Chat 또는 GitLab Duo Chat에 사용합니다.

페이지에서 첫 사용시에는 GitLab Duo Chat을 사용하십시오. 그 후로는 Chat만 사용하십시오.

checkbox

checkbox에 대해 한 단어를 사용하십시오. check box를 사용하지 마십시오.

체크박스를 select (선택)하고 clear (해제)하십시오. 예를 들어:

  • Protect environment 체크 상자를 선택하십시오.
  • Protect environment 체크 상자를 해제하십시오.

체크 상자를 선택했거나, 필경 상자가 해제되었음을 나타낼 수 있습니다. 예를 들어:

  • Protect environment 체크 상자가 해제되었는지 확인하십시오.
  • Protect environment 체크 상자가 선택되어 있는지 확인하십시오.

(Vale 규칙: SubstitutionWarning.yml)

checkout, check out

체크아웃은 동사로 사용하십시오. Git 명령어의 경우 checkout를 사용하십시오.

  • 지역에서 브랜치를 확인하려면 git checkout를 사용하십시오.
  • 편집하려는 파일을 확인하십시오.

CI, CD

GitLab 기능에 대한 언급에서는 CI/CD를 사용하십시오. CI 또는 CD만 사용하지 마십시오.

CI/CD

CI/CD는 항상 대문자입니다. 처음에 사용할 때 철자를 분리할 필요는 없습니다.

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

  • 코드를 CI/CD 파이프라인에서 테스트하십시오. Pipeline을 MR(merge request)용으로 구성하십시오.
  • 값을 CI/CD 변수에 저장하십시오. Variable을 마스킹으로 설정하십시오.

CI/CD minutes

CI/CD minutes라는 용어를 사용하지 마십시오. 이 용어는 compute minutes(계산 분)로 변경되었습니다.

child

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

예시:

  • child issue
  • child epic
  • child objective
  • child key result
  • child pipeline

참고: descendant(하위), parent(상위) 및 subgroup(하위 그룹)도 참조하세요.

click

click을 사용하지 마세요. 대신 버튼, 링크, 메뉴 항목 및 목록을 선택할 때 select를 사용하세요. Select은 더 많은 장치에 적용되지만 click은 마우스에 더 구체적으로 적용됩니다.

right-click 및 click-through demo에는 예외를 사용할 수 있습니다.

cloud licensing

cloud licensing이라는 구문을 사용하지 마세요. 대신, 이 구독이 GitLab과 동기화된다는 사실에 중점을 두세요.

예시:

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

cloud native

GitLab을 호스팅하기 위해 Kubernetes 클러스터를 사용하는 경우, 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의 경우, 타이틀 케이스를 사용하세요.

페이지에서 처음 언급할 때 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 Review Summary

Code Review Summary의 경우, 타이틀 케이스를 사용하세요.

페이지에서 처음 언급할 때 GitLab Duo Code Review Summary를 사용하세요. 그 후로는 Code Review Summary을 그 자체로 사용하세요.

Code Suggestions

Code Suggestions 에는 타이틀 케이스를 사용하세요. 페이지에서 처음 언급할 때 GitLab Duo Code Suggestions를 사용하세요.

이 기능의 경우, 항상 s로 끝나야 합니다. 그러나 그것을 그대로 사용하고 있지만 명칭은 단수로 씁니다.

예시:

  • Code Suggestions는 인스턴스에서 활성화되어 있습니다.

이 기능이 출력하는 제안을 일반적으로 참조할 때는 소문자를 사용하세요.

예시:

  • 타이핑 하는 동안 제안이 표시됩니다.

Code Suggestions에는 두 가지 주요 기능이 포함되어 있는데, code completion(코드 완성)과 code generation(코드 생성)입니다.

collapse

UI에서 섹션을 확장하거나 축소하는 경우 close 대신 collapse를 사용하세요.

command line

명령어를 소개할 때 From the command line을 사용하세요. 형용사로 사용할 때는 하이픈을 사용하세요. 예를 들어, command-line tool.

compute

CI/CD 작업을 실행하는 러너가 사용하는 리소스에는 compute를 사용하세요.

관련 용어:

  • compute minutes(계산 분): 사용된 compute의 계산 방식. 예시: 400 compute minutes.
  • compute quota(계산 할당량): 네임스페이스가 매달 사용할 수 있는 compute 분의 한도.
  • compute usage: 네임스페이스가 월간 할당량에서 사용한 compute 분의 수.

compute minutes

다음과 같은 용어 대신 compute minutes를 사용하세요:

  • CI/CD minutes
  • CI minutes
  • pipeline minutes
  • CI pipeline minutes
  • pipeline minutes

자세한 정보는 2150번 epic을 참조하세요.

configuration

일련의 설정을 업데이트할 때는 configuration를 호출하세요.

configure

기능이나 제품을 set up 한 후에 configure를 사용하세요. 예를 들어:

  1. 설치를 설정하세요.
  2. 설치를 구성하세요.

confirmation dialog

확인 작업을 요청하는 대화 상자를 나타낼 때 confirmation dialog를 사용하세요. 예를 들어:

  • 확인 대화 상자에서 OK를 선택하세요.

confirmation box 또는 confirmation dialog box를 사용하지 마세요. 또한 dialog(대화 상자)를 참조하세요.

container registry

GitLab 컨테이너 레지스트리의 기능과 기능을 문서화할 때는 소문자를 사용하세요.

사용 예:

  • GitLab 컨테이너 레지스트리는 A, B, 및 C를 지원합니다.
  • 프로젝트의 컨테이너 레지스트리에 Docker 이미지를 푸시할 수 있습니다.

create

객체가 존재하지 않고 처음 만드는 경우 create를 사용하세요. Create은 delete(삭제)의 반대입니다.

예를 들어:

  • 이슈를 만드세요.

add와 create를 혼동하지 마세요.

create new를 사용하지 마세요. create라는 단어는 객체가 새로운 것임을 시사하며, 추가 단어는 필요하지 않습니다.

currently

제품 또는 해당 기능에 대해 currently를 사용하지 마세요. 문서는 제품을 현재 상태 그대로 설명합니다. (Vale rule: CurrentStatus.yml)

custom role

특정 사용자 지정 권한으로 생성된 권한을 지칭할 때 custom role을 사용하세요.

사용자 지정이 아닌 권한을 지칭할 때는 default role(기본 역할)을 사용하세요.

data

data를 단수로 사용하세요.

사용 예:

  • 데이터는 수집됩니다.
  • 데이터는 성능 향상을 보여줍니다.

다음과 같은 것들 보다 아래와 같이 사용합니다.

  • 수집된 data가 아닌 data를 사용하세요.
  • 성능 향상을 보여주는 data가 아닌 data를 사용하세요.

default role

다음과 같은 사용자 지정된 특정 권한이 없는 미리 정의된 권한을 지칭할 때 default role을 사용하세요:

  • Guest
  • Reporter
  • Developer
  • Maintainer
  • Owner
  • Minimal Access

static role, built-in role, 또는 predefined role을 사용하지 마세요.

삭제

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

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

Dependency Proxy

GitLab Dependency Proxy에는 제목 케이스를 사용하세요.

배포 보드

배포 보드는 소문자로 사용하세요.

descendant

계층 구조에서 하나 이상의 수준 하위에 있는 자식 항목을 지칭하는 경우 descendant를 사용하세요.

grandchild를 사용하지 마세요.

예시:

  • descendant 프로젝트, 그룹 계층 구조에서의 프로젝트.
  • descendant 이슈, epic 계층 구조에서의 이슈.
  • 그룹과 모든 descendant.

참고: ancestor, child, subgroup도 참조하세요.

Developer

Developer 역할을 다룰 때:

  • 대문자 D를 사용하세요.
  • 굵은 글씨를 사용하지 마세요.
  • 개발자 역할에 할당된 사람을 의미하는 구문으로 if you are a developer 대신 if you are assigned the Developer role과 같이 쓰세요.
  • Developer 역할이 최소 요구되는 상황을 설명할 때:
    • 사용: 적어도 Developer 역할
    • 대신: Developer 역할 또는 그 이상

Developer permissions를 사용하지 마세요. Developer 역할이 할당된 사용자에게는 연관된 권한 집합이 있습니다.

DevSecOps 플랫폼

GitLab 이전에 사용되는 경우 Platform을 대문자로 사용하세요. 예: GitLab DevSecOps Platform.

대화상자

대화상자(dialog)를 사용하세요.

  • 대화상자 상자
  • 모달(modal)
  • 모달 대화상자(modal dialog)
  • 모달 창(modal window)
  • 팝업(pop-up)
  • 팝업 창(pop-up window)
  • 창(window)

등의 다른 용어보다 대화상자를 사용하세요. 자세한 내용은 Microsoft Style Guide를 참조하세요.

대화상자가 작업을 수행하는 위치인 경우 전치사로 on을 사용하세요. 예를 들어:

  • 권한 부여(Grant permission) 대화상자에서 그룹(Group)을 선택하세요.

대화상자(dialog) 또는 서랍 중 올바른 용어를 확인하세요.

비활성화

설정 또는 기능을 사용할 수 없게 하는 것을 설명하는 데 비활성화를 사용하지 마세요. 끄기, 숨기기, 사용할 수 없게 하기, 제거하기와 같은 대안을 사용하세요.

상태를 설명하는 데 off, inactive, unavailable을 사용하세요.

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

허용하지 않음

허용하지 않음 대신 방지를 사용하세요. (Vale 규칙: Substitutions.yml)

토론 요약

토론 요약의 경우 타이틀 케이스를 사용하세요.

페이지의 첫 언급에서는 GitLab Duo Discussion Summary를 사용하세요. 이후로는 Discussion Summary만 사용하세요.

Docker-in-Docker, dind

Docker executor를 사용하여 Docker 컨테이너를 실행하는 경우 Docker-in-Docker를 사용하세요.

컨테이너 이름을 나타낼 때는 역따옴표() 안에 dind`를 사용하세요. 그렇지 않으면 정확히 써주세요.

다운그레이드

더 긍정적이고 정확한 표현을 위해 다운그레이드 대신 행동에 집중하세요.

  • 이전 GitLab 버전으로 변경하는 경우 roll back을 사용하세요.
  • 낮은 GitLab 등급으로 변경하는 경우 구독 등급 변경을 사용하세요.

다운로드

사용자의 기기에 데이터를 저장하는 것을 설명할 때 다운로드를 사용하세요. 자세한 내용은 Microsoft style guide를 참조하세요.

내보내기와 혼동하지 마세요.

서랍

오른쪽 화면에 나타나며 사용자가 현재 페이지를 떠나지 않고도 특정 컨텍스트별 정보나 조치를 표시하는 서랍 UI 구성 요소를 설명할 때 서랍을 사용하세요.

서랍의 예시를 보려면:

이 용어를 사용하기 전에 사용 사례에 따라 서랍 또는 대화상자인지 확인하세요.

드롭다운 목록

UI 요소를 설명할 때 드롭다운 목록을 사용하세요. list 없이 드롭다운을 사용하지 마세요. 하이픈(-)으로 붙인 드롭-다운(hyphenated), 드롭다운 메뉴 또는 다른 변형을 사용하지 마세요.

예시:

  • 가시성(Visibility) 드롭다운 목록에서 공개(Public)를 선택하세요.

이전

버전 번호에 대해 이전을 사용하세요.

다음을 사용하세요:

  • GitLab 14.1 및 이전.

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

  • GitLab 14.1 및 낮음.
  • GitLab 14.1 및 옛.

쉽게

쉽게를 사용하지 마세요. 사용자가 프로세스를 쉽게 생각하지 않는다면 그들의 신뢰를 잃게 됩니다.

예

라틴 약어를 사용하지 마세요. 예를 들어, -와 같은, 예와 같이와 같은 표현을 사용하세요. (Vale 규칙: LatinTerms.yml)

줄임표

UI 텍스트 문서화 시, UI에 줄임표가 포함되어 있으면 문서에는 줄임표를 포함하지 마세요. 자세한 내용은 Microsoft Style Guide를 참조하세요.

사용:

  • 새로 생성

다음을 사용하지 마세요:

  • 새로 생성…

이메일

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

이메일 주소

이메일 주소를 참조할 때는 메시지가 아닌 이메일 주소를 가리킴으로, 이메일로 줄이지 마십시오.

이모지

복수형 이모지를 가리키기 위해서 이모지를 사용하십시오.

enable

설정 또는 기능을 사용 가능하게 하는 것을 나타낼 때 enable 대신 turn on을 사용하십시오.

상태를 설명할 때에는 on 또는 active를 사용하십시오.

이 가이드라인은 Microsoft 스타일 가이드에 기반합니다.

enter

대부분의 경우 enter 대신 type을 사용하십시오.

  • Enter은 음성 및 키보드를 포함한 여러 방법으로 정보를 입력하는 것을 포함합니다.
  • 사용자가 값이 한 필드에 입력하고 커서를 필드 바깥으로 이동(또는 Enter를 누르는)한다는 것을 Enter으로 간주합니다. Enter은 콘텐츠를 입력하고 콘텐츠를 확인하는 작업을 모두 포함합니다.

예시:

  • Variable name 텍스트 상자에 값을 입력하십시오.
  • Variable name 텍스트 상자에 my text를 입력하십시오.

키보드의 키를 가리키기 위해 Enter를 사용할 때 HTML <kbd> 태그를 사용하십시오:

  • 결과 목록을 보려면 Enter를 누르십시오.

type도 참조하십시오.

epic

epic에는 소문자를 사용하십시오.

associate도 참조하십시오.

epic board

epic board에는 소문자를 사용하십시오.

등등

등등은 가능한 피하십시오. 최대한 구체적으로 작성하십시오. 대체로 and so on를 대체로 사용하지 마십시오.

사용:

  • 병합 요청 및 이슈와 같은 객체를 업데이트할 수 있습니다.

다음과 같이 사용하지 마십시오:

  • 병합 요청, 이슈 등을 업데이트할 수 있습니다.

expand

UI에서 섹션을 확장하거나 축소하는 경우 open 대신 expand를 사용하십시오.

experiment

experiment에는 소문자를 사용하십시오. 예시:

  • 이 기능은 실험입니다.
  • 이러한 기능들은 실험입니다.
  • 이 실험은 테스트할 준비가 되었습니다.

필요하다면 experimental을 사용할 수 있습니다.

실험적인 기능에 대해 작성할 때 이 주제에 링크를 추가할 수 있습니다.

export

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

export는 download와 구분할 수 있습니다.

  • 종종, 출력을 변경하기 위해 export 옵션을 사용할 수 있습니다.
  • 내보낸 데이터가 사용자 장치에 반드시 다운로드되는 것은 아닙니다.

예시:

  • 보고서 내용을 CSV 형식으로 내보내기.

download와 혼동하지 마십시오.

FAQ

사용자가 정보를 빠르게 찾을 수 있도록 하고, FAQ라는 용어를 거의 검색하지 않습니다. FAQ에 있는 정보는 다른 유사한 정보와 함께 쉽게 검색 가능한 주제 제목 아래에 포함됩니다.

기능

기능이라는 단어를 거의 사용할 필요가 없습니다. 대신 GitLab이 무엇을 하는 지 설명하십시오.

예시로 다음을 사용하십시오:

  • 병합 요청을 사용하여 변경 사항을 대상 브랜치에 통합하십시오.

다음과 같이 사용하지 마십시오:

  • 변경 사항을 대상 브랜치에 통합하는 병합 요청 기능을 사용하십시오.

feature branch

기능 브랜치를 사용하지 마십시오. branch를 참조하십시오.

field

필드 또는 상자 대신 text box를 사용하십시오.

사용:

  • Variable name 텍스트 상자에 값을 입력하십시오.

다음과 같이 사용하지 마십시오:

  • Variable name 필드에 my text를 입력하십시오.

그러나 작업을 작성하고 한꺼번에 모든 필드를 참조해야 할 때는 예외를 만들 수 있습니다. 예를 들어:

  1. 좌측 사이드 바에서 검색 또는 이동을 선택하고 프로젝트를 찾으십시오.
  2. 설정 > CI/CD를 선택하십시오.
  3. 일반 파이프라인을 확장하십시오.
  4. 필드를 작성하십시오.

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

filename

filename에 대해 하나의 단어를 사용하십시오. 변수로 filename을 사용하는 경우 <filename>을 사용하십시오.

(Vale 규칙: SubstitutionWarning.yml)

filter

이슈나 병합 요청과 같은 항목 목록을 보는 경우, 가능한 속성으로 목록을 필터링할 수 있습니다. 예를 들어, 담당자 또는 검토자로 필터링할 수 있습니다.

필터링은 searching과 다릅니다.

foo

제품 문서에서 foo를 사용하지 마십시오. API 및 기여자 문서에서 사용할 수 있지만 더 명확하고 의미 있는 예를 대신 사용하십시오.

fork

fork는 forking process를 사용하여 upstream project로부터 생성된 프로젝트입니다.

upstream project(또는 source project)와 fork에는 fork 관계가 있으며 linked입니다.

fork 관계가 제거되면 fork는 upstream project로부터 unlinked됩니다.

전체 화면

전체 화면은 두 개의 단어를 사용하십시오. (Vale 규칙: SubstitutionWarning.yml)

미래 시제

가능하다면 미래 시제 대신 현재 시제를 사용하십시오. 예를 들어, 명령을 실행한 후 GitLab이 결과를 표시합니다 대신 명령을 실행한 후 GitLab이 결과를 표시할 것입니다를 사용하십시오. (Vale 규칙: FutureTense.yml)

GB, gigabytes

GB 및 MB에 대해서는 Microsoft 가이드를 따르십시오.

Geo

Geo에는 제목 케이스를 사용하십시오.

generally available, general availability

generally available 및 general availability에는 소문자를 사용하십시오.

예를 들어:

  • 이 기능은 대개 이용 가능합니다.

general availability에 도달했다는 표현을 자주 사용하지 마십시오.

  • 이 기능은 일반적으로 사용 가능합니다.

GA을 사용하여 general availability를 나타낼 수 있으며 첫 번째 사용 시 전체 글자로 쓸 수 있습니다.

GitLab

GitLab을 소유격으로 바꾸지 마십시오. 이 가이드는 GitLab 상표 가이드라인을 따릅니다.

다른 제3자 도구나 브랜드 이름 옆에 GitLab을 두지 마십시오. 예시: - GitLab Chrome extension - GitLab Kubernetes agent

대신 다음을 사용하십시오: - Chrome용 GitLab 확장 프로그램 - Kubernetes용 GitLab 에이전트

브랜드 이름을 서로 옆에 두면 소유권이나 협력을 의미할 수 있으므로, 법적 검토를 거치지 않은 이상 협력을 홍보하지 않아야 합니다. 이 가이드는 제3자 상표 사용을 따릅니다.

GitLab Dedicated

제품 오퍼링을 지칭할 때 GitLab Dedicated를 사용하십시오. 이것은 GitLab이 고객을 위해 호스팅하고 관리하는 GitLab 인스턴스를 가리킵니다.

GitLab Dedicated은 단일 테넌트 SaaS 서비스로 언급할 수 있습니다.

Dedicated를 단독으로 사용하지 마십시오. 항상 GitLab Dedicated를 사용하십시오.

GitLab Duo

Duo를 단독으로 사용하지 마십시오. 항상 GitLab Duo를 사용하십시오.

페이지에서 처음 사용할 때 GitLab Duo <기능이름>을 사용하십시오. 2024년 8월 기준, 다음은 GitLab Duo 기능의 이름입니다:

  • GitLab Duo AI Impact Dashboard
  • GitLab Duo Chat
  • GitLab Duo Code Explanation
  • GitLab Duo Code Review Summary
  • GitLab Duo Code Suggestions
  • GitLab Duo for the CLI
  • GitLab Duo Issue Description Generation
  • GitLab Duo Issue Discussion Summary
  • GitLab Duo Merge Commit Message Generation
  • GitLab Duo Merge Request Summary
  • GitLab Duo Product Analytics
  • GitLab Duo Root Cause Analysis
  • GitLab Duo Self-Hosted Models
  • GitLab Duo Test Generation
  • GitLab Duo Vulnerability Explanation
  • GitLab Duo Vulnerability Resolution

첫 번째 사용 이후에는 GitLab Duo 없이 기능 이름을 사용하십시오.

GitLab Duo Enterprise

부가 기능을 위해 항상 GitLab Duo Enterprise를 사용하십시오. 법적으로 승인되지 않은 경우 Duo Enterprise를 사용하지 마십시오.

대문자로 쓰여진 GitLab Duo Enterprise 부가 기능을 사용할 수 있지만 가능하면 부가 기능을 사용하지 않도록 하십시오.

GitLab Duo Pro

부가 기능을 위해 항상 GitLab Duo Pro를 사용하십시오. 법적으로 승인되지 않은 경우 Duo Pro를 사용하지 마십시오.

대문자로 쓰여진 GitLab Duo Pro 부가 기능을 사용할 수 있지만 가능하면 부가 기능을 사용하지 않도록 하십시오.

GitLab Duo Workflow

GitLab Duo Workflow를 사용하십시오. 처음 사용 이후에는 Duo Workflow를 사용하십시오.

Workflow를 단독으로 사용하지 마십시오.

GitLab Flavored Markdown

가능한 경우, GitLab Flavored Markdown을 전체로 써주십시오.

약어를 사용해야 할 경우 GFM을 사용하지 마십시오. 대신 GLFM을 사용하십시오.

GitLab Helm 차트, GitLab 차트

클라우드 네이티브 버전의 GitLab을 배포하기 위해 다음을 사용하십시오:

  • GitLab Helm 차트 (긴 버전)
  • GitLab 차트 (짧은 버전)

gitlab 차트, GitLab Chart, 또는 클라우드 네이티브 차트를 사용하지 마십시오.

GitLab Helm 차트를 사용하여 Kubernetes 클러스터에 클라우드 네이티브 GitLab을 배포합니다.

이를 다른 설치 방법 설명 문맥에서 사용하는 경우, Helm 차트 (Kubernetes)를 사용하십시오.

GitLab Pages

일관성과 브랜딩을 위해 GitLab Pages 대신 Pages를 사용하십시오.

그러나 페이지나 UI에서 첫 번째 언급에 대해선 이후에 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 Self-Managed를 사용하십시오. 이것은 고객 본인이 관리하는 GitLab 인스턴스를 가리킵니다.

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를 사용할 수도 있습니다.

그룹 접근 토큰

그룹 접근 토큰을 문장 케이스로 사용하십시오.

UI를 가리킬 때 첫 번째 단어를 대문자로 써주십시오.

가이드

우리는 사용자들에게 직접적으로 말하길 원합니다. docs.gitlab.com에서는 페이지 제목에서 가이드를 사용하지 마십시오. 예제: Snowplow Guide. 대신, 기능 자체에 대해 이야기하고 해당 기능을 사용하는 방법에 대해 설명하십시오. 예제: Snowplow를 사용하여 xyz 수행하기.

Guest

Guest 역할에 관한 글을 작성할 때:

  • G를 대문자로 사용하십시오.
  • 전체로 써주십시오:
    • 사용: Guest 역할을 할당받은 경우
    • 대신: 게스트인 경우
  • 최소 필요한 역할이 Guest일 때:
    • 사용: 적어도 Guest 역할
    • 대신: Guest 역할 또는 더 높은 역할

굵게 표시하지 마십시오.

게스트 권한을 사용하지 마십시오. Guest 역할을 받은 사용자는 관련 권한 세트를 가지고 있습니다.

편리함

편리함을 사용하지 마십시오. 사용자가 기능 또는 프로세스를 편리하게 여기지 않으면, 그들의 신뢰를 잃을 것입니다. (Vale 규칙: Simplicity.yml)

고가용성, HA

고가용성 또는 HA를 사용하지 마십시오. 단, GitLab 참조 아키텍처에서는 해당 용어를 사용하세요. 대신 더 많은 사용자를 처리하도록 GitLab을 구성하는 자세한 내용은 참조 아키텍처를 참고하세요.

고가용성 설정이라는 표현을 여러 노드 환경을 의미하는 것으로 사용하지 마십시오. 대신 다중 노드 설정 등을 사용하세요.

높은

버전 번호에 대해 이야기할 때 높은을 사용하지 마십시오.

사용:

  • GitLab 14.4 이상인 경우…

대신:

  • GitLab 14.4 이상인 경우…
  • GitLab 14.4 이상에서…
  • GitLab 14.4 이상 버전에서…

눌러

눌러를 누르다로 이해하는 데 사용하지 마십시오.

사용:

  • ENTER를 누르세요.

대신:

  • ENTER 버튼을 누릅니다.

나

1인칭 단수를 사용하지 마십시오. 대신 you를 사용하거나 문구를 다시 작성하세요.

즉

라틴어 약어를 사용하지 마십시오. 대신 that is을 사용하세요. (Vale 규칙: LatinTerms.yml)

~하기 위해서

~하기 위해서를 사용하지 마십시오. 대신 ** ~하기 위해**를 사용하세요. (Vale 규칙: Wordy.yml)

index, indices

index의 복수형으로 indexes를 사용하세요.

그러나 Elasticsearch의 경우, indices를 사용합니다.

소스로부터 설치

자체 컴파일된 코드를 사용하여 설치하는 방법을 참조할 때 자체 컴파일이라고 지칭하십시오.

다음을 사용하세요:

  • 자체 컴파일된 설치의 경우…

대신:

  • 소스로부터 설치의 경우…

더 많은 정보는 다른 설치 방법을 참조하세요.

-ing 형태

가능한 경우 -ing 단어를 제거하십시오. 번역하기 어려울 수 있으며 더 정확한 용어가 대체로 사용됩니다. 예를 들어,

  • 저장소를 사용하는 파일이 삭제됩니다 대신 저장소를 사용하는 파일이 삭제됩니다를 사용합니다.
  • 편집 버튼을 사용하여 파일을 삭제하십시오 대신 편집 버튼을 사용하여 파일을 삭제합니다를 사용합니다.
  • 서버를 복제해야 합니다 대신 서버를 복제해야 합니다를 사용합니다.

이슈

issue를 소문자로 사용합니다.

이슈 보드

이슈 보드를 소문자로 사용합니다.

이슈 설명 생성

이슈 설명 생성의 경우 타이틀 케이스를 사용합니다.

페이지에서 처음 언급할 때는 GitLab Duo 이슈 설명 생성을 사용합니다. 그 이후에는 이슈 설명 생성만 사용합니다.

이슈 토론 요약

이슈 토론 요약은 타이틀 케이스를 사용합니다.

페이지에서 처음 언급할 때는 GitLab Duo 이슈 토론 요약을 사용합니다. 그 이후에는 이슈 토론 요약만 사용합니다.

이슈 가중치

이슈 가중치는 소문자로 사용합니다.

IP 주소

인터넷 프로토콜(IP) 주소와 관련하여 IP 주소를 사용합니다. IP 주소를 IP로 참조하지 마십시오.

그것

그것이라는 단어를 사용할 때, 그것이 가리키는 대상이 명확한지 확인하십시오. 명확하지 않으면 그것을 사용하는 대신 단어를 반복하십시오.

사용:

  • 해당 필드는 연결을 반환합니다. 해당 필드는 네 개의 인수를 허용합니다.

대신:

  • 해당 필드는 연결을 반환합니다. 해당 필드는 네 개의 인수를 허용합니다.

또한 this, these, that, those를 참고하세요.

작업

작업을 나타내는 것으로 빌드를 사용하지 마십시오. 작업은 .gitlab-ci.yml 파일에서 정의되며 파이프라인의 일부로 실행됩니다.

CI와 함께 작업을 사용하려면 CI 작업 대신 CI/CD 작업을 사용하십시오.

Kubernetes 실행자

GitLab Runner는 Kubernetes 클러스터에서 작업을 실행할 수 있습니다. 이 기능을 참조할 때는 다음을 사용하세요.

  • GitLab Runner용 Kubernetes 실행자
  • Kubernetes 실행자

다음을 사용하지 마십시오.

  • GitLab Runner Kubernetes 실행자는 Kubernetes 상표권을 침해할 수 있으므로 사용하지 마십시오.

이후

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

사용:

  • GitLab 14.1 이후…

대신:

  • GitLab 14.1 이상…
  • GitLab 14.1 이상 버전…
  • GitLab 14.1 이상층수…

수준

수준은 인스턴스, 프로젝트 또는 그룹의 맥락에서 가능하면 피하십시오.

다음을 사용하세요:

  • 해당 설정은 인스턴스에 대해 켜져 있습니다.
  • 해당 설정은 그룹 및 해당 하위 그룹에 대해 켜져 있습니다.
  • 해당 설정은 프로젝트에 대해 켜져 있습니다.

대신:

  • 해당 설정은 인스턴스 수준에서 켜져 있습니다.
  • 해당 설정은 그룹 수준에서 켜져 있습니다.
  • 이것은 프로젝트 수준의 설정입니다.

목록

드롭다운 목록을 참조할 때 목록을 사용하지 마십시오. 대신 드롭다운 목록 전체 구: 드롭다운 목록을 사용하여 페이지가 채워집니다. 그러나 이슈 목록이 아니라 이슈 페이지라고 해야 합니다.

라이선스

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

  • 라이선스는 사용자에게 구매한 구독에 대한 액세스 권한을 부여합니다. 라이선스에는 좌석 수 및 구독 날짜와 같은 정보가 포함됩니다.
  • 구독은 사용자가 구매한 구독 계층입니다.

클라우드 라이선싱 용어를 사용하지 마십시오.

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

  • 온라인 라이선스 - GitLab과 동기화된 라이선스
  • 오프라인 라이선스 - GitLab과 동기화되지 않은 라이선스
  • 레거시 라이선스 - 동기화가 가능해진 이전에 생성된 라이선스

그러나 가능하다면 용어 대신 더 구체적인 설명을 사용하는 것이 좋습니다.

사용:

  • 인스턴스에 라이선스 추가.
  • 구독 구매.

대신:

  • 라이선스 구매.
  • 구독을 구매합니다.

known issues

Do not use known issues. Use known issues instead.

sign in, sign in

Do not use:

  • sign in.
  • sign in.
  • sign in

Use sign in instead.

However, if the user interface has Log in, you should match the UI.

authenticated user

Use authenticated user instead of logged-in user or logged in user.

In GitLab 14.1 and earlier.

Do not use lower when talking about version numbers.

Use:

  • In GitLab 14.1 and earlier.

Instead of:

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

machine learning

Use lowercase for machine learning.

When machine learning is used as an adjective, like a machine learning model, do not hyphenate. While a hyphen might be more grammatically correct, we risk becoming inconsistent if we try to be more precise.

Maintainer

When writing about the Maintainer role:

  • Use a capital M.
  • Write it out.
    • Use: if you are assigned the Maintainer role
    • Instead of: if you are a maintainer
  • When the Maintainer role is the minimum required role:
    • Use: at least the Maintainer role
    • Instead of: the Maintainer role or higher

Do not use bold.

Do not use Maintainer permissions. A user who is assigned the Maintainer role has a set of associated permissions.

people

Do not use mankind. Use people or humanity instead. (Vale rule: InclusiveLanguage.yml)

workforce

Do not use manpower. Use words like workforce or GitLab team members. (Vale rule: InclusiveLanguage.yml)

main

Do not use master. Use main when you need a sample default branch name. (Vale rule: InclusiveLanguage.yml)

might, can

Might means something has the probability of occurring. Might is often used in troubleshooting documentation.

can gives permission to do something. Consider can instead of may.

Consider rewording phrases that use these terms. These terms often indicate possibility and doubt, and technical writing strives to be precise.

See also you can.

Use:

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

Instead of:

  • 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, megabytes

For MB and GB, follow the Microsoft guidance.

member

When you add a user account to a group or project, the user account becomes a member.

Merge Commit Message Generation

Use title case for Merge Commit Message Generation.

On first mention on a page, use GitLab Duo Merge Commit Message Generation. Thereafter, use Merge Commit Message Generation by itself.

merge request branch

Do not use merge request branch. See branch.

merge requests

Use lowercase for merge requests. If you use MR as the acronym, spell it out on first use.

Merge Request Summary

Use title case for Merge Request Summary.

On first mention on a page, use GitLab Duo Merge Request Summary. Thereafter, use Merge Request Summary by itself.

milestones

Use lowercase for milestones.

Minimal Access

When writing about the Minimal Access role:

  • Use a capital M and a capital A.
  • Write it out:
    • Use: if you are assigned the Minimal Access role
    • Instead of: if you are a Minimal Access user
  • When the Minimal Access role is the minimum required role:
    • Use: at least the Minimal Access role
    • Instead of: the Minimal Access role or higher

Do not use bold.

Do not use Minimal Access permissions. A user who is assigned the Minimal Access role has a set of associated permissions.

n/a, N/A, not applicable

When possible, use not applicable. Spelling out the phrase helps non-English speaking users and avoids capitalization inconsistencies.

go

Do not use navigate. Use go instead. For example:

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

(Vale rule: SubstitutionWarning.yml)

Try to avoid need to, because it’s wordy.

For example, when a variable is required, instead of You need to set the variable, use:

  • Set the variable.
  • You must set the variable.

When the variable is recommended:

  • You should set the variable.

When the variable is optional:

  • You can set the variable.

new

Often, you can avoid the word new. When you create an object, it is new, so you don’t need this additional word.

See also create and add.

newer

Do not use newer when talking about version numbers.

Use:

  • In GitLab 14.4 and later…

Instead of:

  • In GitLab 14.4 and higher…
  • In GitLab 14.4 and above…
  • In GitLab 14.4 and newer…

일반적으로, 보통, 일반

normal을 보통, 표준적인 방법을 의미하는 용어로 사용하지 마십시오. 다음 용어를 사용하십시오.

사용:

  • 일반적으로, 인증서를 지정합니다.
  • 보통, 인증서를 지정합니다.
  • 표준 Git 워크플로우를 따릅니다.

대신에:

  • 보통, 인증서를 지정합니다.
  • 일반적인 Git 워크플로우를 따릅니다.

(Vale 규칙: Normal.yml)

유의하세요, 유의하십시오

note that은 길어서 사용하지 마십시오.

사용:

  • 설정을 변경할 수 있습니다.

대신에:

  • 설정을 변경할 수 있다는 점을 유의하세요.

오퍼링

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

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

오래된

버전 번호에 대해 이야기할 때 older를 사용하지 마십시오.

사용:

  • GitLab 14.1 및 이전 버전에서

대신에:

  • GitLab 14.1 및 하위 버전에서
  • GitLab 14.1 및 오래된 버전에서

Omnibus GitLab

리눅스 패키지를 사용하는 설치 방법을 가리킬 때 Omnibus GitLab 대신 리눅스 패키지라고 지칭하십시오.

사용:

  • 리눅스 패키지를 사용하는 인스톨에 대해…

대신에:

  • Omnibus GitLab을 사용하는 인스톨에 대해…

더 많은 정보는 다양한 설치 방법을 참조하십시오.

에,에서

고수준 UI 요소를 문서화할 때, 전치사로 에서(on)를 사용하십시오. 예를 들어:

  • 왼쪽 사이드바에서 설정 > CI/CD를 선택하십시오.
  • 권한 부여 대화상자에서 그룹을 선택하십시오.

from이나 in을 사용하지 마십시오. 더 많은 정보는 Microsoft Style Guide를 참조하십시오.

한 번

한 번은 한 번의를 의미합니다. 이를 이후 또는 시점으로 사용하지 마십시오.

사용:

  • 프로세스가 완료되면…

대신에:

  • 프로세스가 완료되면…

only

only를 수정하는 단어 바로 옆에 놓으십시오.

다음 예시에서 only는 명사 프로젝트(projects)를 수정합니다. 의미는 한 가지 유형의 프로젝트, 즉 비공개 프로젝트를 생성할 수 있다는 것입니다.

  • 당신은 오직 비공개 프로젝트만 생성할 수 있습니다.

다음 예시에서 only는 동사 create를 수정합니다. 의미는 비공개 프로젝트를 생성할 뿐 다른 작업(비공개 프로젝트 삭제, 사용자 추가 등)은 할 수 없다는 것입니다.

  • 당신은 오직 비공개 프로젝트만 생성할 수 있습니다.

override

일시적인 대체를 나타내기 위해 override를 사용하십시오.

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

overwrite

영구적인 대체를 나타내기 위해 overwrite를 사용하십시오.

예를 들어 로그 파일은 동일한 이름의 로그 파일을 덮어씁니다.

소유자

소유자 역할에 대해 작성할 때:

  • 앞에 대문자 O를 사용하십시오.
  • 완전한 형태로 사용하십시오.
    • 할당된 소유자 역할인 경우
    • 대신에: 사용자가 소유자인 경우

볼드체를 사용하지 마십시오.

소유자 권한을 사용하지 마십시오. 소유자 역할이 부여된 사용자는 연관된 권한 세트를 가지고 있습니다. 소유자는 사용자가 가질 수 있는 최고의 역할입니다.

패키지 레지스트리

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

사용:

  • GitLab 패키지 레지스트리는 A, B, C를 지원합니다.
  • 프로젝트의 패키지 레지스트리에 패키지를 게시할 수 있습니다.

페이지

“이슈(Issues) 페이지에서”와 같은 구절을 작성할 때 근처에 해당 페이지로 이동하는 방법이 있어야 합니다. 그렇지 않으면 사람들은 이슈(Issues) 페이지가 무엇인지 모를 수 있습니다.

페이지 이름은 페이지 상단의 UI에 표시되어야 합니다. 그렇지 않은 경우, 경로를 이용해 이름을 찾을 수 있어야 합니다.

문서는 UI와 일치하도록 작성되어야 하며, 페이지 이름은 볼드체여야 합니다. 예를 들어:

  • 테스트 케이스(Test cases) 페이지에서…

부모

항상 복합 명사로 사용하십시오.

직계ancestor나 선조를 사용하지 마십시오.

예시:

  • 상위 디렉토리
  • 상위 그룹
  • 상위 프로젝트
  • 상위 커밋
  • 상위 이슈
  • 상위 아이템
  • 상위 에픽
  • 상위 목표
  • 상위 파이프라인

참고: 하위(Child), 하위 그룹(Subgroup).

권한

역할(roles)과 권한을 서로 교환해서 사용하지 마십시오. 각 사용자에게 역할이 할당되어 있습니다. 각 역할에는 권한 세트가 포함되어 있습니다.

권한은 접근 수준(access levels)과 같지 않습니다.

개인 액세스 토큰

개인 액세스 토큰은 문장으로 작성하십시오.

UI를 말할 때 첫 번째 단어를 대문자로 쓰십시오.

부디

제품 설명서에서는 부디를 사용하지 마십시오.

UI 텍스트에서는 사용자가 불편을 겪었을 때 부디를 사용하십시오. 더 많은 정보는 Microsoft Style Guide를 참조하십시오.

프리미엄

가입 등급을 나타내는 프리미엄은 대문자로 사용하십시오. 프리미엄을 다른 가입 등급의 맥락에서 사용할 때는 가입 등급 지침을 따르십시오.

기본 설정

테마나 레이아웃 같은 사용자별 시스템 수준 설정을 나타낼 때 기본 설정을 사용하십시오.

전제 조건

사용자가 작업을 완료하기 전에 완료해야 하는 작업이나 만족해야 하는 조건을 문서화할 때 전제 조건을 사용하십시오. 요구 사항은 사용하지 마십시오.

전제 조건은 항상 복수형이어야 합니다. 하나만 목록에 있더라도 항상 복수로 표기해야 합니다.

더 많은 정보는 작업 주제 유형을 참조하십시오.

튜토리얼 페이지 유형의 경우 시작하기 전에를 사용하십시오.

눌러, 누르기

키보드 키에 대해 이야기할 때 누르기를 사용하십시오. 예를 들어:

  • 명령을 중지하려면 Control+C를 누르십시오.

저주어

비속어를 사용하지 마십시오. 그렇게 함으로써 다른 사용자 및 기여자에게 부정적인 영향을 미칠 수 있으며, 이는 다양성, 포용, 함께함 GitLab 가치에 반하는 것입니다.

프로젝트 액세스 토큰

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

프로비저닝

클라우드 인프라 프로비저닝을 언급할 때는 용어 프로비저닝을 사용합니다. 인프라를 프로비저닝하고 나서 응용 프로그램을 배포합니다.

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

  • AWS EKS 클러스터를 프로비저닝하고 응용 프로그램을 배포합니다.

푸시 규칙

푸시 규칙을 소문자로 사용합니다.

quite

quite는 단어가 너무 많으므로 사용하지 않습니다.

README 파일

README 파일 또는 README.md 파일에 대해 역따옴표와 소문자를 사용합니다.

가능한 경우, 전체 구절 README 파일 을 사용합니다.

복수의 경우에는 README 파일 을 사용합니다.

추천, 권장

권장하는 것입니다의 대신에 해야 합니다를 사용합니다. 사용자에게 동료와 대화하는 방식으로 말하고 우리와 그들 간의 차별을 피합니다.

  • 변수를 설정해야 합니다. (권장사항입니다.)
  • 변수를 설정합니다. (필수 사항입니다.)
  • 변수를 설정할 수 있습니다. (선택 사항입니다.)

또한 권장 단계를 참조하십시오.

등록

계정을 생성하는 경우 등록을 사용합니다.

제거

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

객체를 완전히 삭제하는 경우 삭제를 사용합니다.

리포터

리포터 역할에 대해 쓸 때:

  • R을 대문자로 사용합니다.
  • 전체로 씁니다.
    • 배정된 리포터 역할이 있는 경우 사용합니다.
    • 배정된 리포터 역할이 있는 경우 사용하지 않습니다.

Reporter permissions를 사용하지 않습니다. 리포터 역할이 할당된 사용자에게는 일련의 관련 권한이 있습니다.

저장소 미러링

저장소 미러링에 대해서는 제목을 대문자로 사용합니다.

해결 및 해결책

문제를 영구적으로 해결하는 해결책에 해결책을 사용합니다. 해결은 보통 문제를 수정하기 위한 파일 및 코드 변경을 포함합니다.

예를 들어:

  • 이 문제를 해결하려면 .gitlab-ci.yml 파일을 업데이트하십시오.
  • 해결책 중 하나는 .gitlab-ci.yml 파일을 업데이트하는 것입니다.

또한 해결책을 참조하십시오.

사전 조건

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

  • 작업에는 필수 조건을 사용합니다. 자세한 정보는 작업 주제 유형을 참조하십시오.
  • 자습서의 경우 시작하기 전에를 사용합니다. 자세한 정보는 자습서 페이지 유형을 참조하십시오.

요구 사항을 사용하지 않습니다.

리셋

항목을 새 상태로 재설정하는 동작을 설명할 때 재설정을 사용합니다.

각각, 각기

각각보다 명확한 용어를 사용하여 피합니다. - 사용자를 생성하려면 사용자 만들기를 선택합니다. 기존 사용자인 경우 변경 사항 저장을 선택합니다.

복원

복원에 대한 지침은 Microsoft Style Guide에서 참조하십시오.

리뷰 앱

리뷰 앱에는 소문자를 사용합니다.

역할

사용자는 프로젝트나 그룹을 위한 역할을 가지고 있습니다. - 그룹에 대한 소유자 역할이 있어야 합니다.

권한이라는 용어를 역할과 교환하여 사용하지 않습니다. 각 사용자에게는 역할이 지정되어 있으며 각 역할에는 일련의 권한이 포함되어 있습니다.

두 가지 유형의 역할이 있습니다: 사용자 정의와 기본.

역할은 액세스 레벨과 동일하지 않습니다.

근본 원인 분석

근본 원인 분석에 대해서는 제목을 대문자로 사용합니다.

페이지 최초 언급에서는 GitLab Duo 근본 원인 분석을 사용합니다. 그 후로는 근본 원인 분석만 사용합니다.

롤백

GitLab 버전을 이전 버전으로 변경하는 경우 롤백을 사용합니다.

라이선스나 구독에 대해 롤백을 사용하지 않습니다. 대신 구독 티어 변경을 사용합니다.

러너

러너의 경우 소문자를 사용합니다. 이는 CI/CD 작업을 실행하는 에이전트입니다. GitLab Runner 및 이 이슈도 참조하십시오.

러너에 언급할 때 고객의 GitLab 인스턴스에 설치된 러너를 명확히 해야하는 경우 자체 관리를 사용합니다.

러너의 범위에 대해 언급할 때 다음을 사용합니다.

  • 프로젝트 러너: 특정 프로젝트에 연결된 러너입니다.
  • 그룹 러너: 그룹 내 모든 프로젝트와 하위 그룹에서 사용할 수 있는 러너입니다.
  • 인스턴스 러너: GitLab 인스턴스의 모든 그룹과 프로젝트에서 사용할 수 있는 러너입니다.

러너 매니저

러너 매니저에 대해서는 소문자를 사용합니다. 이것들은 자동 스케일링을 위해 여러 러너를 만들 수 있는 러너 유형입니다. GitLab Runner를 참조하십시오.

러너 워커

러너 워커에 대해서는 소문자를 사용합니다. 이는 러너에 의해 호스트 컴퓨팅 플랫폼에서 생성된 작업 실행 프로세스입니다. GitLab Runner를 참조하십시오.

러너 인증 토큰

러너 인증 토큰을 사용합니다. 러너는 생성될 때 러너 인증 토큰이 할당되고 작업을 실행할 때 GitLab에서 인증하는 데 사용합니다.

Runner SaaS, SaaS 러너

Runner SaaS 또는 SaaS 러너를 사용하지 않습니다.

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

서비스 및 운영 체제를 구체적으로 지정하려면 다음을 사용합니다.

  • GitLab.com용 호스팅된 러너
  • GitLab Dedicated용 호스팅된 러너
  • GitLab.com용 Linux 호스팅된 러너
  • GitLab.com용 Windows 호스팅된 러너

GitLab- 접두사 없이 또는 제공으로 사용하지 않습니다.

(s)

단어를 선택적으로 복수형으로 만들려면 (s)를 사용하지 마세요. 이렇게 하면 이해하는 데 시간이 더 오래 걸릴 수 있습니다. 예시:

사용하세요:

  • 원하는 작업을 선택하세요.

대신에:

  • 작업을 선택하세요.

하나 이상의 것을 선택할 수 있다면, 단어를 복수형으로 작성하세요.

sanity check

점검 완료 대신에 완전함을 확인 사용하세요. (Vale rule: InclusiveLanguage.yml)

scalability

GitLab의 성능을 추가 사용자용으로 증가시킬 때 scalability를 사용하지 마세요. scalability를 사용할 때, scale 또는 scaling은 종종 허용되지만, 추가 사용자용으로 GitLab의 성능을 증가시키기에 대한 참조는 독자들을 GitLab 참조 아키텍처 페이지로 안내해야 합니다.

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

검색은 filtering와 다릅니다.

seats

구독 요금 청구 모델을 지칭할 때:

  • GitLab SaaS의 경우 seats를 사용합니다. 고객은 seats를 구매합니다. 사용자는 그룹에 초대되었을 때 seats를 차지합니다 (exceptions 참조).
  • GitLab self-managed의 경우 users를 사용합니다. 고객은 특정 수의 users에 대한 구독을 구매합니다.

section

페이지의 부분을 설명할 때 section을 사용하세요. 예를 들어, 페이지에 UI를 분리하는 선이 있다면, 이러한 영역을 section으로 참조하세요.

우리는 주로 확장/축소 가능한 영역을 section으로 생각합니다. 영역을 확장하거나 축소할 때 section이라는 단어를 포함하지 마세요.

사용하세요:

  • Auto DevOps를 확장하세요.

대신에:

  • Auto DevOps 섹션을 확장하지 마세요.

select

버튼, 링크, 메뉴 항목 및 목록에 select를 사용하세요. Select는 더 많은 디바이스에 적용되고, click은 보다 구체적으로 마우스에 관련되어 있습니다.

그러나 right-click 및 click-through demo의 경우에는 예외를 할 수 있습니다.

self-hosted model

고객이 호스팅하는 언어 모델을 가리키기 위해 self-hosted model (소문자)을 사용하세요. 이 언어 모델은 LLM (large language model)이 될 수도 있지만, 의무적이지는 않습니다.

Self-Hosted Models

GitLab Duo Self-Hosted Models 기능에 대해 제목케이스를 사용하세요.

페이지에서 처음 언급할 때는 GitLab Duo Self-Hosted Models을 사용하세요. 그 후에는 Self-Hosted Models만 사용하세요.

이 표현은 특히 기능 이름만을 명시적으로 참조할 때 적용됩니다. 자체 호스팅 모델에 대해 작성할 때에는 제목 케이스를 사용할 필요가 없습니다.

self-managed

GitLab의 고객 설치를 가리키기 위해 self-managed를 사용하세요. self-hosted를 사용하지 마세요.

Service Desk

Service Desk에 대해 제목 케이스를 사용하세요.

setup, set up

명사로 사용할 때는 setup을, 동사로 사용할 때는 set up을 사용하세요. 예를 들어:

  • 당신의 원격 사무실 설치는 멋집니다.
  • 원격 사무실을 올바르게 설치하려면 작업 영역의 인체공학을 고려하세요.

set up을 configure와 혼동하지 마세요. set up은 처음으로 무엇인가를 한다는 것을 의미합니다. 예를 들어:

  1. 설치를 설정하세요.
  2. 설치를 구성하세요.

settings

setting은 제품의 기본 동작을 변경합니다. setting은 일반적으로 하나 이상의 옵션으로 표시되는 레이블에 의해 표현되는 키/값의 쌍으로 구성됩니다.

sign in, sign-in

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

  • sign in
  • 동사로 사용할 때는 sign in to. 예를 들어: GitLab에 로그인하기 위해 비밀번호를 입력하세요.

또한 다음을 사용할 수 있습니다:

  • 명사 또는 형용사로 sign-in. 예를 들어: sign-in 페이지 또는 sign-in 제한.
  • single sign-on.

다음은 사용하지 마세요:

UI에 다른 단어가 있는 경우, 해당 단어를 사용할 수 있습니다.

sign up

계정을 생성하는 것에 대해 이야기할 때 sign up 대신에 register를 사용하세요.

signed-in user, signed in user

인증된 사용자를 사용하지 마세요.

simply, simple

simply 또는 simple를 사용하지 마세요. 사용자가 프로세스를 간단하게 느끼지 않는다면 신뢰를 잃게 됩니다. (Vale rule: Simplicity.yml)

since

since라는 단어는 시간흐름을 나타냅니다. 예를 들어 1984년 이후에는 Bon Jovi가 존재했습니다. since를 because의 의미로 사용하지 마세요.

다음을 사용하세요:

  • 개발자 역할을 가지고 있기 때문에 위젯을 삭제할 수 있습니다.

대신에:

  • 개발자 역할을 가지고 있기 때문에 위젯을 삭제할 수 있습니다.

slashes

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

slave

slave를 사용하지 마세요. 대안으로 secondary을 사용하세요. (Vale rule: InclusiveLanguage.yml)

storages

  • Gitaly의 경우, storage는 물리적이며 storage라고 해야 합니다.
  • Gitaly Cluster의 경우, storage는 다음 중 하나일 수 있습니다:
    • 가상적이며 가상 스토리지라고 해야 합니다.
    • 물리적이며 물리적 스토리지라고 해야 합니다.

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

하위 그룹

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

(Vale rule: SubstitutionWarning.yml)

구독 티어

구독 또는 구독 티어를 라이선스와 혼동하지 마세요. 사용자는 구독을 구매합니다. 해당 구독에는 티어가 있습니다.

티어를 설명하기 위해:

대신에 사용하세요
Free 티어 이상에서 모든 티어에서
Free 티어 이상으로 모든 티어에서
Premium 티어 이상에서 프리미엄 및 얼티메이트 티어에서
Premium 티어 이상으로 프리미엄 및 얼티메이트 티어에서
Premium 티어 이하에서 Free 및 프리미엄 티어에서

추천 리뷰어

추천 리뷰어에는 타이틀 케이스를 사용하세요.

추천 리뷰어는 항상 복수형이어야 하며, 일반적이더라도 대문자로 표기합니다.

예시:

  • 추천 리뷰어는 여러분의 병합 요청을 검토할 사람을 추천할 수 있습니다. (이 구문은 기능을 설명합니다.)
  • 타이핑하는 동안, 추천 리뷰어가 표시됩니다. (이 구문은 일반적이지만 대문자를 사용합니다.)

탭

탭 이름에는 볼드체를 사용합니다. 예를 들면:

  • 파이프라인 탭
  • 개요 탭

지시하는 형용사 사용

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

사용하세요:

  • 당신이 저장하는 파일…

대신에:

  • 당신이 저장하는 that 파일…

이것, 이들, 그것, 그들도 참조하세요.

터미널

터미널은 소문자로 사용하세요. 예를 들면:

  • 터미널을 엽니다.
  • 터미널에서 docker login 명령을 실행합니다.

GitLab Terraform 모듈 레지스트리

GitLab Terraform 모듈 레지스트리에 대한 타이틀 케이스를 사용하지만 일반적인 모듈에 대해 이야기할 때는 m은 소문자로 사용하세요. 예를 들면:

  • 프로젝트의 GitLab Terraform 모듈 레지스트리에 Terraform 모듈을 게시할 수 있습니다.

테스트 생성

테스트 생성에 대해 타이틀 케이스를 사용하세요.

페이지에서 처음 언급할 때는 GitLab Duo 테스트 생성을 사용합니다. 이후에는 테스트 생성만 사용하세요.

텍스트 상자

UI 요소 구내에는 필드 또는 상자 대신 텍스트 상자를 사용하세요.

존재하는 것

존재하는 것인 문장을 피하십시오. 이러한 문구는 주어를 숨 깁니다.

사용하세요:

  • 그 양동이에 구멍이 있습니다.

대신에:

  • 그 양동이에는 구멍이 있습니다.

그들

특정한 사람을 언급하지 않는 한, 성별 특정 대명사를 피하세요. 성별 중립적인 대명사로서 명사에 대해 단수 그들을 사용하세요.

이것, 이들, 그것, 그들

이러한 단어 뒤에 항상 명사를 사용하세요. 예를 들면:

  • 이 설정은 성능을 향상시킵니다.

  • 대신에: 이는 성능을 향상시킵니다.

  • 이 바지가 제일 좋아요.

  • 대신에: 이들이 제일 좋아요.

  • 그 드로이드가 당신이 찾고 있는 것입니다.

  • 대신에: 그가 당신이 찾고 있는 것입니다.

  • 그 설정을 구성해야 합니다. (또는 더 나은 표현으로 그 설정을 구성하세요.)
  • 대신에: 그를 구성해야 합니다.

~에, ~의

~에와 ~의를 피하고 전치사가 문장의 끝에서 매달려도록 하십시오. 예시는 전치사를 참조하세요.

할 일

할 일에 대해 소문자와 하이픈을 사용하세요. (Vale rule: ToDo.yml)

할 일 목록

할 일 목록에 대해 타이틀 케이스를 사용하세요. (Vale rule: ToDo.yml)

토글

토글을 켜거나 끄는 것으로서 사용하세요. 예를 들어:

  • blah 토글을 켜세요.

2FA, 이중 인증

2FA와 이중 인증을 사용하세요.

타이핑

커서가 있는 위치에 문자를 입력할 때 타이핑을 사용하세요. 예를 들어, 검색 상자에서 시작하고 검색 결과가 표시될 때 검색 상자 밖을 클릭하지 않습니다.

예시:

  • “Alex”라고 타이핑하여 모든 이름이 Alex인 사용자를 확인하세요.
  • “doc”라고 타이핑하여 문서 팀의 모든 라벨을 확인하세요.
  • 빠른 조치 목록을 보려면 /를 타이핑하세요.

입력도 참조하세요.

얼티메이트

구독 티어로서 얼티메이트를 대문자로 사용하세요. 다른 구독 티어에서 얼티메이트를 언급할 때는 구독 티어 지침을 따라주세요.

되돌리기

되돌리기에 대한 지침은 Microsoft Style Guide를 참조하세요.

측정 기준 단위

측정값과 측정 기준 단위 사이에는 공백을 사용하세요. 예를 들어 128 GB. (Vale rule: Units.yml)

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

업데이트

새로운 패치 버전을 설치할 때 업데이트를 사용하세요. 예를 들어:

  • GitLab을 14.9에서 14.9.1로 업데이트합니다.

업데이트를 다른 경우에는 사용하지 마세요. 대신 업그레이드를 사용하세요.

업그레이드

업그레이드는 다음과 같은 경우에 사용하세요:

  • 더 높은 구독 티어(Premium 또는 Ultimate)를 선택합니다.
  • GitLab의 새로운 주요(13.0) 또는 부 (13.2) 버전을 설치합니다.

예를 들어:

  • GitLab 얼티메이트로 업그레이드합니다.
  • GitLab을 14.0에서 14.1로 업그레이드합니다.
  • GitLab을 14.0에서 15.0로 업그레이드합니다.

주변 텍스트에서 제품 버전 또는 구독 티어에 대한 부연 설명을 하는지 확인하세요.

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

왼쪽 상단, 오른쪽 상단

UI에서 방향을 제시하기 위해 upper-left corner과 upper-right corner를 사용하세요. UI 요소가 모서리에 없는 경우 upper left와 upper right를 사용하세요.

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

더 많은 정보는 Microsoft Style Guide를 참조하세요.

유용한

유용한을 사용하지 마세요. 사용자가 프로세스를 유용하게 여기지 않는다면, 우리는 그들의 신뢰를 잃습니다. (Vale 규칙: Simplicity.yml)

사용자 계정

사용자 계정을 생성하세요. 사용자 계정에는 액세스 레벨이 있습니다. 그룹이나 프로젝트에 사용자 계정을 추가할 때, 해당 사용자 계정은 멤버가 됩니다.

사용 중

대부분의 경우 사용 중을 피하세요. 주어를 숨기고 구문을 더 어렵게 만듭니다. 사용 중인 대신 사용하는 또는 문장을 재구성하세요.

예: - The files using storage… - The files that use storage…

예: - 명령줄을 사용하여 디렉터리 변경. - 명령줄을 사용하여 디렉터리 변경하세요. 또는 더 나은 해결책: 디렉터리를 변경하려면 명령줄을 사용하세요.

활용

활용을 사용하지 마세요. 활용 대신 사용을 사용하세요. 더 간결하고 비영어 사용자가 이해하기 쉽습니다. (Vale 규칙: SubstitutionWarning.yml)

버전, v

GitLab 버전을 설명할 때 GitLab <버전번호>를 사용하세요. 예를 들어: - GitLab 16.0 이상이 필요합니다.

기타 소프트웨어에 대한 설명은 해당 소프트웨어의 문서와 동일한 스타일을 사용하세요. 예를 들어: - Kubernetes 1.4에서는…

v 뒤에는 공백이 없음을 주의하세요. 세맨틱 버전에서 v 다음에는 공백이 없습니다. 예를 들어: - v1.2.3

via

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

취약점 설명

Vulnerability Explanation에 대해 제목 케이스를 사용하세요.

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

취약점 해결

Vulnerability Resolution에 대해 제목 케이스를 사용하세요.

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

우리

우리를 피하고 사용자가 GitLab에서 어떻게 작업을 수행할 수 있는지에 중점을 둡니다.

다음을 사용하세요: - 작업을 정리하려는 경우 위젯을 사용하세요.

다음과 같은 것을 사용하지 마세요: - 우리는 당신이 위젯을 추가할 수 있는 기능을 만들었습니다.

해결책

문제 해결 솔루션이 일시적인 수정일 때 workaround을 사용하세요. 일시적인 수정이며 계속된 문제가 있을 수 있습니다. 예를 들어: - 임시 방편은 템플릿을 폐기된 버전에 일시적으로 고정하는 것입니다.

해상을 참조하세요.

동안

동안은 시간에 따라 발생하는 것에만 사용하세요. 예를 들어, 프로세스가 실행되는 동안 창을 열어 둡니다.

비교를 위해 동안을 사용하지 마세요. 예를 들어, 다음과 같이 사용하세요: - Job 1은 빠르게 실행될 수 있습니다. 그러나 job 2는 더 정밀합니다.

다음과 같이 사용하지 마세요: - Job 1은 빠르게 실행될 수 있지만 job 2는 더 정밀합니다.

더 많은 정보는 Microsoft Style Guide를 참조하세요.

whilst

whilst를 사용하지 마세요. while 대신에 사용하세요. while은 더 간결하고 비영어 사용자가 이해하기 쉽습니다.

허용 목록

허용 목록을 사용하지 마세요. 다른 옵션은 allowlist입니다. (Vale 규칙: InclusiveLanguage.yml)

내부/안에

가능한 경우 내부/안에를 사용하지 마세요. 시간 프레임, 제한 또는 경계에 참조할 경우를 제외하고 안을 사용하세요. 예를 들어: - 업그레이드는 4시간 동안의 유지 관리 윈도우 내에서 발생합니다. - Wi-Fi 신호는 30피트 반경 내에서 접근할 수 있습니다. (Vale 규칙: SubstitutionWarning.yml)

아직

제품이나 해당 기능에 대해 아직을 사용하지 마세요. 문서는 제품을 현재 그대로 설명합니다.

가끔 작업을 작성할 때 아직을 사용해야 할 수 있습니다. 아직을 사용하는 경우 주변 구절이 현재 시제, 능동태로 작성되었는지 확인하세요.

앞으로의 기능에 대한 작성 방법에 대한 지침을 보려면 클릭하세요.

you, your, yours

문서는 제품을 설치, 구성, 관리 또는 사용하는 모든 사용자에게 직접적으로 말해야 합니다.

다음을 사용하세요: - 파이프라인을 구성할 수 있습니다. - 사용자 비밀번호를 재설정할 수 있습니다. (관리자용 콘텐츠에 대한 내용)

다음과 같은 것을 사용하지 마세요: - 사용자는 파이프라인을 구성할 수 있습니다. - 관리자들은 사용자 비밀번호를 재설정할 수 있습니다.

가능하다/할 수 있다

가능한 경우 할 수 있다 대신에 활동 동사로 시작하는 문장을 사용하세요. 예를 들어: - 코드 리뷰 분석을 사용하여 병합 요청 데이터를 보세요. - 팀 작업을 조직화하기 위해 보드를 생성하세요. - 변수를 구성하여 저장소에 푸시를 제한하세요. - Skype 및 Twitter와 같은 외부 계정에 링크를 추가하세요.

선택적인 작업을 위해 할 수 있다/하는 것이 좋다를 사용하세요. 예를 들어: - 코드 리뷰 분석을 사용하여 병합 요청당 메트릭을 볼 수 있습니다. 또한 API를 사용할 수 있습니다. - 이름과 값 이진을 입력하세요. 스트리밍 대상당 최대 20개의 이진을 추가할 수 있습니다.