권장 단어 디렉터리

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

이 링크에 없는 가이드라인은 다음 스타일 가이드를 참조하세요:

.gitlab-ci.yml 파일

.gitlab-ci.yml 파일에 대해 역따옴표와 소문자를 사용하세요.

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

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

&

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

@mention

@mention을 피하려고 노력하세요. mention을 대신 사용하고 mentions topic에 링크를 추가하세요. 백틱을 사용하지 마십시오.

2FA, two-factor authentication

첫 사용 시 문장 케이스로 two-factor authentication를 철자로 표기하고 주제 제목에도 그대로 사용한 후에는 2FA로 표기하세요. 문장의 첫 단어일 때는 factor 또는 authentication를 대문자로 쓰지 마십니다. 예:

  • Two-factor authentication (2FA)는 귀하의 계정을 안전하게 보호하는 데 도움이 됩니다. 처음 로그인할 때 2FA를 설정하세요.

위

문서 페이지에서 예제나 표를 가리킬 때 above를 사용하는 것을 피하십시오. 필요한 경우 previous 대신 사용하세요. 예:

  • 이전 예시에서 개는 벼룩이 묻었습니다.

제품 버전을 가리킬 때 above 대신에 later를 사용하세요.

사용법:

  • GitLab 14.4 이상…

다음 대신 사용하세요:

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

액세스 레벨

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

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

Admin Area

Admin Area에 대해 타이틀 케이스를 사용하세요. UI는 타이틀 케이스를 사용합니다.

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

Admin Mode

Admin Mode에 대해 타이틀 케이스를 사용하세요. UI는 타이틀 케이스를 사용합니다.

administrator

사용자의 액세스 레벨에 대해 이야기할 때 admin 대신 administrator access를 사용하세요.

admin access level

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

사용법:

  • 이 작업을 수행하려면 관리자여야 합니다.
  • 이 작업을 수행하려면 관리자 액세스가 필요합니다.

다음 대신 사용하세요:

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

전체 GitLab 인스턴스 전체에 대한 빠르고 효율적인 검색을 가리키기 위해 advanced search에 소문자를 사용하세요.

agent

Kubernetes를 위한 GitLab 에이전트를 가리키는 경우 소문자를 사용하세요. 예:

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

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

agent access token

Kubernetes를 위한 에이전트를 작성할 때 생성되는 토큰입니다. registration token, secret token, authentication token 대신 agent access token을 사용하세요.

AI, artificial intelligence

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

AI-powered DevSecOps platform

GitLab 뒤에 따라오는 경우 대문자로 Platform을 사용하세요. 예: GitLab AI-powered DevSecOps Platform.

air gap, air-gapped

물리적 장벽 또는 보안 정책으로 인해 인터넷 액세스가 제한되거나 방지되는 설치를 설명하기 위해 offline environment를 사용하세요. air gap, air gapped, 또는 air-gapped을 사용하지 마십시오. 예:

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

allow, enable

보안 관련 기능에 관한 경우를 제외하고 allow와 enable을 피하세요.

사용법:

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

다음 대신 사용하세요:

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

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

analytics

analytics 및 그 변형에 대해 소문자를 사용하세요. 그러나 UI의 대문자가 다른 경우 문서도 UI와 일치하도록하세요.

예를 들어:

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

and/or

and/or 대신에 or를 사용하거나 두 가지 옵션을 모두 명시하는 문장으로 다시 작성하세요.

and so on

and so on은 사용하지 마십시오. 더 구체적으로 작성하세요. 자세한 내용은 Microsoft 스타일 가이드를 참조하세요.

섹션

영역 대신 section을 사용하십시오. 시스템 관리 영역을 제외한 모든 경우입니다.

because

as 대신 because를 사용하십시오.

  • 아이디를 반환하는 엔드포인트가 없기 때문에…

대신:

  • 아이디를 반환하는 엔드포인트가 없기 때문에…

및

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

연결하다

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

예:

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

authenticated user

authenticated user를 사용하십시오. signed in user 또는 logged in user와 같은 다른 용어는 사용하지 마십시오.

시작하기 전에

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

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

작업 주제 유형의 경우 prerequisites를 사용하십시오.

아래

문서 페이지에서 예제 또는 표를 참조할 때 below 사용을 피하십시오. 필요한 경우 following을 사용하십시오.

예를 들어:

  • 다음 예에서 개는 벼룩을 가지고 있습니다.

Beta

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

베타 기능에 대한 설명 시 이 주제를 링크하는 것이 좋습니다.

denylist

blacklist를 사용하지 마십시오. 다른 옵션은 denylist입니다.

보드

boards, 이슈 보드, 에픽 보드에 대해서는 소문자를 사용하십시오.

박스

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

예를 들어:

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

브랜치

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

  • default branch: 리포지터리의 기본 브랜치. 사용자는 UI를 사용하여 기본 브랜치를 설정할 수 있습니다. 기본 브랜치를 사용하는 예제에는 master 대신 main을 사용하십시오.
  • source branch: Merge하려는 소스 브랜치.
  • target branch: Merge하려는 대상 브랜치.
  • current branch: 현재 확인한 브랜치. 현재 브랜치는 기본 브랜치, 당신이 만든 브랜치, 소스 브랜치 또는 다른 브랜치가 될 수 있습니다.

feature branch나 merge request branch와 같은 용어는 사용하지 마십시오. 되도록 구체적으로 작성하십시오.

예를 들어:

  • 확인한 브랜치…
  • 커밋을 추가한 브랜치…

리스트 항목

순서가 지정된 디렉터리이나 순서가 지정되지 않은 디렉터리의 개별 항목을 bullets로 참조하지 마십시오. 대신 list item을 사용하십시오. 덜 모호하게 할 필요가 있다면 다음과 같이 사용할 수 있습니다:

  • 순서가 지정된 디렉터리의 항목에 대해서는 Ordered list item을 사용하십시오.
  • 순서가 지정되지 않은 디렉터리의 항목에 대해서는 Unordered list item을 사용하십시오.

버튼

button에 설명자를 사용하지 마십시오.

다음을 사용하십시오:

  • Run pipelines를 선택합니다.

대신:

  • Run pipelines 버튼을 선택합니다.

cannot

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

약어도 참조하십시오.

채팅, GitLab Duo 채팅

채팅을 사용할 때 C를 대문자로 사용하십시오. GitLab Duo 채팅에 대해서는 처음 언급할 때 사용하고, 그 이후로 채팅만 사용하십시오.

체크박스

checkbox에는 하나의 단어를 사용하십시오. check box를 사용하지 마십시오.

체크박스를 select (체크)하고 clear (해제)합니다.

예를 들어:

  • 환경 보호 체크박스를 선택합니다.
  • 환경 보호 체크박스를 해제합니다.

체크박스를 선택했음을 나타내려면 selected, 해제했음을 나타내려면 cleared라고 말할 수 있습니다.

(deselect의 경우 Vale 규칙: SubstitutionWarning.yml에 따라 사용)

check out

동사로서 check out을 사용하십시오. Git 명령어의 경우 checkout을 사용하십시오.

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

CI/CD

GitLab 기능에 언급될 때 CI/CD를 사용하십시오. CI나 CD만 사용하지 마십시오.

CI/CD

CI/CD는 항상 대문자로 작성하십시오. 첫 사용 시 풀어쓸 필요가 없습니다.

특히 처음 사용 후에는 CI/CD를 생략할 수 있습니다.

예를 들어:

  • 코드를 CI/CD 파이프라인에서 테스트합니다. 파이프라인을 통해 CI/CD를 동작하도록 구성합니다.
  • 값을 CI/CD 변수에 저장합니다. 변수를 마스킹 처리합니다.

CI/CD 분

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

select

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

클라우드 네이티브

GitLab을 호스팅하는 Kubernetes 클러스터에 대해 언급할 때 cloud-native version of GitLab을 사용하십시오. 이 버전은 GitLab을 배포하는 더 크고 단일화된 Linux package와는 다릅니다.

cloud-native GitLab으로 줄여서 사용할 수도 있습니다. 하이픈(-)으로 구분하고 소문자로 작성해야 합니다.

코드 설명

Code explanation에 대해서는 문장 유효를 사용하십시오.

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

코드 검토 요약

페이지에서 처음 언급할 때는 GitLab Duo 코드 검토 요약을 사용합니다. 이후로는 코드 검토 요약만 사용합니다.

코드 제안

코드 제안에는 항상 복수형을 사용하며, 제네릭하더라도 대문자로 표기됩니다.

예시:

  • 타이핑하는 동안 코드 제안을 표시합니다. (이 문구는 기능을 설명합니다.)
  • 타이핑하는 동안 코드 제안이 표시됩니다. (이 문구는 제네릭하지만 대문자로 표기됩니다.)

접기

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

명령줄

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

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

컴퓨트

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

관련 용어:

  • compute minutes: compute 사용량이 계산되는 방식입니다. 예를 들어, 400 compute minutes.
  • compute quota: 네임스페이스가 매달 사용할 수 있는 compute minutes의 제한입니다.
  • compute 사용량: 네임스페이스가 월간 할당량에서 사용한 compute minutes의 수입니다.

컴퓨트 분

다음 용어들과 유사한 용어인 경우 compute minutes를 사용합니다:

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

자세한 정보는 epic 2150을 참조하십시오.

구성

일련의 설정을 업데이트하는 경우 구성이라고 표현합니다.

구성

기능이나 제품을 set up한 후 구성을 사용합니다.

예:

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

확인 대화상자

확인 동작을 확인하도록 요청하는 대화상자는 확인 대화상자를 사용합니다. 예:

  • 확인 대화상자에서 확인을 선택하십시오.

확인 상자 또는 확인 대화상자 상자를 사용하지 마십시오. 또한 대화창도 참조하십시오.

컨테이너 레지스트리

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

사용:

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

다운로드

다운로드는 사용자의 기기에 데이터를 저장하는 것을 설명할 때 사용합니다. 자세한 내용은 마이크로소프트 스타일 가이드를 참조하세요.

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

드롭다운 디렉터리

UI 요소를 나타내는 데 드롭다운 디렉터리을 사용하세요. 디렉터리 없이 드롭다운만 사용하지 마세요. 하이픈(-)으로 나눠진 드롭-다운, 드롭다운 메뉴 또는 다른 변형은 사용하지 마세요.

예시:

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

이전

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

사용:

  • GitLab 14.1 및 이전.

대신에:

  • GitLab 14.1 및 낮은.
  • GitLab 14.1 및 이전.

쉽게

쉽게를 사용하지 마세요. 사용자가 프로세스를 쉬워하지 못하면 신뢰를 잃을 수 있습니다.

예시

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

생략 부호

UI 텍스트를 문서화할 때 생략 부호가 포함되어 있으면 문서에 생략 부호를 포함시키지 마세요. 자세한 정보는 마이크로소프트 스타일 가이드를 참조하세요.

사용:

  • 새로 만들기

대신에:

  • 새로 만들기…

이메일

하이픈(-)으로 구분된 이메일을 사용하지 마세요. 복수형일 때는 이메일이나 이메일 메시지를 사용하세요. (Vale 규칙: SubstitutionWarning.yml)

이메일 주소

이메일에서 사용되는 주소를 나타낼 때 이메일 주소를 사용하세요. 메시지인 이메일로 줄여서 사용하지 마세요.

이모지

이모지를 복수형으로 나타낼 때 이모지를 사용하세요.

활성화

활성화에 대한 안내는 마이크로소프트 스타일 가이드를 참조하세요. 대신에 활성화된이나 켜기를 사용하세요.

입력

대부분의 경우 입력 대신 입력을 사용하세요.

  • 입력은 음성과 키보드를 포함한 여러 방법으로 정보를 입력하는 것을 포함합니다.
  • 입력은 사용자가 값을 입력하고 커서를 필드 외부로 이동시키거나 Enter 키를 누르는 동작으로 가정합니다. 입력은 콘텐츠의 입력과 콘텐츠를 확인하는 동작을 모두 포함합니다.

예시:

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

키보드의 입력을 나타내기 위해 HTML <kbd> 태그를 사용하세요.

  • 결과 디렉터리 보기에 Enter 키를 누릅니다.

타입에 대해서는 타입을 참조하세요.

이야기

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

관련하여는 연관를 참조하세요.

에픽 보드

에픽 보드에는 소문자를 사용하세요.

등등

가능한 한 등등을 피하세요. 최대한 구체적으로 작성하세요. 등등 대신에 등을 대체로 사용하지 마세요.

사용:

  • Merge Request 및 이슈와 같은 개체를 업데이트할 수 있습니다.

대신에:

  • Merge Request, 이슈 등의 개체를 업데이트할 수 있습니다.

확장

UI에서 섹션을 확장하거나 축소하는 것에 대해 이야기할 때 확장을 사용하세요.

Experiment

Experiment에 대해 대문자를 사용하세요. 예를 들어, XYZ 기능은 Experiment입니다. 또는 이 Experiment를 테스트할 준비가 되었습니다.

Experiment 기능에 대해 작성할 때 이 주제를 참조하는 것이 좋습니다.

내보내기

원시 데이터를 GitLab에서 표준 파일 형식으로 변환하는 것을 나타내려면 내보내기를 사용하세요.

내보내기와 다운로드를 구분할 수 있습니다.

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

예시:

  • 보고서 내용을 CSV 형식으로 내보냅니다.

다운로드와 혼동하지 마세요.

FAQ

속성으로 사용자가 FAQ 용어를 거의 검색하지 않을 것이므로 빠르게 정보를 찾을 수 있기를 원합니다. FAQ에 있는 정보는 다른 유사한 정보와 함께 쉽게 검색 가능한 주제 제목 아래에 있어야 합니다.

기능

기능이라는 단어를 거의 사용할 필요가 없습니다. 대신에 GitLab이 하는 작업에 대해 설명하세요.

예를 들어 다음과 같이 사용하세요:

  • 변경 사항을 대상 브랜치에 통합하려면 Merge Request을 사용하세요.

대신에:

  • 변경 사항을 대상 브랜치에 통합하기 위해 Merge Request 기능을 사용하세요.

기능 브랜치

기능 브랜치를 사용하지 마세요. 브랜치를 참조하세요.

필드

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

예를 들어:

  • 변수 이름 상자에 값을 입력합니다.

대신에:

  • 변수 이름 필드에 값을 입력합니다.

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

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

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

파일 이름

파일 이름에 대해 한 단어를 사용하세요. 변수로서 파일 이름을 사용할 때는 <파일 이름>을 사용하세요.

(Vale 규칙: SubstitutionWarning.yml)

필터

이슈나 Merge Request과 같은 디렉터리을 보고 있을 때 가능한 속성으로 디렉터리을 필터링합니다. 예를 들어 담당자나 리뷰어로 필터링할 수 있습니다.

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

foo

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

fork

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

upstream project(또는 source project로도 알려짐)와 fork는 fork relationship을 가지고 있으며 linked되어 있습니다.

fork relationship가 제거되면 fork는 upstream project에서 unlinked됩니다.

full screen

전체 화면은 두 단어를 사용하십시오. (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 Dedicated

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

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

GitLab Duo

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

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

  • GitLab Duo 채팅
  • GitLab Duo 코드 제안
  • GitLab 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 부가 기능을 사용할 수는 있지만, 필수는 아닙니다.

GitLab Flavored Markdown

가능한 경우 GitLab Flavored Markdown을 철자로 풀어쓰십시오.

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

GitLab Helm chart, GitLab chart

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

  • GitLab Helm chart(긴 버전)
  • GitLab chart(짧은 버전)

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

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

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

GitLab Pages

일관성과 브랜딩을 위해 GitLab Pages를 사용합니다. Pages 대신에 GitLab Pages를 사용할 수 있지만 UI 또는 페이지에서 처음 언급할 때 사용하십시오.

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에서 가이드를 페이지 제목의 일부로 사용하지 마십시오. 예를 들어, Snowplow Guide는 대신 기능 자체에 대해 이야기하고, 어떻게 사용하는지에 대해 설명하십시오. 예를 들어, Snowplow를 사용하여 xyz 수행.

Guest

Guest 역할에 대해 작성할 때:

  • G를 대문자로 사용하십시오.
  • 이를 풀어쓰십시오:
    • 사용: Guest 역할이 할당되었을 때
    • 사용하지 마십시오: 게스트일 때
  • 최소 필요 역할이 Guest 역할 일 때:
    • Guest 역할 이상을 적어 사용하십시오.
    • 사용하지 마십시오: 게스트 역할 또는 이상

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

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

편리한

편리한을 사용하지 마십시오. 사용자가 기능이나 프로세스를 편리하게 느끼지 않으면, 그 신뢰를 잃게 됩니다.

high availability, HA

고 가용성 또는 HA를 사용하지 마십시오. GitLab 참조 아키텍처에서 자세한 정보를 얻을 수 있습니다.

고 가용성 설정과 같은 의미로 다중 노드 설정 등을 사용하십시오.

높은

버전 번호를 언급할 때 높은을 사용하지 마십시오.

GitLab 14.4부터…

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

  • GitLab 14.4와 높은…

누르다

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

ENTER 키를 누르십시오.

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

  • ENTER 키를 누르십시오.

I

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

즉

라틴어 약어를 사용하지 마십시오. 대신 that is를 사용하십시오.

in order to

in order to를 사용하지 마십시오. 대신 to를 사용하십시오.

indexes, indices

index의 복수형으로 indexes를 사용하십시오.

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

Installation from source

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

자체 컴파일된 설치에 대해…

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

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

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

-ing words

가능한 경우 -ing 단어를 제거하십시오. 번역하기 어려운 경우가 많으며 더 정확한 용어를 사용할 수 있습니다.

  • The files using storage are deleted 대신 The files that use storage are deleted를 사용하십시오.
  • Delete files using the Edit button 대신 Use the Edit button to delete files를 사용하십시오.
  • Replicating your server is required 대신 You must replicate your server를 사용하십시오.

issue

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

issue board

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

Issue description generation

Issue description generation에 문장 케이스를 사용하십시오.

페이지에서 처음 언급할 때는 GitLab Duo Issue description generation을 사용하십시오. 그 후, Issue description generation만 사용하십시오.

issue weights

issue weights에 소문자를 사용하십시오.

IP address

IP 주소를 나타낼 때 IP 주소를 사용하십시오. IP로 참조하지 마십시오.

it

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

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

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

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

여기도 참조하십시오.

job

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

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

Kubernetes executor

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

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

  • GitLab 러너의 Kubernetes executor
  • Kubernetes executor

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

  • GitLab 러너 Kubernetes executor. 이것은 Kubernetes 상표를 침해할 수 있습니다.

later

버전 번호를 언급할 때 이후를 사용하십시오.

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

  • GitLab 14.1 및 이후…

디렉터리

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

license

라이선스에 관해 작성할 때 다음과 같이 사용하십시오:

  • 클라우드 라이선스, 오프라인 라이선스, 또는 레거시 라이선스와 같은 변형을 사용하지 마십시오.
  • 구독와 교체를 서로 교체하지 마십시오:
    • 라이선스는 사용자에게 구매한 구독에 대한 액세스를 부여하며, 구매한 좌석 수와 구독 날짜와 같은 정보를 포함합니다.
    • 구독은 사용자가 구매하는 구독 계층입니다.

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

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

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

  • 라이선스 구매
  • 라이선스 구매

제한사항

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

로그인, log on

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

  • 로그인.
  • 로그온.
  • 로그인

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

그러나 사용자 인터페이스에 Log in이 있는 경우, UI와 일치하도록 하십시오.

로그인한 사용자

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

하위

버전 번호를 언급할 때 하위를 사용하지 마십시오.

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

  • GitLab 14.1 및 미만.

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

  • GitLab 14.1 및 더 낮음.
  • GitLab 14.1 및 이전.

machine learning

machine learning에 소문자를 사용하십시오.

machine learning이 형용사로 사용될 때, a machine learning model과 같이 사용되는 경우 하이픈을 사용하지 마십시오. 하이픈을 사용하는 것이 더 문법적으로 정확할 수 있지만, 더 정확하려고 하다보면 일관성을 잃게 될 수 있습니다.

유지자

Maintainer 역할에 대해 쓸 때:

  • 대문자 M을 사용합니다.
  • 전체 글로 작성합니다.
    • 이용: 유지자(Maintainer) 역할이 할당된 경우
    • 대신: 유지자인 경우
  • Maintainer 역할이 최소 필요한 역할일 때:
    • 이용: 적어도 Maintainer 역할
    • 대신: Maintainer 역할 이상

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

Maintainer 권한을 사용하지 않습니다. Maintainer 역할이 지정된 사용자는 관련 권한 세트를 갖습니다.

인류

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

인력

manpower를 사용하지 않습니다. workforce 또는 GitLab team members와 같은 단어를 사용합니다. (Vale 규칙: InclusionGender.yml)

master

master를 사용하지 않습니다. default branch name을 필요로 할 때 main을 사용합니다. (Vale 규칙: InclusionCultural.yml)

might, may

Might는 무언가가 발생할 가능성이 있다는 것을 의미합니다. Might는 문제 해결 설명서에서 자주 사용됩니다.

May는 무언가를 할 수 있는 권한을 부여합니다. may 대신 can을 고려하십시오.

이러한 용어를 사용하는 구를 다시 쓰는 것을 고려하십시오. 이 용어들은 주로 가능성과 의심을 나타내며, 기술적 글쓰기는 정확해야 합니다.

다음을 참조하십시오 you can.

사용:

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

대신:

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

MB, 메가바이트

MB 및 GB의 경우, Microsoft 가이드를 따릅니다.

사용자

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

Merge Request 브랜치

Merge Request 브랜치를 사용하지 않습니다. 브랜치를 참조하십시오.

Merge Request

Merge Request에는 소문자를 사용합니다. 약어로 MR을 사용하는 경우 첫 사용에서 철자를 완전히 입력합니다.

Merge Request 요약

Merge Request 요약에는 문장 첫글자를 대문자로 사용합니다.

페이지에서 처음 언급될 때, GitLab Duo Merge Request 요약을 사용합니다. 그 후로는 Merge Request 요약을 단독으로 사용합니다.

중간 단계

중간 단계에는 소문자를 사용합니다.

최소 액세스

최소 액세스 역할에 대해 쓸 때:

  • 대문자 M 및 대문자 A를 사용합니다.
  • 전체 글로 작성합니다.
    • 이용: 최소 액세스(Minimal Access) 역할이 할당된 경우
    • 대신: 최소 액세스 사용자인 경우
  • 최소 액세스 역할이 최소 필요한 역할일 때:
    • 이용: 적어도 최소 액세스 역할
    • 대신: 최소 액세스 역할 이상

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

Minimal Access 권한을 사용하지 않습니다. Minimal Access 역할이 지정된 사용자는 관련 권한 세트를 갖습니다.

N/A

가능하면 not applicable을 사용합니다. 구문을 철자로 나타내어 영어를 사용하지 않는 사용자의 이해를 돕고 대문자 일관성을 피합니다.

이동

이동을 사용하지 않습니다. 대신 go를 사용합니다. 예를 들어:

  • 이 웹페이지로 이동합니다.
  • 터미널을 열고 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 및 이전으로.

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

Owner 역할에 대해 작성할 때:

  • 대문자 O를 사용합니다.
  • 전체 단어로 작성하십시오.
    • 사용하세요: if you are assigned the Owner role
    • Instead of: if you are an owner

굵게 표시하지 마십시오.

Owner permissions를 사용하지 마십시오. Owner 역할이 지정된 사용자에는 관련 권한 집합이 있습니다. Owner는 사용자가 가질 수 있는 가장 높은 역할입니다.

package registry

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

사용하세요:

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

page

“Issues 페이지에서”와 같은 구문을 작성하는 경우 해당 페이지로 이동하는 단계가 가까이에 있도록 하십시오. 그렇지 않으면 사람들은 Issues 페이지가 무엇인지 모를 수 있습니다.

페이지 이름은 페이지 상단에 UI에서 보여야 합니다. 그렇지 않은 경우, 해당 페이지 이름은 탐색 경로에서 확인할 수 있어야 합니다.

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

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

permissions

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

권한은 access levels과는 다릅니다.

personal access token

personal access token에 대해 소문자를 사용하십시오.

please

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

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

Premium

구독 티어로서 Premium을 사용하십시오. 다른 구독 티어의 맥락에서 Premium을 언급할 때는 구독 티어 가이드를 따르십시오.

preferences

테마 및 레이아웃과 같은 사용자별 시스템 레벨 설정을 설명하는 데 preferences를 사용하십시오.

prerequisites

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

Prerequisites는 항상 복수여야 하며, 항목이 하나만 포함되더라도 항상 복수여야 합니다.

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

튜토리얼 페이지 유형의 경우 before you begin을 사용하십시오.

press

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

  • 명령을 중지하려면 Control+C를 누릅니다.

profanity

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

provision

클라우드 인프라 만들기를 참조할 때 provision이라는 용어를 사용하십시오. 인프라를 프로비저닝하고 그 위에 응용 프로그램을 배포합니다.

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

  • AWS EKS 클러스터를 프로비저닝하고 응용 프로그램을 배포하십시오.

push rules

push rules에 대해 소문자를 사용하십시오.

README file

README 파일 또는 README.md 파일을 위해 역따옴표와 소문자를 사용하십시오.

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

복수형의 경우 README files를 사용하십시오.

recommend, we recommend

we recommend 대신에 you should를 사용하십시오. 우리는 사용자에게 동료에게 말하는 방식으로 말을 걸고, we와 them 사이의 다양한 점을 피하기 위해 노력합니다.

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

register

계정을 만든다는 것에 대해 말할 때 register를 사용하십시오.

remove

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

객체를 완전히 삭제하는 경우 delete를 대신 사용하십시오.

Reporter

Reporter 역할에 대해 작성할 때:

  • 대문자 R을 사용하십시오.
  • 전체 단어로 작성하십시오.
    • 사용하세요: if you are assigned the Reporter role
    • Instead of: if you are a reporter
  • Reporter 역할이 최소 요구 역할인 경우:
    • 최소한 Reporter 역할
    • Instead of: Reporter 역할 또는 그 이상

굵게 표시하지 마십시오.

Reporter permissions를 사용하지 마십시오. Reporter 역할이 지정된 사용자에는 관련 권한 집합이 있습니다.

Repository Mirroring

Repository Mirroring에 대해 제목 케이스를 사용하십시오.

resolution, resolve

문제 해결 솔루션이 문제를 영구적으로 해결할 때 resolution을 사용하십시오. 일반적으로 해결은 파일 및 코드 변경을 포함하여 문제를 수정하는 것을 의미합니다. 예를 들어:

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

참고: workaround도 참조하십시오.

요구 사항

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

requirements을 사용하지 마십시오.

초기화

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

각각

respectively 대신보다 더 정확하게 해석하세요.

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

대신에:

  • 새 사용자를 만든 경우 사용자 만들기를 선택하거나 기존 사용자를 편집한 경우 변경 사항 저장을 선택하세요.

복원

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

리뷰 앱

리뷰 앱은 소문자로 사용하세요.

역할

roles과 permissions를 교차로 사용하지 마십시오. 각 사용자에게는 역할이 할당됩니다. 각 역할에는 권한 세트가 포함됩니다.

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

역할은 access levels과 동일하지 않습니다.

root cause analysis

Root cause analysis에 문장 케이스를 사용하세요.

페이지에서 처음으로 언급될 때는 GitLab Duo Root cause analysis를 사용합니다. 이후에는 단독으로 Root cause analysis를 사용합니다.

롤백

GitLab 버전을 이전 버전으로 변경하는 작업에 롤백을 사용하세요.

라이선스나 구독에 대해 롤백을 사용하지 마십시오. 대신 구독 티어 변경을 사용하세요.

runner, runners

runners는 CI/CD 작업을 실행하는 에이전트입니다. GitLab Runner 및 이 이슈도 참조하십시오.

참조하는 경우, runners가 고객의 GitLab 인스턴스에 설치되어 있다는 것을 명시해야 하는 경우 Self-managed를 사용하세요. self-hosted보다는 Self-managed를 사용하세요.

runners의 범위를 참조할 때 사용하세요:

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

runner manager, runner managers

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

runner worker, runner workers

runner workers에 소문자를 사용합니다. 이것은 runner가 호스트 컴퓨팅 플랫폼에서 작업을 실행하기 위해 생성하는 프로세스입니다. GitLab Runner도 참조하십시오.

runner authentication token

runner authentication token을 사용하고 runner token, authentication token, 또는 token과 같은 다양한 표현 대신 사용합니다. Runners는 생성될 때 runner 인증 토큰이 할당되며, 작업을 실행할 때 GitLab과 인증하는 데 사용합니다.

(s)

단어를 선택적으로 복수형으로 만들기 위해 (s)를 사용하지 마십시오. 이는 이해를 느리게 할 수 있습니다. 예를 들면:

Use:

  • 원하는 작업을 선택합니다.

대신에:

  • 원하는 작업을 선택합니다.

무언가를 다중으로 선택할 수 있는 경우, 해당 단어를 복수형으로 작성하세요.

상태 확인

sanity check을 사용하지 마십시오. 대신 check for completeness을 사용하세요. (Vale 룰: InclusionAbleism.yml)

확장성

GitLab 성능을 추가 사용자를 위해 증가시키는 경우 확장성을 사용하지 마십시오. scale 또는 scaling은 때로는 허용되지만, 추가 사용자를 위해 GitLab 성능을 늘리는 참조는 독자를 GitLab 참조 아키텍처 페이지로 이동해야 합니다.

검색

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

검색은 filtering와 다릅니다.

사용자

구독 요금 체계를 참조할 때:

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

섹션

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

펼침/접힘 영역을 섹션으로 확장하거나 축소할 때 섹션이라는 단어를 포함하지 마십시오.

Use:

  • Auto DevOps를 확장합니다.

대신에:

  • Auto DevOps 섹션을 확장하지 마십시오.

선택

버튼, 링크, 메뉴 항목 및 디렉터리과 관련하여 select를 사용합니다. Select는 더 많은 디바이스에 적용되고, click은 마우스에 특정합니다.

Self-managed

고객의 GitLab 설치를 참조할 때 Self-managed를 사용합니다. self-hosted를 사용하지 마십시오.

서비스 데스크

Service Desk에 대해 제목 케이스를 사용합니다.

설정, 설정

설정(setting)은 제품의 기본 동작을 변경합니다. 설정(setting)은 일반적으로 하나 이상의 옵션을 가진 레이블로 나타내는 키/값 쌍으로 구성됩니다.

로그인, 로그인

로그인 작업을 설명할 때:

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

또한 사용할 수 있습니다:

  • 명사 또는 형용사로 로그인을 사용합니다. 예: 로그인 페이지 또는 로그인 제한.
  • 싱글 사인온을 사용하세요.

사용하지 마십시오:

  • 로그인(sign on).
  • 로그인(sign into).
  • 로그인(log on), 로그인(log in) 또는 로그인(log into)같은 경우.

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

등록

계정을 만드는 경우에는 sign up 대신에 register를 사용합니다.

인증된 사용자

signed-in user 또는 signed in user 대신에 authenticated user를 사용합니다.

간단히

simply나 simple을 사용하지 않습니다. 사용자가 프로세스를 간단히 생각하지 않는다면, 그들에게 신뢰를 잃게 됩니다. (Vale 규칙: Simplicity.yml)

since

단어 since는 시간적인 범위를 나타냅니다. 예를 들어, Since 1984, Bon Jovi has existed. since를 because로 사용하지 않습니다.

사용 예시:

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

사용 예시:

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

기울기

and/or 대신에 or를 사용하거나 문장을 다시 작성합니다. CI/CD와 같은 몇 가지 예외는 허용됩니다.

노예

slave를 사용하지 않습니다. 다른 선택은 secondary입니다. (Vale 규칙: InclusionCultural.yml)

리포지터리

컨텍스트에 따라:

  • Gitaly의 경우, 리포지터리는 물리적이어야 하며 리포지터리라고 부르셔야 합니다.
  • Gitaly 클러스터의 경우, 리포지터리는 다음 중 하나일 수 있습니다:
    • 가상적이고 가상 리포지터리라고 해야 합니다.
    • 물리적이고 물리적 리포지터리라고 해야 합니다.

Gitaly 리포지터리에는 물리적 경로가 있고 가상 리포지터리에는 가상 경로가 있습니다.

하위그룹

subgroup 대신에 subgroup을 사용합니다. 또한, subgroup에 대한 대체 용어인 child group 또는 low-level group와 같은 용어를 피합니다. (Vale 규칙: SubstitutionWarning.yml)

구독 티어

구독이나 구독 티어를 license와 혼동하지 않습니다. 사용자는 구독을 구입합니다. 해당 구독에는 티어가 있습니다.

티어를 설명하는 방법: | 대신에 | 사용 | |—————————–|—————————| | 무료 티어 이상 | 모든 티어 | | 무료 티어 이상 | 모든 티어 | | Premium 티어 이상 | Premium 및 Ultimate 티어 | | Premium 티어 이상 | Premium 및 Ultimate 티어 | | Premium 티어 이하 | 무료 및 Premium 티어 |

추천 리뷰어

Suggested Reviewers에 대해 타이틀 케이스를 사용합니다. 페이지에서 처음 언급할 때는 GitLab Duo Suggested Reviewers를 사용합니다.

Suggested Reviewers는 항상 복수로 사용되며, 일반적이더라도 대문자로 표시됩니다.

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

that

명사를 설명할 때 that을 사용하지 않습니다. 예를 들어:

사용: - 저장하는 파일…

대신에: - that 저장하는 파일…

여기 참고.

터미널

terminal을 소문자로 사용합니다. 예를 들어:

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

Terraform Module Registry

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

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

테스트 생성

Test generation에는 문장 케이스를 사용합니다.

페이지에서 처음 언급할 때는 GitLab Duo Test generation을 사용합니다. 그 후로는 Test generation만 사용합니다.

텍스트 상자

UI 요소를 나타낼 때 field나 box 대신 text box를 사용합니다.

존재하거나 있다

존재하거나 있다를 피하십시오. 이러한 구문은 주어를 숨깁니다.

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

대신에: - 그 양동이에는 구멍이 있습니다.

그들

구체적인 사람을 참조하는 경우가 아니라면, 성별 특정 대명사의 사용을 피합니다. 성별 중립적 대명사로 they를 사용합니다.

this, these, that, those

반드시 명사와 함께 사용합니다. 예를 들어:

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

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

  • 이 바지들이 최고입니다.

  • 대신에: These는 최고입니다.

  • 저 로봇이 당신이 찾는 것입니다.

  • 대신에: That로봇이 당신이 찾는 것입니다.

  • 그 설정들을 구성해야 합니다. (또는 그 설정들을 구성해주세요.)
  • 대신에: Those를 구성해야 합니다.

to which, of which

to which와 of which를 피하고 접속사를 문장 끝에 매달아 놓습니다. 예시는 Prepositions를 참조하십시오.

할 일 항목

to-do 항목에는 소문자와 하이픈을 사용합니다. (Vale 규칙: ToDo.yml)

할 일 디렉터리

To-Do List에는 타이틀 케이스를 사용합니다. (Vale 규칙: ToDo.yml)

토글

토글을 켜거나 끕니다. 예를 들어:

  • blah 토글을 켜십시오.

TFA, 이중 인증

2FA 및 이중 인증 사용

type

검색어를 입력 중인 상태에서 type을 사용합니다. 예를 들어, 검색 상자에 입력을 시작하고 검색 결과가 표시됩니다. 검색 상자에서 벗어나지 않습니다.

예시: - 이름이 Alex인 모든 사용자를 보려면 Al을 입력하세요. - 문서 팀의 모든 라벨을 보려면 doc을 입력하세요. - 퀵 액션 디렉터리을 보려면 /을 입력하세요.

enter도 참조하세요.

Ultimate

구독 계층에서 Ultimate를 대문자로 사용합니다. Ultimate를 다른 구독 계층과 관련하여 언급할 때는 구독 계층 가이드를 따릅니다.

undo

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

units of measurement

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

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

update

소프트웨어의 최신 패치 버전을 설치할 때에만 update를 사용합니다. 예를 들어:

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

다른 경우에는 update 대신 upgrade를 사용합니다.

upgrade

upgrade는 다음과 같은 경우에 사용합니다:

  • 더 높은 구독 계층 (Premium 또는 Ultimate)을 선택합니다.
  • GitLab의 최신 주요(13.0) 또는 마이너(13.2) 버전을 설치합니다.

예시: - GitLab Ultimate로 업그레이드합니다. - GitLab을 14.0에서 14.1로 업그레이드합니다. - GitLab을 14.0에서 15.0으로 업그레이드합니다.

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

downgrade 및 roll back도 참조하세요.

upper left, upper right

UI에서 방향을 제시할 때 upper-left corner 및 upper-right corner를 사용합니다. UI 요소가 모서리에 없는 경우 upper left 및 upper right를 사용합니다.

top left 및 top right를 사용하지 않습니다.

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

useful

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

user account

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

using

대부분의 경우에는 using을 피합니다. 주어를 숨기고 문구를 더 어렵게 만들기 때문입니다. by using, that use를 사용하거나 문장을 다시 작성합니다.

예시: - 리포지터리를 사용하는 파일… - 리포지터리를 사용하여 파일…

올바르지 않은 사용 예:

  • 디렉터리 변경 using the command line.

올바른 사용 예:

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

utilize

utilize를 사용하지 않습니다. 대신 use를 사용합니다. 더 간결하며 비 네이티브 영어 사용자에게 이해하기 쉽습니다. (Vale 규칙: SubstitutionWarning.yml)

Value stream forecasting

Value stream forecasting에는 문장 케이스를 사용합니다. 페이지에서 처음 언급할 때는 GitLab Duo Value stream forecasting을 사용합니다. 이후에는 Value stream forecasting만 사용합니다.

via

라틴 약어를 사용하지 않습니다. with, through, 또는 by using을 대신 사용합니다. (Vale 규칙: LatinTerms.yml)

Vulnerability resolution

Vulnerability resolution에는 문장 케이스를 사용합니다.

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

Vulnerability explanation

Vulnerability explanation에는 문장 케이스를 사용합니다.

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

we

we를 피하고 대신에 사용자가 GitLab에서 어떤 작업을 수행할 수 있는지에 중점을 둡니다.

예시: - 워크를 정리할 작업이 있다면 위젯을 사용하세요.

잘못된 사용 예:

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

workaround

workaround는 해결 방법이 일시적인 경우에 사용합니다. 워크어라운드는 보통 즉시 해결책이며 지속적인 문제가 있을 수 있습니다. 예를 들어:

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

resolution도 참조하세요.

while

while은 시간 상에 일어나는 것에만 사용합니다. 예를 들어, 프로세스가 실행되는 동안 창을 열어 두세요.

while을 비교에 사용하지 않습니다. 예를 들어 사용하세요:

  • Job 1은 빠르게 실행할 수 있습니다. 그러나 Job 2는 더 정확합니다.

잘못된 사용 예:

  • Job 1은 빠르게 실행될 수 있는 반면 Job 2는 더 정확합니다.

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

whilst

whilst를 사용하지 않습니다. 대신 while를 사용합니다. While이 더 간결하며 비 네이티브 영어 사용자에게 이해하기 쉽습니다.

화이트리스트

화이트리스트 대신 허용디렉터리(allowlist)을 사용하세요. (Vale 규칙: InclusionCultural.yml)

아직

제품이나 해당 기능에 대해 아직(yet)을 사용하지 마십시오. 문서에서는 현재 제품으로 설명합니다.

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

미래 버전에서의 유망한 기능에 대해 작성하는 방법을 확인하세요.

you, your, yours

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

예시:

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

대신에:

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

you can

가능하다면 you can 대신에 능동적인 동사로 문장을 시작하세요. 예를 들면:

  • 코드 리뷰 분석을 사용하여 Merge Request 데이터를 확인합니다.
  • 팀 작업을 정리하기 위해 보드를 생성합니다.
  • 리포지터리에 푸시를 제한하기 위해 변수를 구성합니다.
  • Skype 및 Twitter와 같은 외부 계정에 링크를 추가합니다.

선택적인 조치에 대해 you can을 사용하세요. 예를 들면:

  • 코드 리뷰 분석을 사용하여 Merge Request 당 메트릭스를 확인합니다. 또한 API를 사용할 수 있습니다.
  • 이름과 값 쌍을 입력합니다. 스트리밍 대상당 최대 20개의 쌍을 추가할 수 있습니다.