권장 단어 목록

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

이 페이지에 없는 경우, 다음 스타일 가이드를 참조합니다:

.gitlab-ci.yml 파일

.gitlab-ci.yml 파일은 역따옴표와 소문자로 사용하세요.

가능한 경우 전체 구문 “the .gitlab-ci.yml file“을 사용하세요.

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

&

라틴어 약어를 사용하지 마십시오. &를 사용하는 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를 참조할 때 이러한 단어를 대문자화합니다. 그 외에는 소문자를 사용하세요.

관리자 영역

관리자 영역에 대해 제목 케이스를 사용하세요. UI에서는 제목 케이스를 사용합니다.

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

관리자 모드

관리자 모드에 대해 제목 케이스를 사용하세요. UI에서는 제목 케이스를 사용합니다.

관리자

사용자의 액세스 레벨을 언급할 때 관리자 액세스를 사용하세요.

관리자 액세스 레벨

관리자는 역할이나 권한이 아닙니다.

사용하세요: - 이 작업을 하려면 관리자여야 합니다. - 이 작업을 하려면 관리자 액세스가 필요합니다.

대신에: - 이 작업을 하려면 관리자 역할이 필요합니다.

고급 검색

전체 GitLab 인스턴스에서 빠르고 효율적인 검색을 위해 고급 검색을 사용하세요.

에이전트

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

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

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

에이전트 액세스 토큰

Kubernetes용 에이전트를 생성할 때 생성된 토큰을 사용합니다. 에이전트 액세스 토큰을 사용하십시오. 다음과 같은 것을 사용하지 마십시오: - 등록 토큰 - 비밀 토큰 - 인증 토큰

AI, 인공 지능

AI를 사용하세요. 인공 지능을 철자로 표기하지 마십시오.

AI 기반 DevSecOps 플랫폼

GitLab에 앞서 나오는 경우 Platform을 대문자로 사용합니다. 예를 들면, GitLab AI 기반 DevSecOps Platform.

공중 상업, 오프라인 환경

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

  • 오프라인 환경에서 방화벽 정책은 컴퓨터가 인터넷에 액세스하지 못하도록 합니다.

허용, 가능하게 하다

보안 관련 기능에 대해 이외에는 허용 및 가능하게 하다 를 피하십시오.

사용:

  • 저장소에 파일을 추가할 수 있습니다.

다음 대신 사용:

  • 이 기능을 사용하여 저장소에 파일을 추가할 수 있습니다.
  • 이 기능을 통해 사용자는 저장소에 파일을 추가할 수 있습니다.

이 표현은 보다 더 활동적이며 개발자 관점 대신 사용자 관점에서 기술하고 있습니다. 자세한 정보는 Microsoft Style Guide를 참조하십시오.

분석

분석 및 이와 관련된 표현에는 소문자를 사용하십시오. 예를들어 병합 요청 분석과 이슈 분석입니다. 그러나 UI에 대문자를 사용하는 경우 문서도 UI에 맞추어 작성하십시오.

예시:

  • 프로젝트에 대한 병합 요청 분석을 확인할 수 있습니다. 병합 요청 분석 대시보드에 표시됩니다.

그리고/또는

그리고/또는 대신 또는 를 사용하거나 둘 다의 옵션을 명시하는데 더 나은 표현으로 문장을 재작성하십시오.

등 및 기타

등 및 기타를 사용하지 마십시오. 보다 구체적으로 명시하십시오. 자세한 정보는 Microsoft Style Guide를 참조하십시오.

구역

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

왜냐하면

왜냐하면이 이유를 의미하는 용도로 사용하지 마십시오.

사용:

  • 엔드포인트 중 어떠한 것도 ID를 반환하지 않기 때문에…

다음 대신 사용:

  • 어떠한 엔드포인트도 ID를 반환하지 않기 때문에…

그리고 또한

그리고 또한 대신에 그리고를 사용하십시오.

연관시키다

이슈를 에픽에 추가하거나 사용자를 이슈, 병합 요청 또는 에픽에 지정하는데 연관시키다를 사용하지 마십시오.

대신 할당하다를 사용하십시오. 예를들어:

  • 이슈를 에픽에 지정하세요.
  • 사용자를 이슈에 지정하세요.

인증된 사용자

다른 변형인 로그인한 사용자 또는 인증된 사용자 대신 인증된 사용자를 사용하십시오.

시작하기 전에

튜토리얼을 완료하기 전에 완료해야 할 작업이나 충족해야 할 조건을 문서화할 때 시작하기 전에를 사용하십시오. 요구 사항이나 전제 조건을 사용하지 마십시오.

자세한 정보는 the tutorial page type를 참조하십시오.

작업 주제 유형을 위해 필수 조건을 사용하십시오.

아래

문서 페이지에서 예제 또는 테이블을 참조할 때 아래는 피하십시오. 필요한 경우 다음을 대신 사용하십시오. 예를들어:

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

Beta

Beta에는 대문자를 사용하십시오. 예를들어: XYZ 기능은 Beta 상태입니다. 또는 이 Beta 릴리즈는 테스트할 준비가 되어있습니다.

Beta 기능에 대해 작성할 때마다 이 주제에 링크를 걸어두실 수도 있습니다.

차단 목록

블랙리스트를 사용하지 마십시오. 다른 옵션은 거부 목록입니다. (Vale 규칙: InclusionCultural.yml)

보드

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

상자

UI 필드를 참조할 때 텍스트 상자를 사용하십시오. 필드나 박스를 사용하지 마십시오. 예를들어:

  • 변수 이름 텍스트 상자에 값을 입력하십시오.

브랜치

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

  • 기본 브랜치: 저장소의 주요 브랜치입니다. 사용자는 UI를 사용하여 기본 브랜치를 설정할 수 있습니다. 기본 브랜치를 사용한 예시에는 master 대신에 main을 사용하십시오.
  • 소스 브랜치: 병합 대상에서 가져온 브랜치입니다.
  • 대상 브랜치: 병합하려는 브랜치입니다.
  • 현재 브랜치: 체크아웃한 브랜치입니다. 이 브랜치는 기본 브랜치일 수도 있고, 사용자가 만들거나 병합할 대상의 브랜치일 수도 있습니다.

기능 브랜치나 병합 요청 브랜치와 같은 용어를 사용하지 마십시오. 가능한 구체적으로 명시하십시오. 예를들어:

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

글머리 기호

주문되지 않은 목록이나 순서가 있는 목록의 각 항목을 글머리 기호로 지칭하지 마십시오. 대신 목록 항목을 사용하십시오. 좀더 애매하지 않도록 하는데 필요한 경우 다음을 사용할 수 있습니다:

  • 순서가 있는 목록의 항목은 순서가 있는 목록 항목
  • 주문되지 않은 목록의 항목은 주문되지 않은 목록 항목

버튼

버튼에 대해 설명할 때 부연설명을 사용하지 마십시오.

사용:

  • 파이프라인 실행을 선택하십시오.

다음 대신 사용:

  • 파이프라인 실행 버튼을 선택하십시오.

할 수 없다

할 수 없다 대신 할 수 없습니다를 사용하십시오.

더 읽어보기: contractions

채팅, GitLab Duo 채팅

채팅은 Chat 또는 GitLab Duo Chat로 표기합니다.

페이지 내 첫 번째 사용 시에는 GitLab Duo Chat를 사용합니다. 이후에는 채팅(Chat)을 사용합니다.

체크박스

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

체크박스는 선택하고(check 또는 enable이 아님) 해제합니다(deselect 또는 disable가 아님). 예시:

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

체크박스를 참조해야 할 경우, 선택되었거나 해제되었다고 말할 수 있습니다. 예를 들어:

  • Protect environment 체크박스가 해제되어 있는지 확인하세요.
  • Protect environment 체크박스가 선택되어 있는지 확인하세요.

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

checkout, check out

check out을 동사로 사용합니다. Git 명령어의 경우 checkout을 사용합니다.

  • 로컬에서 브랜치를 check out 하려면 git checkout을 사용합니다.
  • 편집하려는 파일을 check out합니다.

CI, CD

GitLab 기능에 대해 언급할 때, CI/CD를 사용합니다. CI 또는 CD만 사용하지 않습니다.

CI/CD

CI/CD는 항상 대문자로 표기합니다. 첫 사용 시에 이니셜을 풀어 쓰는 것은 필요하지 않습니다.

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

  • 코드를 CI/CD 파이프라인에서 테스트합니다. 파이프라인을 머지 요청에 대해 실행하도록 설정합니다.
  • 값을 CI/CD 변수에 저장합니다. 변수를 마스킹 처리합니다.

CI/CD 분

CI/CD 분을 사용하지 않습니다. 이 용어는 연산 분으로 변경되었습니다.

클릭

클릭을 사용하지 않습니다. 대신 버튼, 링크, 메뉴 항목 및 목록을 선택합니다.

선택은 더 많은 장치에 적용되는 반면, 클릭은 마우스에 더 구체적으로 적용됩니다.

클라우드 네이티브

GitLab을 호스트하는 데 Kubernetes 클러스터를 사용하는 경우 클라우드 네이티브 버전의 GitLab에 대해 언급할 때 사용합니다. 이 버전은 GitLab을 배포하는 더 크고 단단한 리눅스 패키지와는 다릅니다.

짧게 클라우드 네이티브 GitLab을 사용할 수도 있습니다. 이 용어는 하이픈을 사용하고 소문자로 작성되어야 합니다.

코드 설명

코드 설명에 대해 문장의 첫 글자만 대문자로 사용합니다.

페이지 내 첫 번째 언급 시에는 GitLab Duo 코드 설명을 사용합니다. 이후에는 코드 설명을 사용합니다.

코드 검토 요약

코드 검토 요약에 대해 문장의 첫 글자만 대문자로 사용합니다.

페이지 내 첫 번째 언급 시에는 GitLab Duo 코드 검토 요약을 사용합니다. 이후에는 코드 검토 요약을 사용합니다.

코드 제안

코드 제안에 대해 Title Case를 사용합니다. 페이지 내 첫 번째 언급 시에는 GitLab Duo 코드 제안을 사용합니다.

코드 제안은 항상 복수로 사용되며, 일반적인 경우에도 대문자로 표기됩니다.

예시:

  • 타이핑하는 동안 코드 제언을 사용하여 제안을 표시합니다. (이 구문은 기능을 설명합니다.)
  • 타이핑하는 동안 코드 제언이 표시됩니다. (본 구문은 일반적이지만 대문자를 사용합니다.)

축소

UI에서 섹션을 확장하거나 축소하는 경우 축소를 사용합니다. 닫기보다 축소를 사용합니다.

명령 줄

명령어를 소개할 때 명령 줄에서를 사용합니다.

형용사로 사용할 때에는 하이픈을 사용합니다. 예를 들어 명령줄 도구.

연산

CI/CD 작업을 실행하는 러너가 사용하는 자원에 대해 연산을 사용합니다.

관련 용어:

  • 연산 분: 연산 사용량이 어떻게 계산되는지에 대한 정보입니다. 예를 들어, 400 연산 분.
  • 연산 할당량: 네임스페이스가 매달 사용할 수 있는 연산 분의 한계입니다.
  • 연산 사용량: 네임스페이스가 매달 할당량에서 사용한 연산 분의 수입니다.

연산 분

다음 용어(또는 유사한 용어) 대신 연산 분을 사용합니다:

  • CI/CD 분
  • CI 분
  • 파이프라인 분
  • CI 파이프라인 분
  • 파이프라인 분

자세한 내용은 epic 2150을 참조하십시오.

구성

여러 설정의 모음을 업데이트할 때, 구성이라고 합니다.

구성

기능이나 제품이 설정된 후에 구성합니다. 예를 들어:

  1. 설치를 설정합니다.
  2. 설치를 구성합니다.

확인 대화상자

작업을 확인하도록 요청하는 대화상자를 확인 대화상자라고 설명합니다. 예를 들어:

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

확인 상자 또는 확인 대화상자 상자는 사용하지 않습니다. 또한 대화상자를 참조하십시오.

컨테이너 레지스트리

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

사용 예시:

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

custom role

특정 맞춤 권한으로 생성된 역할을 참조할 때 custom role을 사용하십시오.

맞춤 역할이 아닌 경우 default role을 사용하십시오.

데이터

data는 단수 명사로 사용하십시오.

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

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

다음과 같은 대신 사용하지 마십시오:

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

기본 역할

다음과 같이 맞춤 권한이 추가되지 않은 미리 정의된 역할을 참조할 때 default role을 사용하십시오:

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

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

삭제

객체가 완전히 삭제되면 delete를 사용하십시오. delete는 create의 반대입니다.

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

의존성 프록시

GitLab 의존성 프록시에는 제목 형식을 사용하십시오.

배포 보드

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

Developer

개발자 역할에 관한 글을 쓸 때 다음을 준수하십시오:

  • 대문자 D 사용
  • 볼드체를 사용하지 마십시오.
  • 개발자 역할을 가진 사람을 의미하는 구절로 if you are a developer를 사용하지 마십시오. 대신, 전체 문장을 작성하십시오. 예를 들어, if you are assigned the Developer role.
  • 개발자 역할이 최소 요구 사항인 상황을 설명할 때:
    • 다음을 사용하십시오: 최소한 개발자 역할
    • 다음을 사용하지 마십시오: 개발자 역할 또는 더 높은 역할

Developer permissions를 사용하지 마십시오. 개발자 역할이 할당된 사용자는 관련 권한 세트를 갖습니다.

DevSecOps 플랫폼

GitLab이 선행되면 플랫폼을 대문자로 쓰십시오. 예를 들어, GitLab DevSecOps 플랫폼.

대화상자

대화상자를 다음과 같은 대안 대신 사용하십시오:

  • 대화 상자
  • 모달
  • 모달 대화상자
  • 모달 창
  • 팝업
  • 팝업 창
  • 윈도우

대화상자가 동작의 위치인 경우 전치사로 on을 사용하십시오. 예를 들어:

  • 권한 부여 대화상자에서 그룹을 선택하십시오.

비활성화

비활성화에 대한 안내를 위해 Microsoft Style Guide를 참조하십시오. 비활성화 대신 inactive 또는 off를 사용하십시오.

거부

거부 대신 prevent를 사용하십시오. (Vale 규칙: Substitutions.yml)

토론 요약

토론 요약에는 문장 케이스를 사용하십시오.

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

Docker-in-Docker, dind

도커 실행기를 사용하여 도커 컨테이너를 실행하는 경우 Docker-in-Docker를 사용하십시오.

컨테이너 이름을 설명할 때 백틱 안에 dind를 사용하십시오: docker:dind. 그 외의 경우는 철자를 기입하십시오.

다운그레이드

보다 낙관적이고 정확하게 표현하기 위해 다운그레이드 대신 사용자가 취하는 조치에 집중하십시오.

  • GitLab 버전을 변경하는 경우 roll back을 사용하십시오.
  • GitLab 티어를 낮추는 경우 후원 티어 변경을 사용하십시오.

다운로드

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

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

드롭다운 목록

UI 요소를 참조할 때 드롭다운 목록을 사용하십시오. 드롭다운 뒤에 목록을 붙이지 않습니다. 드롭다운 (하이픈으로 구분된), 드롭다운 메뉴 또는 기타 변형을 사용하지 마십시오.

예를 들어:

  • 가시성 드롭다운 목록에서 공개를 선택하십시오.

이전

버전 번호에 대해 언급할 때 이전을 사용합니다.

사용:

  • GitLab 14.1 및 이전.

대신에 사용되지 않는 말:

  • GitLab 14.1 이하
  • GitLab 14.1과 이전.

쉽게

쉽게라는 표현을 사용하지 마십시오. 사용자가 프로세스를 쉽다고 느끼지 않을 경우, 우리는 사용자의 신뢰를 잃을 수 있습니다.

예시

라틴어 약어를 사용하지 마십시오. 예를 들어, 와 같은, 예와 같이를 대신 사용하십시오. (Vale 규칙: LatinTerms.yml)

생략 부호

UI 텍스트를 문서화할 때, UI에 생략 부호가 포함되어 있으면 문서에는 생략 부호를 포함시키지 않습니다. 더 많은 정보는 Microsoft Style Guide를 참조하십시오.

사용:

  • 새로 만들기

대신에 사용되지 않는 말:

  • 새로 만들기…

이메일

하이픈으로 구분된 이메일을 사용하지 마십시오. 복수일 때, 이메일 또는 이메일 메시지를 사용하십시오. (Vale 규칙: SubstitutionWarning.yml)

이메일 주소

이메일 주소에 대한 언급 시 이메일 주소를 사용하십시오. 메시지가 있는 이메일로 줄여쓰지 마십시오.

이모지

이모지의 복수형으로 이모지를 사용하십시오.

활성화

활성화에 대한 지침은 Microsoft Style Guide를 참조하십시오. 활성화 대신 활성 또는 켜기를 사용하십시오.

입력

대부분의 경우 입력 대신 입력을 사용하십시오.

  • 입력은 음성 및 키보드를 포함한 여러 방법으로 정보를 입력하는 것을 포괄합니다.
  • 입력은 사용자가 값을 필드에 입력한 다음 커서를 필드 바깥으로 이동시키거나 (Enter 키를 누르거나) 한다고 가정합니다. 입력은 콘텐츠를 입력하는 것과 해당 콘텐츠를 검증하는 동작을 둘 다 포함합니다.

예시:

  • 변수 이름 텍스트 상자에 값을 입력하십시오.
  • 변수 이름 텍스트 상자에 내 텍스트를 입력하십시오.

키보드의 키를 참조할 때 입력을 사용하고 싶을 경우 HTML <kbd> 태그를 사용하십시오:

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

또한 입력을 참조하십시오.

이픽

이픽에 대해 소문자를 사용하십시오.

associate도 참조하십시오.

이픽 보드

이픽 보드에 대해 소문자를 사용하십시오.

등

등등(등)을 피하려고 노력하십시오. 가능한 한 구체적으로 작성하십시오. 등등(등)을 대체어로 사용하지 마십시오.

사용:

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

대신에 사용되지 않는 말:

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

확장

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

실험

실험에 대해 대문자를 사용하십시오. 예를 들면 XYZ 기능은 실험입니다. 또는 이 실험이 테스트 준비가 됐습니다..

실험 기능에 대해 글을 쓸 때 이 주제를 참조할 수도 있습니다.

내보내기

GitLab에서 파일로 표현되지 않는 원시 데이터를 표준 파일 형식으로 변환하는 것을 나타내기 위해 내보내기를 사용하십시오.

자주 다음과 같은 이유로 내보내기와 다운로드를 구분할 수 있습니다:

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

예를 들면:

  • 보고서 내용을 CSV 형식으로 내보내기하십시오.

다운로드와 혼동하지 마십시오.

FAQ

사용자가 정보를 신속하게 찾을 수 있기를 원하며, 그들은 거의 결국 FAQ 용어를 검색하지 않습니다. FAQ에 있는 정보들은 다른 유사한 정보와 함께, 쉽게 검색 가능한 주제 제목 아래에 있어야 합니다.

기능

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

예를 들어 사용:

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

대신에 사용되지 않는 말:

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

기능 브랜치

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

필드

상자 또는 필드 대신 텍스트 상자를 사용하십시오.

사용:

  • 변수 이름 텍스트 상자에 값을 입력하십시오.

대신에 사용되지 않는 말:

  • 변수 이름 필드에 값을 입력하십시오.

그러나 작업을 기술하고 한꺼번에 모든 필드를 언급해야 하는 경우에는 예외를 두십시오. 예를 들어:

  1. 왼쪽 사이드바에서 검색 또는 이동을 선택하고 프로젝트를 찾습니다.
  2. Settings > CI/CD를 선택하십시오.
  3. 일반 파이프라인을 확장하십시오.
  4. 필드를 완료하십시오.

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

파일이름

파일이름에 대해 한 단어를 사용합니다. 변수로서 filename을 사용할 때 <filename>을 사용하십시오.

(Vale 규칙: SubstitutionWarning.yml)

필터

문제나 병합 요청과 같은 항목 목록을 보고 있을 때, 사용 가능한 속성으로 목록을 필터링합니다. 예를 들어, 담당자나 검토자별로 필터링할 수 있습니다.

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

foo

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

포크

포크는 상위 프로젝트에서 포킹 프로세스를 사용하여 만든 프로젝트입니다.

상위 프로젝트(또는 소스 프로젝트로도 알려짐)와 포크는 포크 관계를 갖고 있으며 연결되어 있습니다.

포크 관계가 제거되면 포크는 상위 프로젝트에서 연결 해제됩니다.

전체 화면

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

미래 시제

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

GB, gigabytes

GB와 MB는 Microsoft의 지침을 따릅니다.

Geo

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

Git 제안

Git 제안에는 문장 케이스를 사용하십시오.

페이지에서 처음으로 언급할 때 GitLab Duo Git 제안을 사용합니다. 이후로는 그냥 Git 제안을 사용하십시오.

GitLab

GitLab을 소유격으로 만들지 마십시오 (GitLab’s). 이 지침은 GitLab 상표 가이드라인을 따릅니다.

GitLab 전용

GitLab 전용 을 제품 제공을 언급하는 데 사용하십시오. 이것은 GitLab이 고객을 위해 호스팅하고 관리하는 GitLab 인스턴스를 가리킵니다.

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

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

GitLab Duo

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

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

  • GitLab Duo 채팅
  • GitLab Duo 코드 제안
  • GitLab Duo 제안된 검토자
  • GitLab Duo 가치 스트림 예측
  • GitLab Duo 토론 요약
  • GitLab Duo 병합 요청 요약
  • 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 Chart, 또는 클라우드 네이티브 차트를 사용하지 마십시오.

Kubernetes 클러스터에 클라우드 네이티브 GitLab을 배포하기 위해 GitLab Helm 차트를 사용하십시오.

만약 다양한 설치 방법을 설명하는 맥락에서 사용한다면 Helm chart (Kubernetes)를 사용하십시오.

GitLab Pages

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

그러나 페이지나 UI에서 GitLab Pages를 처음 언급할 경우, 그 이후로는 Pages를 사용할 수 있습니다.

GitLab Runner

GitLab Runner에는 타이틀 케이스를 사용하세요. 이 제품을 설치합니다. 이 사용법에 대한 자세한 정보는 이 이슈를 참조하세요.

참고:

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에서 페이지 제목에 가이드를 사용하지 마십시오. 예를 들어, Snowplow Guide 대신 기능 자체와 해당 기능을 사용하는 방법에 대해 이야기하세요. 예를 들어, Snowplow를 사용하여 xyz 수행하기.

Guest

Guest 역할에 대해 작성할 때:

  • 대문자 G를 사용하세요.
  • 다음과 같이 작성하세요:
    • 사용: Guest 역할이 할당된 경우
    • 대신: 손님이실 경우
  • Guest 역할이 최소 필요한 역할인 경우:
    • 사용: 최소한 Guest 역할
    • 대신: Guest 역할 또는 그 이상

굵은 글씨를 사용하지 마십시오.

Guest 권한을 사용하지 마십시오. Guest 역할이 할당된 사용자에게는 연관된 권한 집합이 있습니다.

편리한

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

고가용성, HA

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

여러 노드 환경을 의미하는 것으로 고가용성 설정과 같은 구문을 사용하지 마십시오. 대신 멀티-노드 설정 또는 유사한 용어를 사용하세요.

상위

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

다음을 사용하세요:

  • GitLab 14.4 이후…

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

  • GitLab 14.4 이상…
  • GitLab 14.4 버전 이상…

눌러

눌러가 누르다를 의미하는 것으로 사용되지 않도록 주의하세요.

다음을 사용하세요:

  • ENTER를 눌러주세요.

다음 대신에:

  • ENTER 버튼을 눌러주세요.

I

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

즉

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

-할 목적으로

할 목적으로를 사용하지 마십시오. 대신 to를 사용하세요. (Vale 규칙: Wordy.yml)

indexes, indices

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

그러나 Elasticsearch의 경우 indices를 사용하세요.

소스에서 설치

자체 컴파일된 코드를 사용한 설치 방법을 나타낼 때 self-compiled로 참조하세요.

다음을 사용하세요:

  • 자체 컴파일된 설치…

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

  • 소스에서의 설치…

자세한 정보는 다양한 설치 방법을 참조하세요.

-ing로 끝나는 단어

가능한 한 -ing로 끝나는 단어를 제거하세요. 번역하기 어려울 수 있으며 보다 정확한 용어가 일반적으로 있습니다. 예를 들어:

  • The files using storage are deleted 대신 The files that use storage are deleted를 사용하세요.
  • Delete files using the Edit button 대신 Use the Edit button to delete files를 사용하세요.
  • Replicating your server is required 대신 You must replicate your server를 사용하세요. 
## 이슈

**이슈**에 대해 소문자를 사용하세요.

## 이슈 보드

**이슈 보드**에 대해 소문자를 사용하세요.

## GitLab Duo 이슈 설명 생성

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

## 이슈 가중치

**이슈 가중치**에 대해 소문자를 사용하세요.

## IP 주소

인터넷 프로토콜(IP)과 관련된 주소를 가리킬 때 **IP 주소**를 사용하세요. **IP**로 표현하지 마세요.

## 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](#this-these-that-those)도 참조해주세요.

## 작업

**작업**과 **빌드**를 동의어로 사용하지 마세요. 작업은 `.gitlab-ci.yml` 파일에 정의되며, 파이프라인의 일부로 실행됩니다.

**CI**와 함께 **작업**을 사용하려면 **CI/CD 작업** 대신 **CI 작업**을 사용하세요.

## 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 및 새로운 것...

## 목록

**목록**을 [드롭다운 목록](#dropdown-list)을 지칭할 때 사용하지 마세요. **드롭다운 목록**이라는 표현을 사용하세요.

## 라이선스

라이선스에 관한 내용을 작성할 때 다음을 사용하지 마세요:
- **클라우드 라이선스**, **오프라인 라이선스**, **레거시 라이선스**와 같은 변형 사용하지 마세요.
- **구독**과 교환 용어로 사용하지 마세요:
  - 라이선스는 사용자가 구매한 구독에 대한 액세스를 부여하며, 구매한 좌석 수 및 구독 기간과 같은 정보가 포함되어 있습니다.
  - 구독은 사용자가 구매하는 구독 계층입니다.

다음을 사용하세요:
- 인스턴스에 라이선스 추가하기.
- 구독 구매하기.

다음을 사용하지 마세요:
- 라이선스 구입하기.
- 라이선스를 구매하기.

## 제한 사항

**제한 사항** 대신 **알려진 문제**를 사용하세요.

## 로그인, 로그온

다음을 사용하지 마세요:
- **로그인**.
- **로그온**.
- **login**

대신 [로그인](#sign-in-sign-in)을 사용해주세요.

그러나, 사용자 인터페이스에 **로그인**이 표시된 경우 인터페이스와 일치시켜야 합니다.

## 로그인한 사용자

**로그인한 사용자** 대신 **인증된 사용자**를 사용하세요.

## 낮은

버전 번호에 대해 **낮은**을 사용하지 마세요.

다음을 사용하세요:
- GitLab 14.1 및 이전.

다음을 사용하지 마세요:
- GitLab 14.1 및 낮은 수.
- GitLab 14.1 및 이전 것.

…

“이점” (FREE ALL BETA)

“이점” (FREE ALL BETA)

MB, 메가바이트

MB 및 GB를 사용할 때는 Microsoft 안내에 따르십시오.

사용자 계정

그룹이나 프로젝트에 사용자 계정을 추가하면 사용자 계정이 멤버가 됩니다.

병합 요청 브랜치

병합 요청 브랜치를 사용하지 마십시오. 브랜치를 참조하십시오.

병합 요청

병합 요청를 소문자로 사용하십시오. 약어로 MR을 사용하는 경우, 첫 번째 사용 시 전체 용어를 쓰십시오.

병합 요청 요약

병합 요청 요약을 문장 중간에 사용하십시오.

페이지의 첫 언급에서는 GitLab Duo 병합 요청 요약을 사용하십시오. 그 후에는 병합 요청 요약만 사용하십시오.

마일스톤

마일스톤을 소문자로 사용하십시오.

최소한의 액세스

최소한의 액세스 역할에 대해 작성할 때:

  • 대문자 M과 대문자 A를 사용하십시오.
  • 전체 용어를 쓰십시오:
    • 할당된 최소한의 액세스 역할을 사용하는 경우
    • 최소한의 액세스 사용자라는 대신
  • 최소한의 액세스 역할이 최소 요구되는 역할인 경우:
    • 최소한의 액세스 역할 이상으로
    • 최소한의 액세스 역할 또는 그 이상으로 대신 사용하십시오.

굵은 글꼴을 사용하지 마십시오.

최소한의 액세스 권한을 사용하지 마십시오. 최소한의 액세스 역할이 할당된 사용자에게 해당 권한 집합이 있습니다.

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

가능하면 해당 없음을 사용하십시오. 이 구문을 철자로 써 주십시오. 이로써 영어를 모국어로 하는 사용자들에게 도움이 되며 대문자로 표시되는 불일치를 피할 수 있습니다.

탐색

탐색을 사용하지 마십시오. 대신 이동을 사용하십시오. 예를 들면:

  • 이 웹페이지로 이동하십시오.
  • 터미널을 열고 runner 디렉터리로 이동하십시오.

(Vale 규칙: SubstitutionWarning.yml)

필요로 하는

가능한 한 필요로 하는을 피하십시오. 이 긴급합니다. 라는 변형 대신에:

  • 변수가 필요한 경우
  • 변수를 설정해야 합니다.

변수가 권장되는 경우:

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

변수가 선택 사항인 경우:

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

더 최근

버전 번호에 관해 더 최근을 사용하지 마십시오.

다음을 사용하십시오:

  • GitLab 14.4 이후…

대신에:

  • GitLab 14.4 이상…
  • GitLab 14.4 이상…
  • GitLab 14.4 이상…

표준, 표준적으로

보통의, 일반적인 또는 표준적인 방법으로 무엇인가를 말하는데 표준을 사용하지 마십시오. 대신 해당 용어를 사용하십시오.

다음을 사용하십시오:

  • 일반적으로, 인증서를 지정합니다.
  • 보통, 인증서를 지정합니다.
  • 표준 Git 작업을 따르십시오.

대신에:

  • 보통, 인증서를 지정합니다.
  • 표준 Git 작업을 따르십시오.

(Vale 규칙: Normal.yml)

주목해 주십시오

주목해 주십시오를 사용하지 마십시오. 이 긴급합니다. 라는 변형 대신에:

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

대신에:

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

오퍼링

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

티어 뱃지는 이러한 오퍼링을 반영합니다.

이전 버전

버전 번호에 관해 이전 버전을 사용하지 마십시오.

다음을 사용하십시오:

  • GitLab 14.1과 그 이전 버전에서

대신에:

  • GitLab 14.1 이하…
  • GitLab 14.1 이전…
  • GitLab 14.1 이상…

Omnibus GitLab

리눅스 패키지를 사용하는 설치 방법을 언급할 때는 리눅스 패키지로 언급하십시오.

다음을 사용하십시오:

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

대신에:

  • Omnibus GitLab을 사용하는 설치에서…

자세한 정보는 다양한 설치 방법을 참조하십시오.

on

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

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

from이나 in을 사용하지 마십시오. 더 많은 정보는 Microsoft 스타일 가이드를 참조하세요.

once

once라는 단어는 한 번을 의미합니다. after나 when을 의미하는 것으로 사용하지 마십시오.

사용:

  • 과정이 완료되면…

대신에:

  • 한 번 과정이 완료되면…

only

only라는 단어를 수정하는 단어 바로 옆에 두세요.

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

이 예시에서 only는 명사인 projects를 수정합니다. 이 문장은 당신이 한 유형의 프로젝트, 즉 비공개 프로젝트를 생성할 수 있다는 것을 의미합니다.

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

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

override

override를 사용하여 일시적인 대체를 나타냅니다.

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

overwrite

overwrite를 사용하여 영구적인 대체를 나타냅니다.

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

Owner

소유자 역할에 대해 쓸 때:

  • 대문자 O를 사용합니다.
  • 전체로 씁니다.
    • 사용: if you are assigned the Owner role
    • 대신에: if you are an owner

굵게 쓰지 마십시오.

Owner permissions를 사용하지 마십시오. 소유자 역할을 할당받은 사용자는 관련 권한 집합을 가지고 있습니다. 소유자는 사용자가 가질 수 있는 가장 높은 역할입니다.

package registry

GitLab 패키지 레지스트리 기능 및 기능을 문서화할 때 소문자를 사용합니다.

사용:

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

page

“이슈” 페이지와 같은 구문을 쓸 때, 페이지에 도달하는 방법을 가까이에 넣으십시오. 그렇지 않으면 사람들은 이슈 페이지가 무엇인지 모를지도 모릅니다.

페이지 이름은 페이지 상단의 UI에 표시되어야 합니다. 그렇지 않으면 breadcrumb에서 이름을 얻을 수 있어야 합니다.

문서는 UI의 케이스와 일치해야 하며, 페이지 이름은 굵게 표시되어야 합니다. 예:

  • 테스트 케이스 페이지에서…

permissions

roles와 permissions을 서로 바꿔 쓰지 마십시오. 각 사용자에게는 역할이 할당됩니다. 각 역할은 권한 집합을 포함합니다.

권한은 access levels과 동일하지 않습니다.

personal access token

personal access token을 소문자로 사용하십시오.

please

제품 문서에서는 please를 사용하지 마십시오.

UI 텍스트에서는 사용자에게 불편을 끼친 경우에 please를 사용하십시오. 더 많은 정보는 Microsoft 스타일 가이드를 참조하세요.

Premium

구독 티어로 Premium을 대문자로 사용하십시오. 다른 구독 티어 관련에서 Premium을 참조할 때는 the subscription tier 지침을 따르십시오.

preferences

사용자별, 시스템 레벨의 테마 및 레이아웃과 같은 설정을 서술할 때 preferences를 사용하십시오.

prerequisites

작업을 완료하기 전에 완료해야 할 작업이나 충족해야 할 조건을 문서화할 때 prerequisites를 사용하십시오. requirements를 사용하지 마십시오.

Prerequisites는 항상 복수로 쓰여야 하며, 항목 목록에 한 가지 항목만 포함되어 있더라도 그렇습니다.

더 많은 정보는 the task topic type를 참조하세요.

튜토리얼 페이지 유형에 대해서는 before you begin을 사용하십시오.

press

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

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

profanity

욕설을 사용하지 마십시오. 이로 인해 다른 사용자 및 기여자에 부정적인 영향을 미칠 수 있으며, 이는 GitLab의 다양성, 포용 및 소속감 가치에 반하는 것입니다.

provision

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

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

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

push rules

push rules는 소문자로 사용하십시오.

README file

README file 또는 README.md file에 대해 역따옴표와 소문자를 사용하십시오.

가능한 경우 완전한 구문 the README file을 사용하십시오.

복수형에는 README files를 사용하십시오.

추천, 권장

우리는 권장합니다 대신에 해야 합니다를 사용하세요. 사용자와 동료에게 하는 말처럼 사용자와 대화하는 것이 목적이며 우리와 그들과의 차이를 피하려 합니다.

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

등록

계정 생성에 대해 말할 때 등록 대신에 가입을 사용하세요.

삭제

물체가 계속 존재할 때 삭제를 사용하세요. 예를 들어, 이슈를 Epic에서 삭제할 수 있지만, 이슈는 여전히 존재합니다.

물체가 완전히 삭제될 때는 삭제를 사용하세요.

기자

기자 역할을 다룰 때:

  • 대문자 R을 사용하세요.
  • 설명할 때는 주어진 명사로 써주세요.
    • 사용: 기자 역할이 할당된 경우
    • 사용 금지: 리포터인 경우
  • 기자 역할이 최소 요구 역할일 때:
    • 사용: 최소한 기자 역할
    • 사용 금지: 기자 역할 또는 그 이상

굵은 글씨를 사용하지 마세요.

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

저장소 미러링

저장소 미러링에 대해서는 제목 케이스를 사용하세요.

해결, 해결책

문제 해결 솔루션이 문제를 영구적으로 해결할 때 해결을 사용하세요. 일반적으로 문제를 해결하는 데는 파일 및 코드 변경이 포함됩니다. 예:

  • 이 문제를 해결하려면 .gitlab-ci.yml 파일을 업데이트하세요.
  • 해결 방법 중 하나는 .gitlab-ci.yml 파일을 업데이트하는 것입니다.

회피도 참조하세요.

요구사항

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

  • 작업에는 prerequisites를 사용하세요. 자세한 내용은 작업 주제 유형을 참조하세요.
  • 자습서의 경우 시작하기 전에를 사용하세요. 자세한 내용은 자습서 페이지 유형을 참조하세요.

요구사항을 사용하지 마세요.

재설정

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

각각, 각자

각각을 피하고 더 정확하게 대체하세요.

사용:

  • 사용자를 만들려면 사용자 만들기를 선택하세요. 기존 사용자의 경우 변경 사항 저장을 선택하세요.

다음과 같이 쓰지 마세요: - 사용자 만들기 또는 변경 사항 저장을 선택하세요. 사용자를 만들었거나 편집했을 경우 각각.

복원

복원에 관한 안내는 Microsoft 스타일 가이드를 참조하세요.

리뷰 앱

리뷰 앱에 소문자를 사용하세요.

역할

역할과 권한을 서로 바꾸지 마세요. 각 사용자에게는 역할이 할당되어 있으며, 각 역할에는 일련의 권한이 포함되어 있습니다.

사용자 지정과 기본 두 종류의 역할이 있습니다.

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

루트 원인 분석

루트 원인 분석에 대해 문장 케이스를 사용하세요.

페이지에서 처음 언급할 때는 GitLab Duo 루트 원인 분석을 사용하세요. 그 이후부터는 루트 원인 분석만 사용하세요.

롤백

GitLab 버전을 이전 버전으로 변경할 때 롤백을 사용하세요.

롤백을 라이선스 또는 구독에는 사용하지 마세요. 대신 구독 티어 변경을 사용하세요.

러너, 러너

러너에는 소문자를 사용하세요. 이는 CI/CD 작업을 실행하는 에이전트입니다. GitLab 러너 및 이 이슈도 참조하세요.

러너에 관한 언급 시, 러너가 고객의 GitLab 인스턴스에 설치되어 있다는 점을 명시해야 한다면 self-managed 대신 self-hosted를 사용하세요.

러너의 범위에 대한 언급 시:

  • 프로젝트 러너: 특정 프로젝트와 관련이 있습니다.
  • 그룹 러너: 그룹 내 모든 프로젝트와 하위 그룹에서 사용할 수 있습니다.
  • 인스턴스 러너: GitLab 인스턴스에 속한 모든 그룹 및 프로젝트에서 사용할 수 있습니다.

러너 매니저, 러너 매니저

러너 매니저에는 소문자를 사용하세요. 이는 자동 스케일링을 위해 여러 러너를 만들 수 있는 러너의 한 유형입니다. GitLab 러너도 참조하세요.

러너 워커, 러너 워커

러너 워커에는 소문자를 사용하세요. 이는 호스트 컴퓨팅 플랫폼에서 러너가 생성한 작업을 실행하는 프로세스입니다. GitLab 러너도 참조하세요.

러너 인증 토큰

러너 인증 토큰을 사용하세요. 러너 토큰, 인증 토큰, 또는 토큰과 같은 변형어를 사용하지 마세요. 러너가 작업을 실행할 때 생성되고 GitLab과 인증하기 위해 러너에게 러너 인증 토큰이 할당됩니다.

(들)

단어를 복수형으로 만들기 위해 (들)을 사용하지 마세요. 이는 이해를 늦출 수 있습니다. 예를 들어:

사용:

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

다음과 같이 쓰지 마세요:

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

정상 여부 확인

정상 여부 확인 대신에 완전성 확인 사용. (Vale rule: InclusionAbleism.yml)

확장성

추가 사용자를 위한 GitLab 성능 향상에 대해 확장성 사용 금지. 단어 scale 또는 scaling은 일부 경우 허용되지만, 추가 사용자를 위한 GitLab 성능 향상에 대한 참조는 독자를 GitLab 참조 아키텍처 페이지로 안내해야 함.

검색

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

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

할당 자리

구독 요금 체계를 언급할 때:

  • GitLab SaaS의 경우 할당 자리(seats) 사용. 고객은 자리를 구매합니다. 사용자는 그룹으로 초대될 때 자리를 차지합니다, 일부 예외가 있습니다.
  • GitLab self-managed의 경우 사용자(users) 사용. 고객은 지정된 수의 사용자에 대한 구독을 구매합니다.

섹션

페이지의 영역을 설명할 때 섹션 사용. 예를 들어, 페이지에 UI를 분리하는 선이 있는 경우, 이러한 영역은 섹션으로 참조합니다.

우리는 종종 확장 가능한/축소 가능한 영역을 섹션으로 생각합니다. 확장/축소하는 것을 설명할 때 섹션이라는 단어를 포함하지 마세요.

사용:

  • Auto DevOps 확장.

사용 안 함: - Auto DevOps 섹션을 확장하지 마세요.

선택

버튼, 링크, 메뉴 항목 및 목록에 선택 사용. 선택은 더 많은 장치에 적용되는 반면, 클릭은 마우스에 더 구체적입니다.

셀프매니지드

고객의 GitLab 설치를 참조할 때 셀프매니지드 사용. 셀프호스팅 사용 금지.

서비스 데스크

서비스 데스크에 대해 타이틀 케이스 사용.

설정, 설정하기

명사로 설정 사용, 동사로 설정하기 사용. 예를 들어:

  • 당신의 원격 사무실 설정은 놀라운 것입니다.
  • 원격 사무실을 올바로 설정하려면 작업 영역의 인간공학을 고려하세요.

설정와 헷갈리지 마세요. 설정은 처음으로 무언가를 한다는 것을 의미합니다. 예를 들어:

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

설정

설정은 제품의 기본 동작을 변경합니다. 설정은 주로 옵션 하나 이상의 레이블로 표현되는 키/값 쌍으로 구성됩니다.

로그인, 로그인하기

로그인 작업을 설명할 때 다음을 사용:

  • 로그인.
  • 동사로 GitLab에 로그인하기 사용. 예를 들어: GitLab에 로그인하려면 비밀번호를 사용하세요.

또한 사용 가능한 것:

  • 명사 또는 형용사로 로그인 사용. 예를 들어: 로그인 페이지 또는 로그인 제한.
  • 단일 로그인 (SSO).

다음을 사용하지 마세요:

인터페이스에 다른 단어가 있는 경우 그것을 사용할 수 있습니다.

등록

계정을 생성하는 것을 설명할 때 등록 사용.

인증된 사용자

로그인한 사용자 대신 인증된 사용자 사용.

간단하게, 간단한

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

~부터

~부터는 시간표를 나타내며 예를 들어, 1984년부터 본 조비가 존재하고 있습니다. ~부터를 ~이므로로 사용하지 마십시오.

사용:

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

대신 사용 안 함:

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

기울기

슬래시(/) 대신 또는 또는 문장을 다시 쓰세요. 이 규칙은 CI/CD와 같은 다른 슬래시에도 적용됩니다.

종속

종속 사용 금지. 다른 옵션은 보조입니다. (Vale rule: InclusionCultural.yml)

저장소

다음과 같은 맥락에서:

  • Gitaly, 저장소는 물리적이고 저장소라고 해야 합니다.
  • Gitaly Cluster, 저장소는 다음 중 하나입니다:
    • 가상이며 가상 저장소라고 해야 합니다.
    • 물리적이며 물리적 저장소라고 해야 합니다.

Gitaly 저장소에는 물리적인 경로가 있고 가상 저장소에는 가상 경로가 있습니다. 

## 하위 그룹

**하위 그룹**(하이픈 없음)을 사용하십시오. 또한 **하위 그룹**에 대한 대체 용어인 **하위 그룹**이나 **낮은 수준 그룹**을 피하십시오.

([Vale](../testing/vale.md) rule: [`SubstitutionWarning.yml`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/doc/.vale/gitlab/SubstitutionWarning.yml))

## 가입 구독 티어

**구독** 또는 **가입 구독 티어**를 **[라이선스](#license)**와 혼동하지 마십시오. 사용자는 **구독**을 구매합니다. 그 구독에는 **티어**가 있습니다.

티어를 설명할 때:

| 대신에                           | 사용                                 |
|---------------------------------|--------------------------------------|
| 무료 티어나 그 이상              | 모든 티어                            |
| 무료 티어나 그 이상              | 모든 티어                            |
| 프리미엄 티어나 그 이상           | 프리미엄 및 얼티밋 티어              |
| 프리미엄 티어나 그 이상           | 프리미엄 및 얼티밋 티어              |
| 프리미엄 티어나 그 이하           | 무료 및 프리미엄 티어                |

## 제안된 리뷰어

**제안된 리뷰어**에 대문자를 사용하십시오. 페이지에서 처음 언급할 때는 **GitLab Duo 제안된 리뷰어**를 사용하십시오.

**제안된 리뷰어**는 항상 복수형이어야 하며, 일반적이더라도 대문자를 사용합니다.

예시:

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

## 그

명사를 설명할 때 **그**를 사용하지 마십시오. 예를 들면:

사용하세요:

- 저장하는 파일...

다음 대신 사용하지 마십시오:

- 저장하는 파일 **that**...

이것도 참조하십시오 [this, these, that, those](#this-these-that-those).

## 터미널

**터미널**을 소문자로 사용하십시오. 예를 들어:

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

## Terraform Module Registry

GitLab Terraform Module Registry에 대문자를 사용하되, 특정하지 않은 모듈에 대해서는 `m`을 소문자로 사용하십시오. 예를 들어:

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

## 테스트 생성

**테스트 생성**에는 문장의 첫 글자를 대문자로 사용하십시오.

페이지에서 처음 언급할 때 **GitLab Duo 테스트 생성**을 사용하고, 이후로는 **테스트 생성**만 사용하십시오.

## 텍스트 상자

UI 요소를 참조할 때 **필드**나 **상자** 대신 **텍스트 상자**를 사용하십시오.

## 있다, 있다

**있다**와 **있다**를 피하십시오. 이 구문은 주체를 감춥니다.

사용하세요:

- 양동이에 구멍이 있습니다.

다음 대신 사용하지 마십시오:

- 양동이에 구멍이 있습니다.

## 그들

특정한 사람을 참조하지 않는 한, 성별 특정 대명사 사용을 피하십시오.
중성적인 대명사로 **그들**을 사용하십시오.

## 이, 이러한, 그, 그러한

이러한 단어 뒤에는 항상 명사를 사용하십시오. 예를 들어:

- **이 설정**은 성능을 향상시킵니다. 
- 이 대신에: **이**는 성능을 향상시킵니다.

- **이 바지**가 가장 좋습니다.
- 이 대신에: **이러한**이 가장 좋습니다.

- **그 드로이드**가 당신이 찾는 것입니다. 
- 그 대신에: **그**가 당신이 찾는 것입니다.

- **그 설정**을 구성해야 합니다. (또는 더 좋은 표현, **그 설정을 구성하세요.**)
- 그 대신에: **그러한**을 구성해야 합니다.

## 어디로, 어떤 것으로

**어디로**와 **어떤 것으로**는 피하고, 전치사는 문장의 끝에 놔두십시오.
예시는 [Prepositions](index.md#prepositions)을 참조하십시오.

## 할 일 항목

**할 일** 항목에는 소문자와 하이픈을 사용하십시오.

## 할 일 목록

**할 일 목록**에는 대문자를 사용하십시오.

## 토글

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

- **다람쥐** 토글을 켜십시오.

## TFA, 2단계 인증

[**2FA**와 **2단계 인증**](#2fa-two-factor-authentication)을 사용하십시오.

## 타입

커서가 자리에 있을 때 **타입**을 사용하십시오. 예를 들어,
검색 상자에서 시작하고 검색 결과가 나타납니다. 검색 상자를 클릭하지 않습니다.

예를 들어:

- 'Al'을 입력하여 이름이 Alex인 모든 사용자 보기.
- 명명 설정팀의 모든 라벨을 查看하려면 `doc`를 입력하십시오.
- 퀵 작업 목록은 `/`를 입력하십시오.

더 알아보기 [**입력**](#enter).

Above is the translation that adheres to the specific translation and formatting rules provided.

얼티메이트

얼티메이트는 구독 티어를 나타낼 때 대문자로 사용합니다. 다른 구독 티어와 관련하여 얼티메이트를 언급할 때는 구독 티어 지침을 따릅니다.

undo

undo에 대한 안내는 Microsoft Style Guide를 참조하세요.

측정 단위

숫자와 측정 단위 사이에는 공백을 사용합니다. 예를 들어, 128 GB입니다. (Vale 규칙: Units.yml)

자세한 정보는 Microsoft Style Guide를 참조하세요.

업데이트

업데이트는 소프트웨어의 최신 패치 버전을 설치할 때에만 사용합니다. 예를 들어,

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

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

업그레이드

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

  • 보다 높은 구독 티어(프리미엄 또는 얼티메이트)를 선택하는 경우
  • GitLab의 보다 최신 주 버전(13.0) 또는 부 버전(13.2)을 설치하는 경우

예를 들어,

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

Upgrade GitLab이라는 구문을 사용할 때는 주변 텍스트가 제품 버전인지 구독 티어인지 명확히합니다.

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

좌측 상단, 우측 상단

UI에서 방향을 제시하는 데는 좌측 상단 모서리 및 우측 상단 모서리를 사용합니다. UI 요소가 모서리에 없는 경우에는 좌측 상단 및 우측 상단을 사용합니다.

최상단 왼쪽 및 최상단 오른쪽을 사용하지 마십시오.

자세한 정보는 Microsoft Style Guide를 참조하세요.

유용함

유용함을 사용하지 마십시오. 사용자가 프로세스를 유용하지 않게 느끼면 사용자의 신뢰를 잃게 됩니다. (Vale 규칙: Simplicity.yml)

사용자 계정

사용자 계정을 만듭니다. 사용자 계정에는 액세스 수준이 있습니다. 사용자 계정을 그룹이나 프로젝트에 추가하면 회원이 됩니다.

사용

대부분의 경우 사용을 피하십시오. 주어를 숨기고 구문을 번역하기 어렵게 만듭니다. 사용 대신 사용하여, 사용하는 것, 또는 문장을 다시 작성하세요.

예:

  • 변경 파일을 저장소를 사용하는…

  • 저장소 사용하는 변경 파일…

  • 명령줄을 사용하여 디렉터리 변경.
  • 명령줄을 사용하여 디렉터리 변경. 또는 더 좋은 표현: 디렉터리를 변경하려면 명령줄을 사용하세요.

활용

활용 대신 사용을 사용하십시오. 더 간결하며 영어가 원어민이 아닌 사람들에게 더 쉽게 이해할 수 있습니다. (Vale 규칙: SubstitutionWarning.yml)

가치 스트림 예상

가치 스트림 예상에는 문장의 첫 글자를 대문자로 사용합니다. 페이지에서 처음 언급할 때는 GitLab Duo 가치 스트림 예상을 사용합니다.

그 후에는 가치 스트림 예상만 사용합니다.

통해

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

취약성 해결

취약성 해결에는 문장의 첫 글자를 대문자로 사용합니다.

페이지에서 처음 언급할 때는 GitLab Duo 취약성 해결을 사용합니다. 그 후에는 취약성 해결만 사용합니다.

취약성 설명

취약성 설명에는 문장의 첫 글자를 대문자로 사용합니다.

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

우리

우리를 피하고 대신 사용자가 GitLab에서 무엇을 수행할 수 있는지에 중점을 두세요.

다음을 사용하세요:

  • 워크플로우를 구성할 작업이 있는 경우 위젯을 사용하십시오.

다음을 사용하지 마세요:

  • 우리는 당신이 위젯을 추가할 수 있는 기능을 만들었습니다.

해결방법

일시적인 수정이 해결책인 경우 해결방법을 사용합니다. 해결방법은 일반적으로 즉시 해결책이며 계속된 문제가 있을 수 있습니다. 예를 들어:

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

해상도도 참조하세요.

while

시간이 지나는 동안에만 어떤 일이 발생하는 경우에만 while을 사용합니다. 예를 들어, 프로세스가 실행되는 동안 창을 열어 두세요.

비교를 위해서 while을 사용하지 마세요. 예를 들어 다음과 같이 사용하세요:

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

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

  • 작업 1이 빠르게 실행될 수 있는 동안, 작업 2는 더 정확합니다.

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

whilst

whilst 대신 while을 사용하세요. while은 더 간결하고 비영어권 사용자에게 더 이해하기 쉽습니다.

whitelist

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

yet

제품 또는 해당 기능에 대해 yet을 사용하지 마세요. 문서에서는 제품을 현재의 상태대로 설명합니다.

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

미래 기능에 대해 작성하는 방법에 대한 지침 보기.

you, your, yours

사용자, 관리자, 또는 고객 대신 you을 사용하세요. 설명서는 제품을 설치, 구성, 관리 또는 사용하는 사람에게 직접적으로 말해야 합니다.

다음과 같이 사용하세요:

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

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

  • 사용자는 파이프라인을 구성할 수 있습니다.
  • 관리자는 사용자의 암호를 재설정할 수 있습니다.

you can

가능한 경우, you can 대신에 능동적인 동사로 문장을 시작하세요. 예를 들어:

  • 코드 검토 분석을 사용하여 병합 요청 데이터를 보세요.
  • 팀 작업을 조직하기 위해 보드를 작성하세요.
  • 푸시를 제한하기 위해 변수를 구성하세요.
  • Skype와 Twitter와 같은 외부 계정 링크를 추가하세요.

you can는 선택적인 작업에 사용하세요. 예를 들어:

  • 코드 검토 분석을 사용하여 병합 요청별 지표를 보세요. 또한 API를 사용할 수 있습니다.
  • 이름과 값 쌍을 입력하세요. 스트리밍 대상 당 최대 20개의 쌍을 추가할 수 있습니다.