권장 단어 디렉터리

기술 문서 작성 팀이 일관성을 유지하기 위해 이러한 단어 선택을 권장합니다. 또한:

이 페이지에 없는 지침에 대해서는 다음 스타일 가이드를 참조하십시오:

.gitlab-ci.yml 파일

.gitlab-ci.yml 파일을 나타내는 데 역따옴표와 소문자를 사용합니다.

가능한 경우, .gitlab-ci.yml 파일이라는 전체 구절을 사용합니다.

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

&

라틴어 약어를 사용하지 마십시오. &을 사용하는 UI 요소를 문서화하는 경우를 제외하고 and를 대신 사용하십시오.

@mention

@mention을 피하십시오. 대신 mention을 사용하고 mentions topic에 링크하는 것을 고려해보십시오. 역따옴표를 사용하지 마십시오.

2FA, 이중 인증

문장 케이스로 첫 사용 및 주제 제목에서 이중 인증을 철자로 나열하고 그 후에는 2FA를 사용하십시오. 문장의 첫 단어인 경우 factor 또는 authentication을 대문자로 만들지 마십시오. 예를 들면:

  • 이중 인증(2FA)은 계정 보안을 돕습니다. 처음으로 로그인할 때 2FA를 설정하십시오.

이전

문서에서 예시나 표를 참조할 때 이전을 사용하는 것을 피하십시오. 필요한 경우 이전을 대신 사용하십시오. 예를 들면:

  • 이전 예시에서 개는 벼룩을 가지고 있었습니다.

제품의 버전을 참조할 때 이전 대신 이후를 사용하십시오.

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

  • GitLab 14.4 및 이후…

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

  • GitLab 14.4 및 이상…
  • GitLab 14.4 및 그 이상…
  • GitLab 14.4 및 새로운…

액세스 수준

액세스 수준은 역할이나 권한과 다릅니다. 사용자를 생성할 때 액세스 수준을 선택합니다: 일반, 감사자, 또는 관리자.

UI를 참조할 때 이러한 단어를 대문자로 작성하며, 그 외의 경우 소문자를 사용하십시오.

추가

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

예:

  • 디렉터리에 사용자 추가
  • 이슈를 에픽에 추가

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

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

관리자 영역

Admin Area에 대해 제목 케이스를 사용하십시오. UI에서는 제목 케이스를 사용합니다.

administrator area, administration area 또는 다른 변형을 사용하지 마십시오.

관리자 모드

Admin Mode에 대해 제목 케이스를 사용하십시오. UI에서는 제목 케이스를 사용합니다.

관리자

사용자의 액세스 수준에 대해 말할 때 admin 대신 administrator access를 사용하십시오.

admin access level

administrator은 역할이나 권한이 아닙니다.

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

  • 이것을 수행하려면 관리자여야 합니다.
  • 이것을 수행하려면 관리자 액세스를 얻어야 합니다.

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

  • 이것을 수행하려면 관리자 역할이 필요합니다.

고급 검색

전체 GitLab 인스턴스 전체에서 더 빠르고 효율적인 검색을 참조할 때 고급 검색에 소문자를 사용하십시오.

에이전트

Kubernetes용 GitLab 에이전트를 참조할 때 소문자를 사용하십시오. 예를 들어:

  • 클러스터를 GitLab에 연결하려면 Kubernetes용 GitLab 에이전트를 사용하십시오.
  • 클러스터에 에이전트를 설치하십시오.
  • 디렉터리에서 에이전트를 선택하십시오.

GitLab Agent 또는 Kubernetes용 GitLab Agent에 대해 제목 케이스를 사용하지 마십시오.

에이전트 액세스 토큰

Kubernetes용 에이전트를 생성할 때 생성되는 토큰을 나타내는 데 에이전트 액세스 토큰을 사용하십시오. 다음을 사용하지 마십시오:

  • 등록 토큰
  • 비밀 토큰
  • 인증 토큰

AI, 인공 지능

AI를 사용하십시오. artificial intelligence을 철자로 나열하지 마십시오.

AI 기반 DevSecOps 플랫폼

GitLab 앞에 사용된 경우 Platform을 대문자로 만듭니다. 예를 들면, GitLab AI 기반 DevSecOps Platform.

공기 차단, 공기 차단된

물리적 장벽이나 인터넷 액세스를 방지하거나 제한하는 보안 정책이 있는 설치를 설명할 때 오프라인 환경을 사용하십시오. air gap, air gapped, air-gapped를 사용하지 마십시오. 예를 들면:

  • 오프라인 환경의 방화벽 정책으로 인해 컴퓨터가 인터넷에 액세스하는 것이 방지됩니다.

허용, 활성화

보안 관련 기능에 대한 경우를 제외하고 허용 및 활성화를 피하십시오.

다음을 사용하십시오:

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

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

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

이 표현은 보다 더 활동적이며 사용자의 관점에서 구현한 사람이 아닌 사용자의 관점에서 기술되었습니다. 자세한 내용은 Microsoft 스타일 가이드를 참조하십시오.

분석

analytics 및 이와 관련된 내용인 contribution analytics 및 issue analytics에 대문자가 있는 경우에는 UI와 문서를 일치시키십시오.

예를 들면:

  • 프로젝트의 Merge Request 분석을 볼 수 있습니다. 이들은 Merge Request 분석 대시보드에 표시됩니다.

그리고/또는

그리고/또는 대신 또는을 사용하거나 둘 다 옵션을 철자로 나열하도록 문장을 재작성하십시오.

이런 식으로

이런 식으로를 사용하지 마십시오. 보다 구체적으로 해주십시오. 자세한 내용은 Microsoft 스타일 가이드를 참조하십시오.

영역

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

~를 통해

as를 because의 의미로 사용하지 마십시오.

다음을 사용하십시오:

  • 어떤 엔드포인트도 ID를 반환하지 않습니다…

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

  • 특정 엔드포인트는 ID를 반환하지 않습니다…

뿐만 아니라

뿐만 아니라 대신 그리고를 사용하십시오.

연관시키다

이슈를 에픽에 추가하거나 사용자를 이슈, Merge Request, 또는 에픽에 할당할 때 associate를 사용하지 마십시오.

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

  • 이슈를 에픽에 할당하십시오.
  • 사용자를 이슈에 할당하십시오.

인증된 사용자

다른 변형인 signed in user 또는 logged in user 대신 authenticated user를 사용하십시오.

시작하기 전에

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

자세한 내용은 튜토리얼 페이지 유형 에서 prerequisites를 사용하십시오.

하단

예제나 표를 참조할 때 below를 사용하지 말고 following을 대신 사용하세요. 예를 들면:

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

beta

beta에는 소문자를 사용하세요. 예를 들면:

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

베타 기능에 관한 문구를 작성할 때 이 주제를 링크하는 것도 좋습니다.

denylist

denylist 대신 blacklist를 사용하지 마세요. 대안으로 denylist를 사용하세요. (Vale 규칙: InclusionCultural.yml)

board

boards, issue boards, 및 epic boards에 대해서는 소문자를 사용하세요.

text box

UI 필드를 참조할 때 text box를 사용하세요. field나 box를 사용하지 마세요. 예를 들면:

  • Variable name 텍스트 상자에 값을 입력하세요.

branch

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

  • default branch: 리포지터리의 기본 브랜치. 사용자들은 기본 브랜치를 설정할 수 있습니다. 기본 브랜치를 사용하는 예제에는 master 대신 main을 사용하세요.
  • source branch: Merge하는 브랜치.
  • target branch: Merge하는 대상 브랜치.
  • current branch: 현재 체크아웃된 브랜치. 이 브랜치는 기본 브랜치일 수도 있고, 사용자가 생성한 브랜치이거나, 소스 브랜치이거나 다른 브랜치일 수도 있습니다.

feature branch나 merge request branch와 같은 용어는 사용하지 마세요. 가능한 구체적으로 작성해주세요. 예를 들면:

  • 체크아웃한 브랜치…
  • 커밋을 추가한 브랜치…

list item

순서가 있는 디렉터리이나 순서가 없는 디렉터리의 개별 항목을 bullets로 표현하지 마세요. 대신 list item을 사용하세요. 명확히 하려면 다음과 같이 사용할 수 있습니다:

  • 순서가 있는 디렉터리의 항목: 순서가 있는 디렉터리의 항목
  • 순서가 없는 디렉터리의 항목: 순서가 없는 디렉터리의 항목

button

button과 함께 설명어를 사용하지 마세요.

다음과 같이 사용하세요:

  • Run pipelines을 선택하세요.

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

  • Run pipelines 버튼을 선택하세요.

cannot, can not

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

자세한 내용은 축약형을 참조하세요.

Chat, GitLab Duo Chat

Chat이나 GitLab Duo Chat에는 대문자 C를 사용하세요.

페이지에 처음 사용할 때는 GitLab Duo Chat을 사용하세요. 이후에는 Chat을 사용하세요.

checkbox

checkbox에는 한 단어만 사용하세요. check box를 사용하지 마세요.

체크박스는 select(check나 enable 대신)와 clear(deselect나 disable 대신)합니다. 예를 들면:

  • Protect environment 체크박스를 선택하세요.
  • Protect environment 체크박스를 선택 해제하세요.

체크박스를 참조할 경우 선택했는지 또는 선택되었는지 기술할 수 있습니다. 예를 들면:

  • Protect environment 체크박스가 선택되지 않았는지 확인하세요.
  • Protect environment 체크박스가 선택되었는지 확인하세요.

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

checkout, check out

check out은 동사로 사용합니다. Git 명령어를 사용할 때는 checkout를 사용하세요.

  • 로컬에서 브랜치를 확인하려면 git checkout을 사용하세요.
  • 편집하려는 파일을 확인하세요.

CI, CD

GitLab 기능에 관한 설명에서 CI/CD를 사용하세요. CI나 CD를 단독으로 사용하지 마세요.

CI/CD

CI/CD는 항상 대문자입니다. 첫 사용 시에 완전한 형태로 사용할 필요는 없습니다.

특히 처음 사용한 후에는 컨텍스트가 명확하다면 CI/CD를 생략할 수 있습니다. 예를 들면:

  • 코드를 CI/CD 파이프라인에서 테스트하세요. 파이프라인을 MR을 위해 설정하세요.
  • 값을 CI/CD 변수에 저장하세요. 변수를 마스킹하세요.

CI/CD minutes

CI/CD minutes를 사용하지 마세요. 이 용어는 compute minutes로 변경되었습니다.

click

click을 사용하지 마세요. 대신 버튼, 링크, 메뉴 항목, 및 디렉터리에 대해 select를 사용하세요. select은 더 많은 장치에 적용되는 반면 click은 더 구체적으로 마우스에 적용됩니다.

cloud licensing

cloud licensing이라는 구절을 사용하지 마세요. 대신 이 구독이 GitLab과 동기화됨을 강조하세요.

예를 들면:

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

cloud native

Kubernetes 클러스터를 사용하여 GitLab을 호스팅하는 경우 cloud-native version of GitLab을 사용하고 있습니다. 이러한 버전은 GitLab을 배포하는 더 크고 통합적인 Linux package와는 다릅니다.

축약형으로 cloud-native GitLab을 사용할 수도 있습니다. 하이픈과 소문자를 사용해야 합니다.

Code explanation

Code explanation에는 문장 부호가 들어가야 합니다.

페이지에 처음 사용할 때는 GitLab Duo Code explanation을 사용하세요. 이후에는 Code explanation을 사용하세요.

Code review summary

Code review summary에는 문장 부호가 들어가야 합니다.

페이지에 처음 사용할 때는 GitLab Duo Code review summary을 사용하세요. 이후에는 Code review summary을 사용하세요.

Code Suggestions

Code Suggestions에는 첫 글자가 대문자이어야 합니다. 페이지에 처음 사용할 때는 GitLab Duo Code Suggestions을 사용하세요.

Code Suggestions는 항상 복수형이어야 하며, 일반적인 케이스에서도 대문자를 사용합니다.

예시:

  • 글을 작성하는 동안 Code Suggestions를 사용하여 제안을 표시합니다. (이 문구는 기능을 설명합니다.)
  • 글을 작성하는 동안 Code Suggestions가 표시됩니다. (이 문구는 일반적이지만 여전히 대문자를 사용합니다.)

collapse

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

command line

명령어를 소개할 때 From the command line을 사용하세요.

명사로 사용할 때는 하이픈을 사용하세요. 예를 들면, a command-line tool.

compute

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

관련 용어:

  • compute minutes: 어떻게 컴퓨트 사용이 계산되는지에 대한 내용. 예를 들면, 400 compute minutes.
  • compute quota: 네임스페이스가 매달 사용할 수 있는 컴퓨트 분의 한도.
  • compute usage: 네임스페이스가 매달 할당된 할당량에서 사용한 컴퓨트 분의 수.

compute minutes

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

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

더 많은 정보는 epic 2150을 참조하세요.

configuration

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

configure

기능이나 제품을 설치한 후에는 configure를 사용하세요.

예를 들면:

  1. 설치를 완료하세요.
  2. 설치를 구성하세요.

confirmation dialog

작업을 확인하는 대화 상자를 설명할 때는 confirmation dialog를 사용하세요. 예를 들면:

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

confirmation box나 confirmation dialog box를 사용하지 마세요. 또한 dialog도 참조하세요.

컨테이너 레지스트리

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

사용:

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

생성

생성은 객체가 존재하지 않고 처음으로 생성될 때 사용합니다. 삭제(delete)의 반대 개념입니다.

예:

  • 이슈를 생성합니다.

추가(add)와 생성을 혼동하지 마십시오.

새로 생성을 사용하지 마십시오. 생성이라는 단어가 객체가 새로운 것이라는 것을 의미하며, 여분의 단어는 필요하지 않습니다.

현재

제품이나 해당 기능에 대해 현재를 사용하지 마십시오. 문서는 현재 제품의 상태를 설명합니다. (Vale rule: CurrentStatus.yml)

사용자 정의 역할

특정 사용자 정의 권한으로 생성된 역할을 나타낼 때 사용자 정의 역할을 사용합니다.

기본 사용자 정의 역할이 아닌 경우 기본 역할(default role)을 사용합니다.

데이터

데이터는 단수로 사용합니다.

아래를 사용하십시오:

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

다음 대신에:

  • 데이터가 수집됩니다.
  • 데이터가 수집되었습니다.

기본 역할

사용자 정의된 권한이 추가되지 않은 다음 사전 정의된 역할에 대해 기본 역할을 사용하십시오:

  • 게스트
  • 기고자
  • 개발자
  • 관리자
  • 소유자
  • 최소한의 액세스

정적 역할, 내장 역할, 또는 미리 정의된 역할을 사용하지 마십시오.

삭제

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

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

의존성 프록시

GitLab 의존성 프록시의 제목은 카멜 케이스를 사용합니다.

배포 보드

배포 보드에 대해서는 소문자를 사용하십시오.

개발자

개발자 역할에 대해 작성할 때:

  • 대문자 D를 사용합니다.
  • 굵게 표시하지 마십시오.
  • 개발자 역할을 지정된 사람을 의미하는 구문으로 개발자를 사용하지 마십시오. 예를 들어, 개발자 역할이 할당된 경우와 같이 작성합니다.
  • 최소한 개발자 역할이 필요한 상황을 설명할 때:
    • 최소한 개발자 역할
    • 대신에: 개발자 역할 또는 그 이상

개발자 권한을 사용하지 마십시오. 개발자 역할이 할당된 사용자에는 관련된 권한이 있습니다.

DevSecOps 플랫폼

GitLab 다음에 오는 경우 플랫폼을 대문자로 사용합니다. 예를 들어, GitLab DevSecOps 플랫폼.

다이얼로그

다이얼로그 대신에 다음 대안을 사용하지 마십시오:

  • 다이얼로그 상자
  • 모달
  • 모달 다이얼로그
  • 모달 창
  • 팝업
  • 팝업 창
  • 창

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

다이얼로그가 작업의 위치인 경우 전치사로 on을 사용하십시오. 예를 들어:

  • 권한 부여 다이얼로그에서 그룹을 선택합니다.

또한 on을 참조하십시오.

비활성화

비활성화에 대한 지침은 Microsoft 스타일 가이드를 참조하십시오. 대신 비활성 상태 또는 끔을 사용하십시오.

금지

금지 대신에 방지를 사용하십시오. (Vale rule: Substitutions.yml)

토론 요약

토론 요약에 대해서는 문장의 첫 문자를 대문자로 사용하십시오.

페이지에서 처음 언급할 때는 GitLab Duo 토론 요약을 사용하십시오. 그 후로는 토론 요약만 사용하십시오.

Docker-in-Docker, dind

Docker Executor를 사용하여 Docker 컨테이너를 실행하는 방법을 설명할 때 Docker-in-Docker를 사용하십시오.

dind라는 컨테이너 이름을 설명할 때 백틱 내에 dind를 사용하십시오. 그렇지 않으면 철자를 씁니다.

다운그레이드

보다 긍정적이고 정확하게 하려면 다운그레이드를 사용하지 마십시오. 대신 사용자의 동작에 중점을 두십시오.

  • 이전 GitLab 버전으로 변경하는 경우, 롤백을 사용하십시오.
  • 낮은 GitLab 티어로 변경하는 경우 구독 티어 변경을 사용하십시오.

다운로드

데이터를 사용자의 기기에 저장하는 것을 설명할 때 다운로드를 사용하십시오. 자세한 내용은 Microsoft 스타일 가이드를 참조하십시오.

내보내기와 혼동하지 마십시오.

드롭다운 디렉터리

UI 요소를 지칭할 때 드롭다운 디렉터리을 사용하십시오. drropdown 다음에 리스트를 사용하지 않습니다. 드롭다운만 사용하지 마십시오(다른 용어나 변수와 혼용되기 쉽습니다).

예를 들어:

  • 가시성 드롭다운 디렉터리에서 공개를 선택합니다.

이전

버전 번호에 대해 이전을 사용하십시오.

다음을 사용하십시오:

  • GitLab 14.1 및 이전.

이번 이야기

epic은 소문자로 씁니다.

associate도 참고하세요.

이번 이야기 보드

epic board도 소문자로 씁니다.

기타

가능한 한 구체적으로 작성하세요. 등등와 같은 용어는 피하세요.

다음과 같이 사용하세요:

  • Merge Request이나 이슈 같은 오브젝트를 업데이트할 수 있습니다.

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

  • Merge Request, 이슈 등을 업데이트할 수 있습니다.

펼치기

UI에서 섹션을 펼치거나 축소할 때 펼치기를 사용하세요.

실험

실험은 소문자로 씁니다. 예를 들어:

  • 이 기능은 실험입니다.
  • 이 실험들은 준비가 되었습니다.

실험적(Experimental)을 사용해도 됩니다.

실험적인 기능에 대해 쓸 때 이 주제에 링크하는 것이 좋습니다.

추출(export)

추출은 GitLab에서 파일을 표현하지 않는 원시 데이터를 표준 파일 형식으로 변환하는 것을 나타내기 위해 사용합니다.

출력을 변경할 수 있는 경우가 많습니다. 추출된 데이터는 필요에 따라 사용자의 기기에 다운로드되지 않습니다.

예를 들어:

보고서 내용을 CSV 형식으로 추출합니다.

다운로드와 헷갈리지 마세요.

FAQ

사용자가 정보를 빠르게 찾을 수 있게 하고자 하는데 사용자들은 거의 FAQ라는 용어를 검색하지 않습니다. FAQ에 있는 정보는 사용자가 쉽게 검색 할 수있는 주제 제목 아래에 있어야 합니다.

기능

기능이라는 용어를 드물게 사용해야 합니다. 대신 GitLab의 기능을 설명하십시오.

예를 들어:

  • Merge Request을 사용하여 대상 브랜치에 변경 사항을 통합합니다.

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

  • 변경 사항을 대상 브랜치에 통합하는 기능을 사용합니다.

기능 브랜치

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

필드

상자나 필드 대신 텍스트 상자를 사용하세요.

다음과 같이 사용하세요:

  • 변수 이름 텍스트 상자에 내 텍스트를 입력합니다.

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

  • 변수 이름 필드에 내 텍스트를 입력합니다.

그러나 작업 을 설명하고 한 번에 여러 필드를 참조해야 할 경우 예외를 둘 수 있습니다.

예를 들어:

  1. 왼쪽 사이드바에서 검색 또는 이동을 선택하여 프로젝트를 찾습니다.
  2. 설정 > CI/CD를 선택합니다.
  3. 일반적인 파이프라인을 확장합니다.
  4. 필드를 작성합니다.

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

파일 이름

파일 이름은 하나의 단어를 사용하세요. 변수로 사용할 때는 <파일이름>을 사용합니다.

(Vale 규칙: SubstitutionWarning.yml)

필터

이슈 또는 Merge Request과 같은 디렉터리을 볼 때 사용 가능한 속성으로 디렉터리을 필터링합니다. 예를 들어, 담당자 또는 리뷰어에 의해 필터링할 수 있습니다.

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

foo

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

포크

포크는 원본 프로젝트에서 포킹 프로세스를 사용하여 생성된 프로젝트입니다.

원본 프로젝트(또는 소스 프로젝트)와 포크는 포크 관계를 가지며 연결됩니다.

포크 관계가 해제되면 포크는 원본 프로젝트와 연결이 해제됩니다.

전체 화면

전체 화면은 두 단어로 사용합니다. (Vale rule: SubstitutionWarning.yml)

미래 시제

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

GB, 기가바이트

GB 와 MB에 대해서는 Microsoft 가이드를 따릅니다.

Geo

Geo는 제목을 사용합니다.

일반적으로 사용 가능함, 일반적 사용 가능성

일반적 사용 가능함과 일반적 사용 가능성에 대해 소문자를 사용합니다. 예를 들어:

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

자주 일반적 사용 가능함을 사용하십시오. 예를 들어, 다음과 같이 말하지 마십시오:

  • 이 기능은 일반적 사용 가능성에 도달했습니다.

GA를 사용하여 일반적 사용 가능성을 나타낼 수 있습니다.

Git 제안

Git 제안에서는 문장을 대문자로 시작합니다.

페이지 상에서 최초 언급 시 GitLab Duo Git 제안를 사용합니다. 그 이후로는 단순히 Git 제안을 사용합니다.

GitLab

GitLab을 소유하는 것으로 만들지 마십시오 (GitLab’s). 이 가이드는 GitLab 상표 가이드를 따릅니다.

GitLab Dedicated

GitLab Dedicated은 제품 서비스를 가리키는 데 사용합니다. GitLab이 고객을 위해 호스팅하고 관리하는 GitLab 인스턴스를 지칭합니다.

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

전용만 사용하지 마십시오. 항상 GitLab Dedicated을 사용하십시오.

GitLab Duo

Duo만 사용하지 마십시오. 항상 GitLab Duo를 사용하십시오.

페이지에서 최초 사용시 GitLab Duo <기능명>을 사용하십시오. 2023년 12월 현재 다음은 GitLab Duo 기능의 이름입니다:

  • GitLab Duo 채팅
  • GitLab Duo 코드 제안
  • GGitLab Duo 제안 리뷰어
  • GitLab Duo 가치 스트림 예측
  • GitLab Duo 토론 요약
  • GitLab Duo Merge Request 요약
  • GitLab Duo 코드 검토 요약
  • GitLab Duo 코드 설명
  • GitLab Duo 취약점 설명
  • GitLab Duo 취약점 결정
  • GitLab Duo 테스트 생성
  • GitLab Duo Git 제안
  • GitLab Duo 루트 원인 분석
  • GitLab Duo 이슈 설명 생성

최초 사용 후에는 GitLab Duo 없이 기능 이름을 사용하십시오.

GitLab Duo Pro

항상 GitLab Duo Pro를 사용하십시오. Duo Pro는 법적으로 승인되지 않는 한 사용하지 마십시오.

GitLab Duo Pro add-on을 사용할 수 있지만 사용할 수있는 경우 add-on을 사용하지 말고 생략하십시오.

GitLab Flavored Markdown

가능한 한 GitLab Flavored Markdown을 완전히 작성하십시오.

만약 약어를 사용해야하는 경우 GFM이 아닌 GLFM을 사용하지 마십시오.

GitLab Helm 차트, GitLab 차트

클라우드 네이티브 버전의 GitLab을 배포하려면:

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

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

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

다른 설치 방법을 설명할 때Helm chart (Kubernetes)를 사용합니다.

GitLab Pages

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

GitLab Runner

GitLab Runner에 대해 타이틀 케이스를 사용하십시오. 이 제품은 설치하는 제품입니다. 이 사용에 대한 결정에 대한 자세한 내용은 이 이슈를 참조하십시오.

note

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에 의해 관리되는 인스턴스입니다.

가이드

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

Guest

Guest 역할에 대해 작성할 때:

  • 대문자 G를 사용하십시오.
  • 다음과 같이 작성하십시오:
    • 사용: Guest 역할이 할당된 경우
    • 대신: 손님이 되었을 때
  • Guest 역할이 최소 필요 역할인 경우:
    • 사용: 적어도 Guest 역할
    • 대신: Guest 역할 또는 더 높은 역할

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

Guest permissions을 사용하지 마세요. Guest 역할을 할당받은 사용자에게 해당하는 권한 집합이 있습니다.

편리한

편리한이라는 용어를 사용하지 마십시오. 사용자가 기능이나 프로세스를 편리하게 여기지 않는다면, 우리는 그들의 신뢰를 잃습니다. (Vale 규칙: Simplicity.yml)

고가용성, HA

고가용성 또는 HA를 사용하지 마십시오. 사용자가 더 많은 양의 사용자를 처리하도록 GitLab을 구성하는 방법에 대한 자세한 내용은 참조 아키텍처로 안내하십시오.

여러 노드 환경을 의미하는 고가용성 설정과 같은 구문을 사용하지 마십시오. 대신 다중 노드 설치 또는 유사한 용어를 사용하십시오.

더 높은

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

다음을 사용하십시오:

  • GitLab 14.4 이상…

대신에 다음을 사용하십시오:

  • GitLab 14.4와 높은…
  • GitLab 14.4와 이상…
  • GitLab 14.4와 그 이상…

누르다

누르다를 누르다로 의미하는 용어로 사용하지 마십시오.

다음을 사용하십시오:

  • ENTER를 누르십시오.

대신에 다음을 사용하십시오:

  • ENTER 버튼을 누르십시오.

나

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

즉

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

하는데, 하기 위해서

하는데 대신 to를 사용하십시오. (Vale 규칙: Wordy.yml)

색인들

색인의 복수형에는 indexes를 사용하십시오.

그러나 Elasticsearch의 경우 indices를 사용하십시오.

소스로부터 설치

자체 컴파일 된 코드를 사용하여 설치 방법을 참조할 때 self-compiled로 참조하십시오.

다음을 사용하십시오:

  • 자체 컴파일 설치에서…

대신에 다음을 사용하십시오:

  • 소스로부터 설치에서…

자세한 정보는 여러 가지 설치 방법을 참조하십시오.

-ing 단어

가능한 한 -ing 단어를 제거하십시오. 이해하기 어려울 수 있으며 더 정확한 용어를 사용할 수 있습니다. 예를 들어:

  • 스토리지를 사용하는 파일들이 삭제됩니다 대신 스토리지를 사용하는 파일들이 삭제됩니다를 사용하십시오.
  • 편집 버튼을 사용하여 파일 삭제 대신 편집 버튼을 사용하여 파일을 삭제하십시오를 사용하십시오.
  • 서버를 복제하는 것이 필요합니다 대신 서버를 복제해야 합니다를 사용하십시오.

이슈

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

이슈 보드

이슈 보드에는 소문자를 사용하십시오.

이슈 설명 생성

이슈 설명 생성에 대해 문장 케이스를 사용하십시오.

페이지 최초 언급에서는 GitLab Duo Issue description generation를 사용하고, 이후에는 Issue description generation만 사용하십시오.

이슈 가중치

이슈 가중치에는 소문자를 사용하십시오.

IP 주소

인터넷 프로토콜(IP)에 사용되는 주소를 참조할 때 IP address를 사용하십시오. IP로 참조하지 마십시오.

it

it이라는 단어를 사용할 때 it이 무엇을 가리키는지 명확해야 합니다. 명확하지 않은 경우 it 대신 단어를 반복해서 사용하십시오.

다음을 사용하십시오:

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

대신에 다음을 사용하십시오:

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

또한 this, these, that, those를 참조하십시오.

작업

작업을 job과 동의어로 사용하지 마십시오. 작업은 .gitlab-ci.yml 파일에서 정의되며 파이프라인의 일부로 실행됩니다.

job에서 CI를 사용하려면 CI job 대신 CI/CD job를 사용하십시오.

Kubernetes executor

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

이 기능을 참조할 때 다음을 사용하십시오:

  • GitLab Runner용 Kubernetes executor
  • Kubernetes executor

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

  • GitLab Runner Kubernetes executor. 왜냐하면 이는 Kubernetes 상표권을 침해할 수 있습니다.

이후

버전 번호에 대해 이후를 사용하십시오.

다음을 사용하십시오:

  • GitLab 14.1 이상…

대신에 다음을 사용하십시오:

  • GitLab 14.1와 높은…
  • GitLab 14.1와 이상…
  • GitLab 14.1와 새로운 것…

디렉터리

디렉터리을 드롭다운 디렉터리을 참조할 때 사용하지 마십시오. 전체 구문 드롭다운 디렉터리을 사용하십시오.

라이선스

라이선스에 대해 작성할 때:

  • cloud license, offline license, 또는 legacy license와 같은 변형을 사용하지 마십시오.
  • 구독과 교차로 사용하지 마십시오:
    • 라이선스는 사용자에게 구매한 구독에 대한 액세스를 부여하며, 구매한 좌석 수 및 구독 기간과 같은 정보가 포함되어 있습니다.
    • 구독은 사용자가 구매하는 구독 티어를 의미합니다.

다음을 사용하십시오:

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

대신에 다음을 사용하십시오:

  • 라이선스 구매
  • 라이선스를 구매하다

제한 사항

제한 사항을 사용하지 마십시오. 대신 알려진 이슈를 사용하십시오.

로그인

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

  • 로그인
  • 로그온
  • login

대신 로그인을 사용하십시오.

그러나 사용자 인터페이스에 로그인이 있다면, UI에 맞추십시오.

로그인한 사용자, 인증된 사용자

“로그인한 사용자” 또는 “로그인 된 사용자” 대신 인증된 사용자를 사용합니다.

최하

버전 번호에 대해 언급할 때 최하는 사용하지 않습니다.

  • GitLab 14.1 및 그 이전 버전.

대신에:

  • GitLab 14.1 및 하위 버전.
  • GitLab 14.1 및 이전 버전.

머신 러닝

머신 러닝은 소문자로 사용합니다.

머신 러닝이 형용사로 사용될 때, 예를 들어 머신 러닝 모델과 같이 사용될 때 하이픈을 사용하지 않습니다. 하이픈이 문법적으로 더 정확할 수 있지만, 더 정확하려고 노력할 때 불일치할 위험이 있습니다.

관리자

Maintainer (관리자) 역할에 대해 작성할 때:

  • 대문자 M을 사용합니다.
  • 단어로 씁니다.
    • 사용: 당신이 관리자 역할을 할당받은 경우
    • 사용하지 않음: 유지 관리자
  • 최소한 요구되는 역할이 관리자인 경우:
    • 사용: 적어도 Maintainer 역할
    • 사용하지 않음: Maintainer 역할 또는 그 이상

굵은 글씨를 사용하지 않습니다.

관리자 권한을 사용하지 않습니다. 사용자가 관리자 역할을 할당받으면 관련 권한이 있습니다.

인류

인류를 사용하지 않습니다. 대신 people 또는 humanity을 사용합니다. (Vale 규칙: InclusionGender.yml)

인력

인력을 사용하지 않습니다. 대신 workforce 또는 GitLab 팀 멤버와 같은 단어를 사용합니다. (Vale 규칙: InclusionGender.yml)

마스터

마스터를 사용하지 않습니다. 기본 브랜치 이름의 예로 main을 사용합니다. (Vale 규칙: InclusionCultural.yml)

MIGHT, MAY

MIGHT는 어떤 일이 발생할 가능성을 가리킵니다. MIGHT는 종종 문제 해결 설명서에서 사용됩니다.

MAY는 어떤 일을 하도록 허용합니다. MAY 대신 CAN을 사용하는 것이 좋습니다.

이러한 용어를 이용한 문구를 다시 작성하는 것을 고려합니다. 이러한 용어는 종종 가능성과 의심을 나타내며, 기술 문서 작성은 정확성을 추구합니다.

예:

  • committed_date 및 authored_date 필드는 서로 다른 소스에서 생성되며 서로 동일하지 않을 수 있습니다.
  • 전형적인 파이프라인은 순서대로 실행되는 네 단계로 구성됩니다.

대신에:

  • committed_date 및 authored_date 필드는 서로 다른 소스에서 생성되며 동일하지 않을 수 있습니다.
  • 전형적인 파이프라인은 순서대로 실행되는 네 단계로 구성됩니다.

MB, 메가바이트

MB와 GB에 대해 Microsoft 가이드를 따릅니다.

구성원

사용자 계정을 그룹이나 프로젝트에 추가하면 사용자 계정은 구성원이 됩니다.

Merge Request 브랜치

Merge Request 브랜치 대신 브랜치를 참조하세요.

Merge Request

Merge Request에 대해 소문자를 사용합니다. 약어로 MR을 사용할 경우, 첫 사용 시 전체 용어로 표기합니다.

Merge Request 요약

Merge Request 요약에 대해 문장의 첫 글자를 대문자로 표기합니다.

페이지 첫 언급 시 GitLab Duo Merge Request 요약을 사용합니다. 이후엔 Merge Request 요약만 사용합니다.

마일스톤

마일스톤에 대해 소문자를 사용합니다.

최소 액세스

Minimal Access (최소 액세스) 역할에 대해 작성할 때:

  • 대문자 M과 대문자 A를 사용합니다.
  • 단어로 씁니다:
    • 사용: 최소 액세스 역할을 할당받은 경우
    • 사용하지 않음: Minimal Access 사용자
  • 최소한 요구되는 역할이 Minimal Access인 경우:
    • 사용: 적어도 최소 액세스 역할
    • 사용하지 않음: 최소 액세스 역할 또는 그 이상

굵은 글씨를 사용하지 않습니다.

최소 액세스 권한을 사용하지 않습니다. 사용자가 최소 액세스 역할을 할당받으면 관련 권한이 있습니다.

n/a, N/A, 해당 없음

가능한 경우 해당 없음을 사용합니다. 구문을 철자로 작성하면 영어를 사용하지 않는 사용자에게 도움이 되며 대문자 사용의 일괄성을 유지합니다.

탐색

탐색을 사용하지 않습니다. 이동을 대신 사용하세요. 예를 들어:

  • 이 웹페이지로 이동합니다.
  • 터미널을 열고 runner 디렉터리로 이동합니다.

(Vale 규칙: SubstitutionWarning.yml)

해야 하는

가능한 경우 해야 하는을 피합니다. 왜냐하면 단어가 많기 때문입니다.

예를 들어, 변수가 필요한 경우,

  • 변수를 설정합니다.
  • 변수를 반드시 설정합니다.

변수가 권장될 때:

  • 변수를 설정해야 합니다.

변수가 선택 사항일 때:

  • 변수를 설정할 수 있습니다.

새로운

새로운 이라는 단어를 피하는 경우가 많습니다. 객체를 만들 때 이미 새로운 것이므로 이 추가 단어가 필요하지 않습니다.

생성 및 추가도 참조하세요.

더 최근

버전 번호에 대해 더 최근을 사용하지 않습니다.

사용:

  • GitLab 14.4 및 이후…

대신에:

  • GitLab 14.4 및 그 이후…
  • GitLab 14.4 및 이상…
  • GitLab 14.4 및 더 최신…

평소, 일반적으로

평소를 평소, 전형적 또는 표준 방식으로 하는 다른 단어로 풀어쓰지 않습니다. 그 대신 해당 용어를 사용하세요.

사용:

  • 일반적으로 인증서를 지정합니다.

대신에:

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

(Vale 규칙: Normal.yml)

유의하여 주십시오

유의하여 주십시오를 사용하지 않습니다. 왜냐하면 이것은 말이 많기 때문입니다.

사용:

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

대신에:

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

제공

현재 제품 제공 항목은 다음과 같습니다:

티어 뱃지는 이러한 제공 항목을 반영합니다.

이전

버전 번호에 대해 이전을 사용하지 않습니다.

사용:

  • GitLab 14.1 및 이전 버전.

대신에:

  • GitLab 14.1 및 그 이전 버전.
  • GitLab 14.1 및 이전 버전.

Omnibus GitLab

리눅스 패키지를 사용하는 설치 방법을 말할 때, 리눅스 패키지로 참조하세요.

사용:

  • 리눅스 패키지를 사용하는 설치…

대신에:

  • Omnibus GitLab를 사용하는 설치…

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

에 따라

고수준 UI 요소를 문서화할 때 전치사로 에 따라를 사용합니다. 예를 들어:

  • 좌측 사이드바에서 설정 > CI/CD를 선택합니다.
  • 권한 부여 대화상자에서 그룹을 선택합니다.

부터나 에서를 사용하지 않습니다. 더 많은 정보는 Microsoft 스타일 가이드를 참조하세요.

한 번

단어 한 번은 한 번을 의미합니다. 이후 또는 언제를 의미하는 것으로 사용하지 마십시오.

사용법:

  • 프로세스가 완료될 때…

대신 사용법:

  • 프로세스가 완료되면…

only

only는 수정하는 단어 옆에 두십시오.

  • 당신은 개인 프로젝트만 생성할 수 있습니다.

이 예에서 only는 명사 projects를 수정합니다. 이 문장은 당신이 한 유형의 프로젝트 - 비공개 프로젝트를 만들 수 있다는 것을 의미합니다.

  • 당신은 개인 프로젝트만 만들 수 있습니다.

이 예에서 only는 동사 create를 수정합니다. 이 문장은 당신이 다른 행동을 할 수 없다는 것을 의미합니다. 예를 들어, 비공개 프로젝트를 삭제하거나 사용자를 추가할 수 없습니다.

override

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

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

overwrite

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

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

소유자(Owner)

소유자 역할을 다룰 때:

  • 대문자 O를 사용합니다.
  • 전체 단어로 쓰십시오.
    • 사용: 당신에게 소유자 역할이 할당된 경우
    • 사용 금지: 당신이 소유자인 경우

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

소유자 권한(Owner permissions)을 사용하지 마십시오. 소유자 역할이 지닌 일련의 권한이 있습니다. 소유자는 사용자가 소유할 수 있는 가장 높은 역할입니다.

패키지 레지스트리

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

사용법:

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

페이지(page)

“이슈(Issues) 페이지에”와 같은 구를 쓸 때 페이지에 어떻게 이동하는지 단계가 근처에 있어야 합니다. 그렇지 않으면 사람들이 이슈(Issues) 페이지가 무엇인지 모를 수 있습니다.

페이지 이름은 페이지 상단에 UI에서 볼드체로 표시되어야 합니다. 그렇지 않은 경우, 해당 페이지 이름을 브래드크럼에서 얻을 수 있어야 합니다.

문서는 UI의 대소문자와 일치해야 하며, 페이지 이름은 볼드체여야 합니다. 예를 들어:

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

권한

역할(roles)과 권한을 서로 바꿔서 사용하지 마십시오. 각 사용자에게는 역할이 할당됩니다. 각 역할에는 일련의 권한이 포함됩니다.

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

개인 액세스 토큰

개인 액세스 토큰에 대해 소문자를 사용하십시오.

please

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

UI 텍스트에서 사용자에게 불편을 끼친 경우에만 please를 사용하십시오. 자세한 내용은 Microsoft Style Guide을 참조하십시오.

Premium

가입 등급인 Premium을 나타낼 때 대문자 P를 사용하십시오. Premium을 다른 가입 등급과 관련한 문맥에서 언급할 때는 가입 등급 지침을 따르십시오.

환경 설정(preferences)

환경 설정(preferences)를 사용하여 테마 및 레이아웃과 같은 사용자별 시스템 수준 설정을 설명하십시오.

준비 사항(prerequisites)

사용자가 작업을 완료하기 전에 완료해야 하는 작업이나 충족해야 하는 조건을 문서화할 때 준비 사항(prerequisites)을 사용하십시오. 요구 사항(requirements)을 사용하지 마십시오.

준비 사항(prerequisites)은 항상 복수어여야 하며, 리스트에 하나의 항목만 포함되어 있더라도 말입니다.

자세한 내용은 작업 주제 유형을 참조하십시오.

튜토리얼 페이지 유형의 경우 시작하기 전에(before you begin)을 사용하십시오.

누르기

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

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

저주어

저주어를 사용하지 마십시오. 이는 다른 사용자 및 기여자에게 부정적인 영향을 끼칠 수 있으며, GitLab의 다양성, 포용성 및 소속 가치에 반하는 것입니다.

프로비저닝(provision)

클라우드 인프라 프로비저닝을 참조할 때 프로비저닝(provision) 용어를 사용하십시오. 인프라를 프로비저닝한 다음에 애플리케이션을 배포합니다.

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

  • AWS EKS 클러스터를 프로비저닝하고 애플리케이션을 배포합니다.

푸시 규칙(push rules)

푸시 규칙(push rules)에 대해 소문자를 사용하십시오.

README 파일

README 파일 또는 README.md 파일에 대해서 백틱과 소문자를 사용하십시오.

가능한 경우, 전체 구문인 README 파일을 사용하십시오.

복수형의 경우 README 파일을 사용하십시오.

권장, 우리는 권장합니다

우리는 권장합니다 대신 당신은을 사용하십시오. 우리는 사용자에게 동료처럼 말하고 차별을 피하기 위해 사용자와 우리 사이의 구분을 피하려고 합니다.

  • 당신은 변수를 설정해야 합니다. (권장됨)
  • 변수를 설정하십시오. (필수)
  • 당신은 변수를 설정할 수 있습니다. (선택사항)

등록(register)

계정을 만드는 것에 대해 이야기할 때 등록(register)을 사용하십시오.

제거(remove)

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

객체가 완전히 삭제되면 삭제(delete)를 대신 사용하십시오.

기자(Reporter)

기자 역할에 대해 작성할 때:

  • 대문자 R를 사용하십시오.
  • 전체 단어로 쓰십시오.
    • 사용: 당신이 기자 역할을 할당받은 경우
    • 사용 금지: 당신이 기자인 경우
  • 기자 역할이 필요한 최소 요건인 경우:
    • 사용: 적어도 기자 역할
    • 사용 금지: 기자 역할 또는 그 이상

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

기자 권한(Reporter permissions)을 사용하지 마십시오. 기자 역할이 지닌 일련의 권한이 있습니다.

리포지터리 미러링(Repository Mirroring)

리포지터리 미러링(Repository Mirroring)에 대해 대문자를 사용하십시오.

해결(resolution), 해결

문제 해결 솔루션이 문제를 영구적으로 해결할 때 해결(resolution)을 사용하십시오. 해결은 주로 문제를 수정하기 위해 파일 및 코드를 변경하는 것을 별로입니다. 예를 들어:

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

참조: 일시적인 해결책(workaround).

요구 사항(requirements)

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

  • 작업에는 준비 사항(prerequisites)을 사용하십시오. 자세한 내용은 작업 주제 유형을 참조하십시오.
  • 튜토리얼에는 시작하기 전에(before you begin)을 사용하십시오. 자세한 내용은 튜토리얼 페이지 유형을 참조하십시오.

요구 사항(requirements)을 사용하지 마십시오.

재설정(reset)

항목을 새로운 상태로 재설정하는 작업을 설명할 때 재설정(reset)을 사용하십시오.

각각(respectively)

respectively를 피하고 더 구체적이지 못한 표현을 대신 사용하십시오.

사용법:

  • 사용자를 생성하려면 사용자 생성(Create user)를 선택하십시오. 기존 사용자의 경우 변경 사항 저장(Save changes)을 선택하십시오.

예를 들어:

  • 새 사용자를 만드는 경우 사용자 생성(Create user)를 선택하십시오. 기존 사용자의 경우 변경 사항 저장(Save changes)을 선택하십시오.

복원(restore)

restore에 대한 안내는 Microsoft Style Guide에서 확인하십시오.

검토 앱(review app)

review app에 대해 소문자를 사용하십시오.

역할(roles)

권한(permissions)과 역할을 서로 바꿔서 사용하지 마십시오. 각 사용자에게 역할이 할당됩니다. 각 역할에는 일련의 권한이 포함됩니다.

두 가지 타입의 역할이 있습니다: 사용자 정의(custom) 및 기본(default).

역할과 접근 수준(access levels)은 동일하지 않습니다.

루트 원인 분석(Root cause analysis)

루트 원인 분석(Root cause analysis)에 대해 문장 첫 번째 언급에서 대문자 G를 사용하십시오. 이후에는 Root cause analysis만 사용하십시오.

롤백(roll back)

GitLab 버전을 이전 버전으로 변경할 때 롤백(roll back)을 사용하십시오.

구독이나 가입 등급과 관련하여 롤백을 사용하지 마십시오. 대신 가입 등급 변경(change the subscription tier)을 사용하십시오.

runner, runners

러너(runner)란 CI/CD 작업을 실행하는 에이전트입니다. 자세한 내용은 GitLab Runner 및 이 이슈를 참조하십시오.

러너(runner)에 대한 언급 시, 고객의 GitLab 인스턴스에 설치된 러너(runner)임을 명시해야 할 경우, Self-Managed를 사용하십시오. self-hosted 대신에 사용하십시오.

러너(runner)의 범위에 대해 언급할 때 다음과 같이 사용하십시오:

  • project runner: 특정 프로젝트와 관련이 있음
  • group runner: 그룹 내의 모든 프로젝트 및 서브그룹에서 사용 가능
  • instance runner: GitLab 인스턴스 내의 모든 그룹 및 프로젝트에서 사용 가능

러너 관리자, 러너 관리자들

러너 관리자는 자동 스케일링을 위해 여러 러너를 생성할 수 있는 러너의 유형입니다. 자세한 내용은 GitLab Runner를 참조하십시오.

러너 워커, 러너 워커들

러너 워커는 러너가 호스트 컴퓨팅 플랫폼에서 생성하는 프로세스로, 작업을 실행하는 데 사용됩니다. 자세한 내용은 GitLab Runner를 참조하십시오.

러너 인증 토큰

러너 인증 토큰을 다른 용어인 러너 토큰, 인증 토큰, 또는 토큰 대신 사용하십시오. 러너는 생성될 때 러너 인증 토큰이 할당되며 작업을 실행할 때 GitLab과 인증하기 위해 사용합니다.

Runner SaaS, SaaS runners

Runner SaaS 또는 SaaS runners를 사용하지 마십시오.

GitLab.com 및 GitLab Dedicated에 호스팅된 러너를 설명하는 주요 용어로 GitLab-hosted runners를 사용하십시오.

다음과 같이 제공 및 운영 체제를 지정하십시오:

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

GitLab- 접두사나 제공체 또는 운영 체제 없이 호스팅된 러너를 사용하지 마십시오.

(s)

단어를 선택적으로 복수로 만드는 데 (s)를 사용하지 마십시오. 이로 인해 이해가 늦추어질 수 있습니다. 예:

사용:

  • 원하는 작업을 선택하십시오.

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

  • 원하는 작업을 선택하십시오.

여러 가지를 선택할 수 있는 경우, 해당 단어를 복수로 작성하십시오.

상식적 검사

상식적 검사 대신 완료 여부 확인을 사용하십시오. (Vale rule: InclusionAbleism.yml)

확장성

추가 사용자를 위한 GitLab 성능 향상에 관한 확장성은 사용하지 마십시오. scale 또는 scaling은 일부 경우에 허용되지만, 추가 사용자를 위한 GitLab 성능 향상에 대한 참조는 독자를 GitLab 참조 아키텍처 페이지로 안내해야 합니다.

검색

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

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

사이트

구독 청구 모델을 지칭할 때 다음을 사용하십시오:

  • GitLab SaaS의 경우 Seats를 사용하십시오. 고객은 Seats를 구매합니다. 사용자들은 예외가 있습니다.
  • GitLab Self-Managed의 경우 users를 사용하십시오. 고객은 특정 수의 사용자를 위한 구독을 구매합니다.

섹션

섹션은 페이지 내의 영역을 설명하는 데 사용됩니다. 예를 들어 페이지에 UI를 분리하는 선이 있는 경우, 이러한 영역을 섹션이라고 합니다.

우리는 주로 펼침/접힘 가능한 영역을 섹션이라고 생각합니다. 섹션을 펼치거나 접는 것에 대해 언급할 때는 섹션이라는 단어를 포함하지 마십시오.

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

  • Auto DevOps를 펼치십시오.

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

  • Auto DevOps 섹션을 펼치지 마십시오.

선택

버튼, 링크, 메뉴 항목 및 디렉터리에 선택을 사용하십시오. 선택은 더 많은 장치에 적용되는 반면, 클릭은 마우스에 특화되어 있습니다.

Self-Managed

GitLab 설치를 나타내기 위해 Self-Managed를 사용하십시오. self-hosted를 사용하지 마십시오.

서비스 데스크

서비스 데스크에는 제목이 대문자로 사용되어야 합니다.

설치, 설치하다

명사로 설치를, 동사로 설치하다를 사용하십시오. 예를 들어:

  • 당신의 원격 사무실 설치는 놀라운데요.
  • 원격 사무실을 올바르게 설치하려면 근무 공간의 인간공학을 고려하십시오.

설치하다를 configure와 혼동하지 마십시오. 설치하다는 처음으로 무언가를 한다는 것을 의미합니다. 예를 들어:

  1. 설치를 진행하십시오.
  2. 설치를 구성하십시오.

설정

설정은 제품의 기본 동작을 변경시키는 것입니다. 설정은 일반적으로 하나 이상의 옵션을 갖는 레이블에 의해 나타낸 키/값 쌍으로 구성됩니다.

로그인

로그인 작업에 대해 기술할 때 다음을 사용하십시오:

  • 로그인.
  • 동사로 GitLab에 로그인하다를 사용하십시오. 예를 들어: 비밀번호를 사용하여 GitLab에 로그인하십시오.

다음과 같이 사용할 수도 있습니다:

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

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

만약 사용자 인터페이스에 다른 단어가 있다면, 해당 단어를 사용할 수 있습니다.

가입

계정을 생성하는 데 대해 이야기할 때 가입 대신 등록을 사용하십시오.

로그인한 사용자

로그인한 사용자나 로그인한 사용자 대신 인증된 사용자를 사용하십시오.

간편하게, 간단한

간편하게나 간단한을 사용하지 마십시오. 사용자가 프로세스를 간단하게 생각하지 못하는 경우, 신뢰를 잃을 수 있습니다. (Vale rule: Simplicity.yml)

because

because는 시간적 범위를 나타냅니다. 예를 들어, 1984년부터, Bon Jovi가 존재했습니다. because를 because로 사용하지 마십시오.

다음을 사용하십시오:

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

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

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

경로(/)

사용/사용하지 않음 대신 사용함 또는 문장을 다시 작성하십시오. 이 규칙은 CI/CD와 같은 기타 슬래시에도 적용됩니다.

동료

동료를 사용하지 마십시오. 다른 옵션으로는 보조, 보조적 등이 있습니다. (Vale rule: InclusionCultural.yml)

리포지터리

다음과 같은 맥락에서:

  • Gitaly에서는 리포지터리가 물리적이며 리포지터리라고 불러야 합니다.
  • Gitaly Cluster의 경우, 리포지터리는 다음 중 하나일 수 있습니다:
    • 가상적이며 가상 리포지터리라고 불러야 합니다.
    • 물리적이며 물리 리포지터리라고 불러야 합니다.

Gitaly 리포지터리는 물리적 경로를 갖고 있으며 가상 리포지터리는 가상 경로를 갖고 있습니다.

서브그룹

서브그룹 (하이픈 없음)을 사용하십시오. 또한 하위 그룹이나 낮은 수준 그룹과 같은 서브그룹의 대안 용어를 사용하지 마십시오.

(Vale rule: SubstitutionWarning.yml)

구독 티어

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

티어를 설명하려면:

대신에 사용
Free 티어 이상 모든 티어에서
Free 티어 이상 모든 티어에서
Premium 티어 이상 Premium 및 Ultimate 티어에서
Premium 티어 이상 Premium 및 Ultimate 티어에서
Premium 티어 이하 Free 및 Premium 티어에서

건의된 리뷰어

건의된 리뷰어에는 타이틀 케이스를 사용합니다. 페이지에서 처음 언급할 때는 GitLab Duo 건의된 리뷰어를 사용하세요.

건의된 리뷰어는 항상 복수로 사용되며, 일반적인 경우에도 대문자로 쓰입니다.

예시:

  • 건의된 리뷰어는 Merge Request을 검토할 사람을 추천할 수 있습니다. (이 구문은 기능을 설명합니다.)
  • 입력하는 대로, 건의된 리뷰어가 표시됩니다. (이 구문은 일반적이지만 대문자를 사용합니다.)

that

명사를 설명할 때 that을 사용하지 마십시오. 예를 들어:

사용:

  • 저장하는 파일…

대신에:

  • 저장하는 파일…

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

터미널

터미널에는 소문자를 사용하십시오. 예를 들어:

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

Terraform Module Registry

GitLab Terraform Module Registry에는 타이틀 케이스를 사용하지만, 특정하지 않은 모듈에 대해 이야기할 때는 m을 소문자로 사용합니다. 예를 들어:

  • 해당 프로젝트의 Terraform Module Registry에 Terraform 모듈을 게시할 수 있습니다.

테스트 생성

테스트 생성에는 문장 케이스를 사용합니다.

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

텍스트 상자

UI 요소를 참조할 때 텍스트 상자를 사용하세요.

there is, there are

there is와 there are는 피하는 것이 좋습니다. 이러한 구문은 주체를 숨기고 이해하기 어렵게 만듭니다.

다음을 사용합니다:

  • 그 통에 구멍이 있습니다.

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

  • 그 통에 구멍이 있습니다.

they

구체적인 사람을 지칭하지 않는 한, 성별 특정 대명사의 사용을 피합니다. 성별 중립적인 대명사로 단수로 they를 사용합니다.

this, these, that, those

이러한 단어 뒤에는 항상 명사가 옵니다. 예를 들어:

  • 이 설정으로 성능이 향상됩니다.

대신에:

  • 이 설정으로 성능이 향상됩니다.

  • 이 바지가 최고입니다.

대신에:

  • 이 바지가 최고입니다.

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

대신에:

  • 그 드로이드가 당신이 찾고 있는 것입니다. (또는 더 좋은 선택으로, 그 설정을 구성하세요.)

to which, of which

to which와 of which을 피하고, 대신에 전치사를 문장 끝에 둡니다. 예시는 Prepositions를 참조하세요.

할 일 항목

할 일 항목에는 소문자와 하이픈을 사용합니다. (Vale rule: ToDo.yml)

할 일 디렉터리

할 일 디렉터리에는 타이틀 케이스를 사용합니다. (Vale rule: ToDo.yml)

토글

토글은 켜기 또는 끄기합니다. 예를 들어:

  • blah 토글을 켭니다.

2FA, 이중 인증

2FA와 이중 인증을 사용합니다. (2FA와 이중 인증을 참조하세요)

타입

커서가 있는 곳에서 타입을 사용합니다. 예를 들어, 검색 상자에서 입력을 시작하고 검색 결과가 표시됩니다.

예를 들어:

  • 이름이 Alex인 모든 사용자를 보려면, Al이라고 입력합니다.
  • 문서 팀의 모든 라벨을 보려면, doc이라고 입력합니다.
  • 빠른 조치 디렉터리을 보려면, /이라고 입력합니다.

enter도 참조하세요.

Ultimate

Ultimate을 대문자로 사용하여 구독 티어를 나타냅니다. Ultimate을 다른 구독 티어와 함께 사용할 때는 구독 티어 가이드를 따릅니다.

되돌리기

되돌리기에 대한 안내는 Microsoft Style Guide를 참조하세요.

메트릭 단위

메트릭 단위 사이에는 공백을 사용합니다. 예를 들어, 128 GB. (Vale rule: Units.yml)

추가 정보는 Microsoft Style Guide를 참조하세요.

업데이트

소프트웨어의 더 높은 패치 버전을 설치할 때 업데이트를 사용합니다. 예를 들어:

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

다른 경우에는 업데이트 대신 업그레이드를 사용합니다.

업그레이드

업그레이드는 다음과 같은 경우에 사용합니다:

  • 더 높은 구독 티어(Premium 또는 Ultimate)를 선택할 때
  • 더 높은 주요(13.0) 또는 부 (13.2) 버전의 GitLab을 설치할 때.

예를 들어:

  • GitLab Ultimate로 업그레이드합니다.
  • GitLab을 14.0에서 14.1로 업그레이드합니다.
  • GitLab을 14.0에서 15.0으로 업그레이드합니다.

GitLab을 업그레이드라는 구문은 주변 텍스트가 제품 버전인지 구독 티어인지 명확히하세요.

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

왼쪽 상단, 오른쪽 상단

UI에서 방향을 제공할 때 왼쪽 상단과 오른쪽 상단을 사용합니다. UI 요소가 모서리에 없는 경우 왼쪽 위와 오른쪽 위를 사용합니다.

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

추가 정보는 Microsoft Style Guide를 참조하세요.

유용한

유용한은 사용하지 않습니다. 사용자가 프로세스를 유용하지 않다고 느끼면 신뢰를 잃게됩니다. (Vale rule: Simplicity.yml)

사용자 계정

사용자 계정을 만듭니다. 사용자 계정은 액세스 레벨을 가지고 있습니다. 그룹이나 프로젝트에 사용자 계정을 추가하면 해당 사용자 계정은 멤버로 됩니다.

사용하기

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

예를 들어:

  • 파일에서 저장중인 파일…

대신에:

  • 파일에서 저장중인 파일…

  • 명령줄을 사용하여 디렉터리를 변경합니다.
  • 명령줄을 사용하여 디렉터리를 변경합니다. 또는 더 좋은 것으로, 디렉터리를 변경하려면 명령줄을 사용합니다.

활용

utilize 대신 use를 사용하십시오. 이것은 더 간결하고 비영어권 사용자들에게 더 쉽게 이해할 수 있습니다. (참고: Vale 규칙)

Value stream forecasting

Value stream forecasting에 대해 문장의 첫 글자는 소문자로 쓰십시오. 페이지 상에서 처음 언급할 때에는 GitLab Duo Value stream forecasting를 사용하세요.

이후에는 Value stream forecasting만 사용하십시오.

버전

GitLab의 버전을 설명할 때는 GitLab <version number>을 사용하십시오. 예를 들어:

  • GitLab 16.0 이상이 필요합니다.

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

  • Kubernetes 1.4에서는…

v 다음의 문자 사이의 간격에 유의하십시오. Semantic versioning에서는 v 다음에 간격이 존재하지 않습니다. 예를 들어:

  • v1.2.3

통해

라틴어 약어를 사용하지 마십시오. 대신 with, through, 또는 by using을 사용하십시오. (참고: Vale 규칙)

취약점 해결

Vulnerability resolution에 대해 문장의 첫 글자는 소문자로 쓰십시오.

페이지 상에서 처음 언급할 때에는 GitLab Duo Vulnerability resolution를 사용하십시오. 그 이후에는 Vulnerability resolution을 사용하십시오.

취약점 설명

Vulnerability explanation에 대해 문장의 첫 글자는 소문자로 쓰십시오.

페이지 상에서 처음 언급할 때에는 GitLab Duo Vulnerability explanation를 사용하십시오. 그 이후에는 Vulnerability explanation을 사용하십시오.

우리

가능한한 we 대신에 사용자가 GitLab에서 어떻게 무언가를 수행할 수 있는지에 중점을 두세요.

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

  • 작업을 정리하고 싶을 때 위젯을 사용하십시오.

다음과 같은 방식으로 사용하지 마십시오:

  • 우리는 위젯을 추가할 수 있는 기능을 생성했습니다.

workaround

문제 해결 방법이 일시적인 수정일 때 workaround를 사용하십시오. 일시적인 수정이며 지속적인 문제가 발생할 수 있습니다. 예를 들어:

  • 해결책은 일시적으로 템플릿을 폐기된 버전에 고정하는 것입니다.

resolution도 참조하십시오.

while

while을 시간에 따라 발생하는 것으로만 참조할 때에 사용하십시오. 예를 들어, 프로세스가 실행되는 동안 창을 열어두세요.

while을 비교에 사용하지 마십시오. 예를 들어, 다음과 같이 사용하십시오.

  • 작업 1은 빠르게 실행될 수 있습니다. 그러나, 작업 2는 더 정교합니다.

다음과 같은 방식으로 사용하지 마십시오.

  • 작업 1은 빠르게 실행될 수 있지만, 작업 2는 더 정교합니다.

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

whilst

whilst를 사용하지 마십시오. 대신 while을 사용하십시오. While이 더 간결하고 비영어권 사용자들에게 이해하기 쉽습니다.

익명 디렉터리

whitelist를 사용하지 마십시오. allowlist를 대안으로 사용하십시오. (참고: Vale 규칙)

아직

제품이나 그 기능에 관해 아직을 사용하지 마십시오. 문서는 현재 제품을 설명합니다.

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

미래 기능에 대해 쓰는 방법에 관한 지침을 참조하십시오.

you, your, yours

the user, the administrator 또는 the customer 대신에 you를 사용하십시오. 문서는 제품을 설치, 구성, 관리 또는 사용하는 사용자에게 직접적으로 이야기해야 합니다.

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

  • 파이프라인을 구성할 수 있습니다.
  • 사용자의 비밀번호를 재설정할 수 있습니다. (관리자용 콘텐츠인 경우)

다음과 같은 방식으로 사용하지 마십시오:

  • 사용자들은 파이프라인을 구성할 수 있습니다.
  • 관리자들은 사용자의 비밀번호를 재설정할 수 있습니다.