권장 단어 목록

일관성을 보장하기 위해, 기술 문서 작성팀은 다음과 같은 단어 선택을 권장합니다. 추가로:

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

.gitlab-ci.yml 파일

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

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

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

& (앰퍼샌드)

라틴어 약어를 사용하지 마세요. 대신 and를 사용하세요. UI 요소가 &를 사용하는 경우는 제외합니다.

@mention

@mention을 사용하지 않도록 하세요. 대신 mention이라고 말하고, mention 주제로 링크하는 것을 고려하세요.

백틱은 사용하지 마세요.

2FA, 이중 인증

첫 사용 및 주제 제목의 경우 문장 대문자로 이중 인증을 쓰고, 그 이후에는 2FA를 사용하세요. 문장의 첫 단어에 있을 때는 factor나 authentication을 대문자로 쓰지 마세요. 예를 들어:

  • 이중 인증 (2FA)은 계정을 안전하게 보호하는 데 도움이 됩니다. 최초 로그인 시 2FA를 설정하세요.

이전

문서 페이지의 예제나 표를 참조할 때 위라는 단어의 사용을 피하세요. 필요할 경우, 대신 이전을 사용하세요. 예를 들어:

  • 이전 예제에서는 개가 벨레가 있었습니다.

제품의 버전을 언급할 때는 위를 사용하지 마세요. 대신 이후를 사용하세요.

사용 예:

  • GitLab 14.4 및 이후…

사용하지 않을 예:

  • GitLab 14.4 및 위…
  • GitLab 14.4 및 더 높음…
  • GitLab 14.4 및 최신…

접근 수준

접근 수준은 역할 또는 권한과 다릅니다. 사용자를 생성할 때, 접근 수준을 선택합니다: 정규, 감사자, 또는 관리자.

UI를 언급할 때는 이러한 단어의 첫 글자를 대문자로 쓰세요. 그렇지 않으면 소문자를 사용하세요.

추가

물체가 이미 존재하는 경우 추가를 사용하세요. 물체가 아직 존재하지 않는 경우는 생성을 대신 사용하세요.
추가는 제거의 반대입니다.

예를 들어:

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

추가와 생성을 혼동하지 마세요.

새로운 추가는 사용하지 마세요.

관리 영역

사용:

  • 관리 영역, UI의 이 영역을 설명합니다.
  • UI 버튼에 대해 관리를 사용합니다.

대신에:

  • 관리 영역 (두 단어를 모두 굵게)
  • 관리 영역 (Area를 대문자로)
  • 관리 영역 (Area를 대문자로)
  • 관리자 영역
  • 또는 다른 변형들

관리 모드

UI에서 title case를 사용하므로 관리 모드를 사용합니다.

관리자

사용자의 접근 수준에 대해 이야기할 때 관리자 접근 대신 admin을 사용하십시오.

관리 접근 수준

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

사용:

  • 이 작업을 수행하려면 관리자가 되어야 합니다.
  • 이 작업을 수행하려면 관리자 접근이 필요합니다.

대신에:

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

고급 검색

GitLab 인스턴스 전체에서 더 빠르고 효율적인 검색을 가리키기 위해 고급 검색은 소문자로 사용합니다.

에이전트

GitLab Kubernetes 에이전트에 대해 언급할 때 소문자를 사용합니다.

예를 들어:

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

GitLab 에이전트 또는 GitLab Kubernetes 에이전트에 대해 title case를 사용하지 마십시오.

에이전트 접근 토큰

Kubernetes용 에이전트를 생성할 때 생성된 토큰입니다. 에이전트 접근 토큰을 사용하세요, 다음을 사용하지 마세요:

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

중립적

중립적 대신 플랫폼 독립적 또는 벤더 중립적을 사용하십시오.

AI, 인공지능

AI를 사용하십시오. 인공지능을 풀어서 쓰지 마십시오.

AI 영향 대시보드

AI 영향 대시보드를 title case로 사용하십시오.

페이지에서 처음 언급할 때는 GitLab Duo AI 영향 대시보드를 사용하십시오.

이후에는 AI 영향 대시보드만 사용하십시오.

AI 기반 DevSecOps 플랫폼

GitLab에 선행할 경우, 플랫폼을 대문자로 작성하십시오. 예: GitLab AI 기반 DevSecOps 플랫폼.

오프라인 환경

인터넷 접근을 방지하거나 제한하는 물리적 장벽이나 보안 정책이 있는 설치를 설명하기 위해 오프라인 환경을 사용하십시오. 공기 간격, 공기 갭, 또는 공기 갭된 표현은 사용하지 마십시오. 예:

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

허용, 활성화

보안 관련 기능에 대해 이야기하지 않는 한 허용 및 활성화를 피하는 것이 좋습니다.

사용:

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

대신에:

  • 이 기능은 저장소에 파일을 추가할 수 있도록 허용합니다.
  • 이 기능은 사용자가 그들의 저장소에 파일을 추가할 수 있도록 활성화합니다.

이 표현은 사용자 관점에서 보다 능동적이며 기능을 구현한 사람의 관점이 아닙니다.

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

분석

분석 및 그 변형(예: 기여 분석 및 이슈 분석)은 소문자로 사용합니다.

그러나 UI에 다른 대문자 표현이 있으면 문서가 UI에 맞게 조정됩니다.

예:

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

조상

계층 구조에서 하나 이상의 레벨 위에 있는 부모 항목을 언급할 때는 조상을 사용하세요.

할아버지는 사용하지 마세요.

예시:

  • 조상 그룹: 프로젝트의 계층 구조에 있는 그룹.
  • 조상 에픽: 이슈의 계층 구조에 있는 에픽.
  • 그룹과 그 모든 조상.

또한 참조: 자식, 자손, 하위 그룹.

and/or

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

and so on

and so on은 사용하지 마세요. 대신 더욱 구체적으로 작성하세요. 자세한 내용은 Microsoft Style Guide를 참조하세요.

지역

지역 대신 섹션을 사용하세요. 유일한 예외는 관리 영역입니다.

~로서

~로서를 ~때문에를 의미하는 데 사용하지 마세요.

사용 예:

  • 엔드포인트가 ID를 반환하지 않기 때문에…

대신:

  • 엔드포인트가 ID를 반환하지 않기 때문에…

뿐만 아니라

~뿐만 아니라 대신 그리고를 사용하세요.

연관

이슈를 에픽에 추가하거나, 사용자를 이슈, 병합 요청 또는 에픽에 추가하는 경우에는 연관이라는 단어를 사용하지 마세요.

대신 할당을 사용하세요. 예를 들어:

  • 이슈를 에픽에 할당하세요.
  • 사용자를 이슈에 할당하세요.

인증된 사용자

로그인한 사용자 또는 가입한 사용자와 같은 다른 변형 대신 인증된 사용자를 사용하세요.

시작하기 전에

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

자세한 내용은 자습서 페이지 유형을 참조하세요.

작업 주제 유형에 대해서는 전제 조건을 사용하세요.

이하

문서 페이지에서 예시나 표를 언급할 때는 이하를 피하세요. 필요한 경우 대신 다음을 사용하세요. 예를 들어:

  • 다음 예에서 개는 벼룩이 있습니다.

베타

베타는 소문자로 사용하세요. 예:

  • 기능은 베타에 있습니다.
  • 이것은 베타 기능입니다.
  • 이 베타 릴리즈는 테스트할 준비가 완료되었습니다.

베타 기능에 대해 작성할 때는 이 주제와 링크를 추가할 수도 있습니다.

블랙리스트

블랙리스트는 사용하지 마세요. 대안으로 거부 목록을 사용할 수 있습니다. (Vale 규칙: InclusiveLanguage.yml)

보드

보드, 이슈 보드, 에픽 보드는 소문자로 사용하세요.

텍스트 상자

UI 필드를 언급할 때는 텍스트 상자를 사용하세요. 필드나 상자는 사용하지 마세요. 예:

  • 변수 이름 텍스트 상자에 값을 입력하세요.

브랜치

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

  • 기본 브랜치: 저장소의 기본 브랜치. 사용자는 UI를 사용하여 기본 브랜치를 설정할 수 있습니다. 기본 브랜치를 사용하는 예시는 main 대신 master를 사용하세요.
  • 소스 브랜치: 병합할 브랜치입니다.
  • 대상 브랜치: 병합할 브랜치입니다.
  • 현재 브랜치: 체크아웃한 브랜치입니다. 이 브랜치는 기본 브랜치, 사용자가 생성한 브랜치, 소스 브랜치 또는 다른 브랜치일 수 있습니다.

기능 브랜치 또는 병합 요청 브랜치라는 용어를 사용하지 마세요. 가능한 한 구체적으로 작성하세요. 예:

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

목록

주문된 목록이나 순서가 없는 목록의 개별 항목을 bullets라고 언급하지 마세요. 대신 리스트 항목을 사용하세요. 모호성을 줄일 필요가 있는 경우 다음과 같이 사용할 수 있습니다:

  • 주문된 리스트 항목: 주문된 목록의 항목.
  • 순서가 없는 리스트 항목: 순서가 없는 목록의 항목.

버튼

버튼에 설명자를 사용하지 마세요.

사용하세요:

  • Run pipelines 선택.

대신:

  • Run pipelines 버튼을 선택.

불가능, 할 수 없다

할 수 없다 대신 불가능을 사용하세요.

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

Chat, GitLab Duo Chat

Chat 또는 GitLab Duo Chat을 사용할 때 첫 글자는 대문자 C로 사용하세요.

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

이후에는 Chat만 사용하세요.

체크박스

체크박스는 하나의 단어로 사용하세요. check box라는 용어는 사용하지 마세요.

체크박스를 선택해야 하며(또는 클리어해야 하며), 체크 또는 활성화 또는 비활성화라는 용어는 사용하지 마세요. 예를 들어:

  • Protect environment 체크박스를 선택하세요.
  • Protect environment 체크박스를 클리어하세요.

체크박스를 언급해야 하는 경우 선택되었거나 클리어되었다고 말할 수 있습니다. 예를 들어:

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

(deselect와 관련하여, Vale 규칙: SubstitutionWarning.yml)

체크아웃, 체크아웃

동사로서 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 분이라는 용어는 사용하지 마세요. 이 용어는 컴퓨트 분으로 이름이 변경되었습니다.

자식

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

예제:

  • 자식 이슈
  • 자식 에픽
  • 자식 목표
  • 자식 핵심 결과
  • 자식 파이프라인

자세한 내용은 자손, 부모, 하위 그룹을 참고하세요.

선택

클릭을 사용하지 마세요. 대신 버튼, 링크, 메뉴 항목 및 목록과 함께 선택을 사용하세요.

선택은 더 많은 장치에 적용되며, 클릭은 마우스에 더 구체적입니다.

하지만 우클릭과 클릭 스루 데모의 경우 예외를 만들 수 있습니다.

클라우드 라이센스

클라우드 라이센스라는 문구를 사용하지 마세요. 대신 이 구독이 GitLab과 동기화된다는 사실에 집중하세요.

예를 들어:

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

클라우드 네이티브

Kubernetes 클러스터를 사용하여 GitLab을 호스팅하는 것에 대해 이야기할 때, 클라우드 네이티브 버전의 GitLab에 대해 이야기하는 것입니다.

이 버전은 GitLab을 배포하는 데 사용되는 더 크고 단일한 리눅스 패키지와 다릅니다.

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

코드 완성

코드 제안은 두 가지 주요 기능을 포함하도록 발전했습니다:

  • 코드 완성
  • 코드 생성

코드 완성은 소문자로 사용하세요. GitLab Duo Code Completion을 사용하지 마세요.

GitLab Duo는 Code Suggestions에만 사용됩니다.

코드 완성은 항상 단수형이여야 합니다.

예시:

  • 파일을 채우기 위해 코드 완성을 사용하세요.

코드 설명

코드 설명에 대해 제목 형식을 사용하세요.

페이지에서 처음 언급할 때는 GitLab Duo Code Explanation을 사용하세요.

그 이후에는 Code Explanation만 단독으로 사용하세요.

코드 생성

코드 제안은 두 가지 주요 기능을 포함하도록 발전했습니다:

  • 코드 완성
  • 코드 생성

코드 생성은 소문자로 사용하세요. GitLab Duo Code Generation을 사용하지 마세요.

GitLab Duo는 Code Suggestions에만 사용됩니다.

코드 생성은 항상 단수형이여야 합니다.

예시:

  • 당신의 코멘트를 기반으로 코드를 만들기 위해 코드 생성을 사용하세요.
  • 파일에 코드 코멘트를 추가하여 코드 생성 결과를 조정하세요.

코드 리뷰 요약

코드 리뷰 요약에 대해 제목 형식을 사용하세요.

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

그 이후에는 Code Review Summary만 단독으로 사용하세요.

코드 제안

코드 제안에 대해 제목 형식을 사용하세요. 페이지에서 처음 언급할 때는 GitLab Duo Code Suggestions을 사용하세요.

코드 제안 기능은 항상 s로 끝나야 합니다. 그러나 단수로 작성해야 합니다. 예를 들어:

  • 인스턴스에 대해 코드 제안이 켜져 있습니다.

기능 출력에 대한 제안을 일반적으로 언급할 때는 소문자를 사용하세요.

예시:

  • 타이핑할 때 코드 제안을 사용하여 제안을 표시하세요. (이 문구는 기능을 설명합니다.)
  • 타이핑할 때, 제안이 표시됩니다. (이 문구는 일반적입니다.)

코드 제안은 두 가지 주요 기능을 포함하도록 발전했습니다:

축소

UI에서 섹션을 확장하거나 축소할 때는 축소를 사용하세요.

커맨드 라인

명령을 소개할 때는 커맨드 라인에서를 사용하세요.

형용사로 사용할 때 하이픈을 사용하세요. 예: 커맨드-라인 도구.

컴퓨트

CI/CD 작업을 실행하기 위해 러너가 사용하는 리소스를 위해 컴퓨트를 사용하세요.

관련 용어:

  • 컴퓨트 분: 컴퓨트 사용량이 계산되는 방법. 예: 400 컴퓨트 분.
  • 컴퓨트 쿼터: 네임스페이스가 매달 사용할 수 있는 컴퓨트 분의 한도.
  • 컴퓨트 사용량: 네임스페이스가 월간 쿼터에서 사용한 컴퓨트 분의 수.

컴퓨트 분

컴퓨트 분을 이러한 (또는 유사한) 용어 대신 사용하세요:

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

자세한 내용은 에픽 2150를 참조하세요.

구성

설정 모음을 업데이트할 때는 구성이라고 부르세요.

구성

기능이나 제품을 설정한 후에 configure를 사용하십시오.

예를 들어:

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

확인 대화 상자

동작을 확인하라는 메시지를 표시하는 대화 상자를 설명할 때 확인 대화 상자를 사용하십시오. 예를 들어:

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

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

컨테이너 레지스트리

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

사용 예:

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

생성

객체가 존재하지 않을 때 처음으로 생성하는 경우 create를 사용하세요. Create는 delete의 반대입니다.

예를 들어:

  • 문제를 생성합니다.

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

create new는 사용하지 마십시오. create라는 단어는 객체가 새로 생성된 것임을 함의하므로 추가 단어가 필요하지 않습니다.

현재

제품이나 기능에 대해 이야기할 때 현재를 사용하지 마십시오. 문서는 현재 제품을 설명합니다.

(Vale 규칙: CurrentStatus.yml)

사용자 정의 역할

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

비맞춤 역할에 대해 언급할 때는 default role을 사용하십시오.

데이터

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

사용 예:

  • 데이터가 수집됩니다.
  • 데이터는 성능 증가를 보여줍니다.

대신:

  • 데이터가 수집됩니다.
  • 데이터는 성능 증가를 보여줍니다.

기본 역할

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

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

static role, built-in role 또는 predefined role는 사용하지 마십시오.

삭제

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

객체가 계속 존재하는 경우 remove를 대신 사용하십시오.

예를 들어, 문제를 에픽에서 제거할 수 있지만 문제는 여전히 존재합니다.

Dependency Proxy

GitLab Dependency Proxy에 대해 제목 대문자를 사용하십시오.

배포 보드

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

자손

계층에서 하나 이상의 레벨 아래의 자식 항목을 언급할 때 descendant를 사용하십시오.

grandchild는 사용하지 마십시오.

예시:

  • 자손 프로젝트, 그룹의 계층에 있는 프로젝트입니다.
  • 자손 문제, 에픽의 계층에 있는 문제입니다.
  • 그룹과 그에 소속된 모든 자손들.

자세한 내용은 ancestor, child 및 subgroup을 참조하십시오.

개발자

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

  • 대문자 D를 사용하십시오.
  • 굵은 글씨를 사용하지 마십시오.

  • if you are a developer라는 문구를 사용하여 개발자 역할에 배정된 사람을 의미하지 않도록 하십시오. 대신 다음과 같이 작성하십시오. 예: if you are assigned the Developer role.

  • 개발자 역할이 최소 요구 사항인 상황을 설명할 때:
    • 다음을 사용하십시오: 최소한 개발자 역할
    • 대신: 개발자 역할 또는 더 높음

Developer permissions는 사용하지 마십시오. 개발자 역할에 배정된 사용자는 관련 권한 집합을 보유하고 있습니다.

DevSecOps 플랫폼

GitLab이 앞에 올 경우 Platform을 대문자로 적습니다. 예를 들어, GitLab DevSecOps Platform.

대화 상자

다음 대안 대신 대화 상자를 사용하세요:

  • 대화 상자
  • 모달
  • 모달 대화 상자
  • 모달 창
  • 팝업
  • 팝업 창
  • 창

또한 확인 대화 상자를 참조하세요. 자세한 내용은 Microsoft Style Guide를 참조하세요.

이 용어를 사용하기 전에 대화 상자 또는 서랍이 귀하의 사용 사례에 적합한 용어인지 확인하세요.

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

  • Grant permission 대화 상자에서 Group을 선택하세요.

또한 on을 참조하세요.

비활성화

설정이나 기능을 사용할 수 없도록 만드는 것을 설명하기 위해 비활성화를 사용하지 마세요. 대신 끄기, 숨기기, 사용 불가능하게 만들기 또는 제거하기와 같은 대안을 사용하세요.

상태를 설명할 때는 off, 비활성, 또는 사용 불가능이라고 사용하세요.

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

방지

disallow 대신 prevent를 사용하세요. (Vale 규칙: Substitutions.yml)

토론 요약

토론 요약에는 제목 대문자를 사용하세요.

페이지에서 처음 등장할 때는 GitLab Duo 토론 요약을 사용하세요. 그 이후에는 토론 요약만 사용하세요.

Docker-in-Docker, dind

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

컨테이너 이름을 설명할 때는 백틱으로 감싸서 사용하세요: docker:dind. 그렇지 않으면 전체 단어로 적으세요.

다운그레이드

보다 긍정적이고 구체적으로 하기 위해 다운그레이드라는 용어를 사용하지 마세요. 대신 사용자가 수행하는 작업에 집중하세요.

  • 이전 GitLab 버전으로 변경할 때는 롤백을 사용하세요.
  • 낮은 GitLab 수준으로 변경할 때는 구독 수준 변경을 사용하세요.

다운로드

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

다운로드와 내보내기를 혼동하지 마세요.

서랍

서랍 UI 구성 요소를 설명할 때는 서랍을 사용하세요:

  • 화면 오른쪽에서 나타납니다.
  • 사용자가 현재 페이지를 떠나지 않고도 맥락에 맞는 정보 또는 작업을 표시합니다.

서랍의 예를 보려면:

이 용어를 사용하기 전에 서랍 또는 대화 상자가 귀하의 사용 사례에 적합한 용어인지 확인하세요.

드롭다운 목록

UI 요소를 참조할 때는 드롭다운 목록을 사용하세요. 목록 없이 드롭다운을 사용하지 마세요.

하이픈이 있는 드롭다운이나 드롭다운 메뉴 또는 다른 변형을 사용하지 마세요.

예를 들어:

  • Visibility 드롭다운 목록에서 Public을 선택하세요.

이전

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

사용 예:

  • GitLab 14.1 및 이전.

사용하지 마세요:

  • GitLab 14.1 및 낮은.
  • GitLab 14.1 및 오래된.

쉽게

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

예를 들어

라틴 약어는 사용하지 마세요. 대신 예를 들어, 처럼, 예시로, 또는 같이를 사용하세요. (Vale 규칙: LatinTerms.yml)

생략 부호

UI 텍스트를 문서화할 때 UI에 생략 부호가 포함되어 있다면, 문서에는 생략 부호를 포함하지 마세요.

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

사용 예:

  • 새로 만들기

사용하지 마세요:

  • 새로 만들기…

이메일

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

이메일 주소

이메일에 사용되는 주소를 언급할 때는 email address를 사용하세요. email로 줄이지 마세요. 이는 메시지를 의미합니다.

이모지

이모지의 복수형을 언급할 때는 이모지를 사용하세요.

활성화

설정이나 기능을 사용 가능하게 만들 때는 활성화를 사용하지 마세요. 대신 켜기를 사용하세요.

상태를 설명할 때는 켜짐 또는 활성을 사용하세요.

이 지침은 Microsoft 스타일 가이드를 기반으로 합니다.

입력

대부분의 경우 입력을 사용하세요. 입력은 정보를 입력하는 다양한 방법(음성 및 키보드 포함)을 포괄합니다.

입력은 사용자가 필드에 값을 입력하고 커서를 필드 외부로 이동시키는 것(또는 Enter 키를 누르는 것)을 포함합니다.

예를 들어:

  • 변수 이름 텍스트 상자에 값을 입력하세요.
  • 변수 이름 텍스트 상자에 my text를 입력하세요.

키보드의 키를 지칭할 때는 입력을 사용하세요:

  • 결과 목록을 보려면 Enter를 눌러주세요.

자세한 내용은 타입을 참조하세요.

서사시

서사시는 소문자를 사용하세요.

자세한 내용은 연관시키기를 참조하세요.

서사시 보드

서사시 보드는 소문자를 사용하세요.

기타

etc.는 피하세요. 가능하면 구체적으로 작성하세요. 그리고 그 외를 대체로 사용하지 마세요.

사용 예:

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

사용하지 마세요:

  • 병합 요청, 문제 등과 같은 객체를 업데이트할 수 있습니다.

확장

UI에서 섹션을 확장하거나 축소할 때는 확장을 사용하세요.

실험

실험은 소문자를 사용하세요. 예를 들어:

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

필요한 경우 실험적을 사용할 수 있습니다.

실험적 기능에 대해 작성할 때는 이 주제로 링크하는 것도 고려하세요.

내보내기

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

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

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

예를 들어:

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

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

자주 묻는 질문

사용자가 정보를 신속하게 찾기를 원하며, 자주 묻는 질문이라는 용어를 검색하는 경우는 드뭅니다.

자주 묻는 질문의 정보는 다른 유사한 정보와 함께 쉽게 검색 가능한 주제 제목 아래에 있어야 합니다.

기능

기능이라는 단어를 잘 사용하지 않아야 합니다. 대신 GitLab이 하는 일을 설명하십시오.

예를 들어, 다음을 사용하십시오:

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

대신에:

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

기능 브랜치

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

필드

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

사용 예:

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

대신에:

  • 변수 이름 필드에 my text를 입력합니다.

하지만, 작업을 작성하고 모든 필드를 한 번에 언급해야 할 때는 예외를 만들 수 있습니다. 예를 들어:

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

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

파일 이름

파일 이름은 한 단어로 사용하십시오. 변수를 사용할 때는 <filename>을 사용하십시오.

(Vale 규칙: SubstitutionWarning.yml)

필터

항목 목록(예: 이슈 또는 병합 요청)을 보고 있을 때, 사용 가능한 속성으로 목록을 필터링합니다. 예를 들어, 담당자나 검토자로 필터링할 수 있습니다.

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

foo

제품 문서에서 foo를 사용하지 마십시오. API와 기여자 문서에서는 사용할 수 있지만, 대신 더 명확하고 의미 있는 예제를 사용하는 것을 권장합니다.

포크

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

업스트림 프로젝트(소스 프로젝트라고도 함)와 포크는 포크 관계를 가지고 있으며, 연결되어 있습니다.

포크 관계가 제거되면, 포크는 업스트림 프로젝트와 연결 해제됩니다.

전체 화면

전체 화면은 두 단어로 사용하십시오.

(Vale 규칙: SubstitutionWarning.yml)

미래 시제

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

(Vale 규칙: FutureTense.yml)

GB, 기가바이트

GB 및 MB에 대해서는 Microsoft 안내를 따르세요.

Geo

Geo는 제목 대문자로 사용하세요.

일반적으로 사용 가능, 일반 출시

일반적으로 사용 가능 및 일반 출시는 소문자로 사용하세요.

예시:

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

일반적으로 사용 가능을 더 자주 사용하세요. 예를 들어,

  • 이 기능은 일반 출시를 달성했습니다. 라고 하지 마세요.

처음 사용할 때 GA(General Availability)를 풀어 쓰면 됩니다.

GitLab

GitLab을 소유형(예: GitLab’s)으로 만들지 마세요. 이 지침은 GitLab 상표 가이드라인을 따릅니다.

GitLab을 타 제3자 도구나 브랜드 이름 옆에 두지 마세요.

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

  • GitLab Chrome extension
  • GitLab Kubernetes agent

대신 다음과 같이 사용하세요:

  • GitLab extension for Chrome
  • GitLab agent for Kubernetes

브랜드 이름을 서로 옆에 두는 것은 소유권이나 파트너십을 암시할 수 있으며, 이는 원하지 않습니다.

법적 검토를 거쳐 파트너십을 홍보하라는 지시를 받지 않는 한 그렇습니다.

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

GitLab Dedicated

GitLab Dedicated는 제품 오퍼링을 지칭하는 데 사용합니다. 이는 고객을 위해 GitLab이 호스팅하고 관리하는 GitLab 인스턴스를 의미합니다.

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

Dedicated를 혼자 사용하지 마세요. 항상 GitLab Dedicated를 사용하세요.

GitLab Duo

Duo를 혼자 사용하지 마세요. 항상 GitLab Duo를 사용하세요.

페이지에서 처음 사용할 때는 GitLab Duo <featurename>를 사용합니다. 2024년 8월 기준으로, GitLab Duo 기능의 이름은 다음과 같습니다:

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

첫 번째 사용 이후에는 GitLab Duo 없이 기능 이름만 사용하세요.

GitLab Duo Enterprise

추가 기능에 대해 항상 GitLab Duo Enterprise를 사용하세요. 법적으로 승인되지 않는 한 Duo Enterprise를 사용하지 마세요.

the GitLab Duo Enterprise add-on (이 대문자 사용으로)이라 할 수 있으나, add-on을 사용할 필요는 없으며 가능하면 생략하세요.

GitLab Duo Pro

추가 기능에 대해 항상 GitLab Duo Pro를 사용하세요. 법적으로 승인되지 않는 한 Duo Pro를 사용하지 마세요.

the GitLab Duo Pro add-on (이 대문자 사용으로)이라 할 수 있으나, add-on을 사용할 필요는 없으며 가능하면 생략하세요.

GitLab Duo Workflow

GitLab Duo Workflow를 사용하세요. 처음 사용한 후에는 Duo Workflow를 사용하세요.

혼자서 Workflow를 사용하지 마세요.

GitLab Flavored Markdown

가능한 경우, GitLab Flavored Markdown을 풀어 쓰세요.

약어를 사용해야 한다면, GFM 대신 GLFM을 사용하세요.

GitLab Helm chart, GitLab chart

GitLab의 클라우드 네이티브 버전을 배포하려면 다음을 사용하세요:

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

the gitlab chart, the GitLab Chart 또는 the cloud-native chart를 사용하지 마세요.

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

설치 방법의 다양성을 설명하는 문맥에서는 different installation methods에서 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를 피하고 대신 specific offering을 참조하세요.

GitLab self-managed

제품 제안을 언급할 때 GitLab self-managed를 사용하세요. 이는 고객이 직접 관리하는 GitLab 인스턴스를 나타냅니다.

GitLab.com

URL이나 제품 제안을 언급할 때 GitLab.com을 사용하세요. GitLab.com은 GitLab에서 관리하는 인스턴스입니다.

GitLab Workflow extension for VS Code

확장 프로그램을 언급할 때 GitLab Workflow extension for VS Code를 사용하세요.

또한 GitLab Workflow for VS Code 또는 GitLab Workflow를 사용할 수 있습니다.

group access token

group access token을 문장 형식으로 사용하세요.

UI를 언급할 때 첫 번째 단어의 앞 글자를 대문자로 작성하세요.

guide

우리는 사용자에게 직접 이야기하고 싶습니다. docs.gitlab.com에서는 페이지 제목의 일부로 guide를 사용하지 마세요.

예: Snowplow Guide. 대신 기능 자체와 사용 방법에 대해 이야기하세요. 예: Use Snowplow to do xyz.

Guest

Guest 역할에 대해 작성할 때:

  • 대문자 G를 사용하세요.
  • 풀어 쓰세요:
    • 사용: if you are assigned the Guest role
    • 대신: if you are a guest
  • Guest 역할이 최소 요구 역할인 경우:
    • 사용: at least the Guest role
    • 대신: the Guest role or higher

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

Guest permissions 사용하지 마세요. Guest 역할이 할당된 사용자는 관련된 권한 집합을 가집니다.

편리함

편리함을 사용하지 마십시오. 사용자가 기능이나 프로세스를 편리하다고 느끼지 못하면 신뢰를 잃게 됩니다. (Vale 규칙: Simplicity.yml)

고가용성, HA

고가용성 또는 HA를 사용하지 마십시오. GitLab 참조 아키텍처에서만 사용합니다. 대신, 사용자 수를 더 많이 처리하도록 GitLab을 구성하는 방법에 대한 자세한 정보는 참조 아키텍처로 안내하십시오.

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

더 높은

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

사용:

  • GitLab 14.4 및 이후 버전에서…

대신:

  • GitLab 14.4 및 더 높은 버전에서…
  • GitLab 14.4 및 그 이상의 버전에서…

누르다

누르다를 버튼을 누르다라는 의미로 사용하지 마십시오.

사용:

  • ENTER를 누르십시오.

대신:

  • ENTER 버튼을 누르십시오.

나

첫 번째 인칭 단수를 사용하지 마십시오. 당신 또는 문구를 다시 작성하여 사용하십시오.

즉

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

하기 위해

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

인덱스, 인디시스

인덱스의 복수형으로 indexes를 사용하십시오.

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

소스에서 설치

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

사용:

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

대신:

  • 소스에서 설치의 경우…

자세한 내용은 다양한 설치 방법을 참조하십시오.

-ing 단어

가능한 한 -ing 단어를 제거하십시오. 번역하기 어려운 경우가 있으며, 더 정확한 용어가 일반적으로 사용 가능합니다. 예를 들어:

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

이슈

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

이슈 보드

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

이슈 설명 생성

이슈 설명 생성의 첫 언급에서 GitLab Duo 이슈 설명 생성을 사용하십시오. 이후에는 이슈 설명 생성만 사용하십시오.

이슈 논의 요약

이슈 논의 요약의 첫 언급에서 GitLab Duo 이슈 논의 요약을 사용하십시오. 이후에는 이슈 논의 요약만 사용하십시오.

이슈 가중치

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

IP 주소

IP 주소를 사용할 때는 인터넷 프로토콜 (IP)과 함께 사용되는 주소를 지칭합니다. IP 주소를 IP라고 언급하지 마세요.

그것

그것이라는 단어를 사용할 때, 그것이 무엇을 지칭하는지 확실히 해야 합니다.

확실하지 않은 경우, 그것 대신 단어를 반복하세요.

사용 예:

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

대신:

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

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

작업

작업이라는 의미로 빌드를 사용하지 마세요. 작업은 .gitlab-ci.yml 파일에서 정의되며 파이프라인의 일부분으로 실행됩니다.

CI와 함께 작업이라는 단어를 사용하고 싶다면, CI/CD 작업이라고 사용하세요. CI 작업이라고 사용하지 마세요.

Kubernetes 실행기

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

이 기능을 언급할 때는 다음을 사용하세요:

  • GitLab Runner를 위한 Kubernetes 실행기
  • Kubernetes 실행기

다음은 사용하지 마세요:

  • GitLab Runner Kubernetes 실행기, 이는 Kubernetes 상표를 침해할 수 있습니다.

나중에

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

사용 예:

  • GitLab 14.1 및 이후 버전에서는…

대신:

  • GitLab 14.1 및 더 높은 버전에서는…
  • GitLab 14.1 및 상위 버전에서는…
  • GitLab 14.1 및 최신 버전에서는…

수준

가능한 경우, 인스턴스, 프로젝트 또는 그룹의 맥락에서 수준이라는 사용을 피하세요.

사용 예:

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

대신:

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

목록

드롭다운 목록을 언급할 때 목록이라는 사용을 피하세요.

대신 전체 문구 드롭다운 목록을 사용하세요.

페이지를 언급할 때도 목록이라는 사용을 피하세요. 예를 들어, 이슈 페이지는 이슈 목록으로 채워집니다. 그러나 이슈 페이지라고 부르고 이슈 목록이라고 부르지 마세요.

라이선스

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

  • 라이선스는 사용자가 구매한 구독에 대한 접근을 허용합니다. 라이선스는 좌석 수 및 구독 날짜와 같은 정보를 포함합니다.
  • 구독은 사용자가 구매하는 구독 수준입니다.

클라우드 라이선스라는 용어는 사용하지 마세요.

다음 용어는 UI와 이메일에 표시됩니다. 필요할 때 사용할 수 있습니다:

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

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

사용 예:

  • 인스턴스에 라이선스를 추가하세요.
  • 구독을 구매하세요.

대신:

  • 라이선스를 구매하세요.
  • 라이선스를 구입하세요.

제한 사항

제한 사항이라는 용어를 사용하지 마세요. 대신 알려진 문제를 사용하세요.

로그인, 로그온

다음은 사용하지 마세요:

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

대신 로그인으로 사용하세요.

그러나 사용자 인터페이스에 로그인이 있다면, UI와 일치시켜야 합니다.

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

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

낮은

버전 번호에 대해 이야기할 때 낮은을 사용하지 마세요.

다음과 같이 사용하세요:

  • GitLab 14.1 및 이전 버전에서.

대신 다음과 같은 표현은 사용하지 마세요:

  • GitLab 14.1 및 낮은 버전에서.
  • GitLab 14.1 및 오래된 버전에서.

머신 러닝

machine learning은 소문자로 사용하세요.

머신 러닝이 형용사로 사용될 때, 예를 들어 머신 러닝 모델과 같이,

하이픈을 사용하지 마세요. 하이픈이 문법적으로 더 정확할 수 있지만, 더 정확하게 하려다 우리는 일관성이 없게 될 위험이 있습니다.

유지 관리자

유지 관리자 역할에 대해 작성할 때:

  • 대문자 M을 사용하세요.
  • 전체 표현을 작성하세요.
    • 사용: 당신이 유지 관리자 역할이 할당된 경우
    • 대신: 당신이 유지 관리자일 경우
  • 유지 관리자 역할이 최소 요구 역할일 때:
    • 사용: 최소한 유지 관리자 역할
    • 대신: 유지 관리자 역할 이상

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

유지 관리자 권한을 사용하지 마세요. 유지 관리자 역할이 할당된 사용자는 관련 권한의 집합을 가집니다.

인류

인류라는 단어를 사용하지 마세요. 대신 사람들 또는 인류를 사용하세요. (Vale 규칙: InclusiveLanguage.yml)

인력

인력이라는 단어를 사용하지 마세요. 노동력이나 GitLab 팀원과 같은 단어를 사용하세요. (Vale 규칙: InclusiveLanguage.yml)

마스터

master라는 단어를 사용하지 마세요. 샘플 기본 브랜치 이름으로 main을 사용하세요.

(Vale 규칙: InclusiveLanguage.yml)

수월함, 가능성

Might는 무언가가 발생할 가능성을 의미합니다. Might는 종종 문제 해결 문서에서 사용됩니다.

May는 무언가를 할 허가를 줍니다. 대신 can을 고려하세요.

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

자세한 내용은 you can을 참조하세요.

사용:

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

대신 다음과 같은 표현은 사용하지 마세요:

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

MB, 메가바이트

MB 및 GB에 대해서는 Microsoft 가이드라인을 따르세요.

구성원

사용자 계정을 그룹이나 프로젝트에 추가할 때,

사용자 계정은 구성원이 됩니다.

병합 커밋 메시지 생성

Merge Commit Message Generation에는 제목 대문자를 사용하세요.

페이지에서 처음 언급할 때는 GitLab Duo Merge Commit Message Generation을 사용하세요.

그 이후에는 Merge Commit Message Generation만 사용하세요.

병합 요청 브랜치

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

병합 요청

병합 요청은 소문자를 사용하세요. 첫 번째 언급 시 MR이라는 약어를 사용할 경우, 전체를 써주세요.

병합 요청 요약

병합 요청 요약에 대해 제목 대문자를 사용하세요.

페이지에서 처음 언급할 때는 GitLab Duo 병합 요청 요약을 사용하세요.

그 이후에는 병합 요청 요약만 단독으로 사용하세요.

마일스톤

마일스톤에 소문자를 사용하세요.

최소 액세스

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

  • 대문자 M과 대문자 A를 사용하세요.
  • 전체를 써주세요:
    • 사용: 최소 액세스 역할이 할당된 경우
    • 대신에: 최소 액세스 사용자인 경우
  • 최소 액세스 역할이 최소 요구 역할일 때:
    • 사용: 최소 액세스 역할 이상
    • 대신에: 최소 액세스 역할 또는 그 이상

굵게 표시하지 마세요.

최소 액세스 권한을 사용하지 마세요. 최소 액세스 역할이 할당된 사용자는 관련된 권한 집합을 가지고 있습니다.

n/a, N/A, not applicable

가능한 경우 not applicable를 사용하세요. 이 문구를 풀어 쓰면 비영어권 사용자가 이해하는 데 도움이 되고, 대문자 일관성 문제를 피할 수 있습니다.

이동

navigate를 사용하지 마세요. 대신 go를 사용하세요. 예를 들어:

  • 이 웹페이지로 이동하세요.
  • 터미널을 열고 runner 디렉토리로 이동하세요.

(Vale 규칙: SubstitutionWarning.yml)

할 필요가 있다

need to를 피하세요, 문장이 길어지기 때문입니다.

예를 들어, 변수가 필수일 때,

변수를 설정해야 합니다 대신에:

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

변수가 권장될 때:

  • 변수를 설정하는 것이 좋습니다.

변수가 선택적일 때:

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

새로운

종종 new라는 단어를 피할 수 있습니다. 객체를 생성할 때 그것은 새롭기 때문에, 추가적인 단어가 필요하지 않습니다.

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

더 새로운

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

다음과 같이 사용하세요:

  • GitLab 14.4 및 이후 버전…

대신에:

  • GitLab 14.4 및 더 높은 버전…
  • GitLab 14.4 및 이상의 버전…
  • GitLab 14.4 및 더 새로운 버전…

일반, 일반적으로

무엇인가를 하는 일반적인, 전형적인 또는 표준 방법을 의미하기 위해 normal을 사용하지 마세요.

대신 다음 용어를 사용하세요:

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

대신에:

  • 일반적으로 인증서를 지정합니다.
  • 일반 Git 워크플로를 따르세요.

(Vale 규칙: Normal.yml)

유의할 점

note that을 사용하지 마세요, 문장이 길어지기 때문입니다.

대신 사용하세요:

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

대신에:

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

제안

현재 제품 제안은 다음과 같습니다:

가용성 세부정보는 이러한 제안을 반영합니다.

오래된

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

사용:

  • GitLab 14.1 및 이전 버전에서.

대신 사용:

  • GitLab 14.1 및 낮은 버전에서.
  • GitLab 14.1 및 오래된 버전에서.

Omnibus GitLab

Linux 패키지를 사용하는 설치 방법에 대해 언급할 때는 그것을 Linux 패키지라고 Refer 합니다.

사용:

  • Linux 패키지를 사용하는 설치의 경우…

대신 사용:

  • Omnibus GitLab을 사용하는 설치의 경우…

자세한 내용은 다양한 설치 방법을 참조하세요.

on

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

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

from이나 in을 사용하지 마십시오. 자세한 내용은 Microsoft 스타일 가이드를 참조하세요.

한 번

단어 한 번은 한 번을 의미합니다. 후 또는 때를 의미하는 데 사용하지 마십시오.

사용:

  • 프로세스가 완료되면…

대신 사용:

  • 프로세스가 완료된 후…

오직

단어 오직은 수정하려는 단어 옆에 두십시오.

다음 예제에서, 오직은 명사 프로젝트를 수정합니다. 의미는 하나의 유형의 프로젝트, 즉 비공개 프로젝트를 생성할 수 있다는 것입니다.

  • 오직 비공식 프로젝트만 만들 수 있습니다.

다음 예제에서, 오직은 동사 생성을 수정합니다. 의미는 다른 작업, 즉 비공식 프로젝트 삭제나 사용자 추가와 같은 작업을 수행할 수 없다는 것입니다.

  • 오직 비공식 프로젝트만 생성할 수 있습니다.

오버라이드

일시적인 대체를 나타내기 위해 오버라이드를 사용하십시오.

예를 들어, 작업이 실행될 때 값이 오버라이드될 수 있습니다. 원래 값은 변경되지 않습니다.

오버라이트

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

예를 들어, 로그 파일이 동일한 이름의 로그 파일을 오버라이트할 수 있습니다.

소유자

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

  • 대문자 O를 사용합니다.
  • 전체적으로 작성합니다.
    • 사용: 당신이 소유자 역할에 배정된 경우
    • 대신에: 당신이 소유자일 경우

굵게 사용하지 마십시오.

소유자 권한을 사용하지 마십시오. 소유자 역할에 배정된 사용자는 관련된 권한 세트를 가지고 있습니다. 소유자는 사용자가 가질 수 있는 가장 높은 역할입니다.

패키지 레지스트리

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

사용:

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

페이지

“문제 페이지에서”와 같은 문구를 작성하는 경우, 페이지에 도달하는 방법에 대한 단계가 가까이에 있어야 합니다. 그렇지 않으면 사람들이 문제 페이지가 무엇인지 모르지 않을 수 있습니다.

페이지 이름은 페이지 상단의 UI에 visible해야 합니다. 그렇지 않은 경우, breadcrumbs에서 이름을 얻을 수 있어야 합니다.

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

  • 테스트 사례 페이지에서, …

부모

항상 복합명사로 사용합니다.

직속 조상 또는 상위를 사용하지 마십시오.

예시:

  • 부모 디렉토리
  • 부모 그룹
  • 부모 프로젝트
  • 부모 커밋
  • 부모 문제
  • 부모 항목
  • 부모 에픽
  • 부모 목표
  • 부모 파이프라인

자세한 내용은 자식 및 하위 그룹을 참조하세요.

권한

역할과 권한을 서로 바꾸어 사용하지 마세요. 각 사용자는 역할이 할당됩니다. 각 역할은 권한 집합을 포함합니다.

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

개인 접근 토큰

개인 접근 토큰은 문장 첫 글자를 대문자로 사용하세요.

UI를 언급할 때 첫 번째 단어는 대문자로 시작하세요.

제발

제품 문서에서는 제발을 사용하지 마세요.

UI 텍스트에서 사용자가 불편을 겪었을 때 제발을 사용하세요. 자세한 내용은 Microsoft 스타일 가이드를 참조하세요.

프리미엄

구독 등급에 대해 프리미엄은 대문자로 사용하세요. 다른 구독 등급과 함께 프리미엄을 언급할 때는 구독 등급 지침을 따르세요.

기본 설정

기본 설정은 테마 및 레이아웃과 같은 사용자별 시스템 수준 설정을 설명하는 데 사용하세요.

전제 조건

사용자가 작업을 수행하기 전에 완료해야 하는 작업 또는 충족해야 하는 조건을 문서화할 때 전제 조건을 사용하세요. 요구 사항은 사용하지 마세요.

전제 조건은 항상 복수형이어야 하며, 항목이 하나만 포함되어 있어도 마찬가지입니다.

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

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

누르기

키보드 키를 언급할 때 누르기를 사용하세요. 예를 들어:

  • 명령을 중지하려면 Control+C를 누르세요.

욕설

욕설은 사용하지 마세요. 이렇게 하면 다른 사용자와 기여자에게 부정적인 영향을 미칠 수 있으며, 이는 GitLab의 다양성, 포용 및 소속감 가치를 위배하는 것입니다.

프로젝트 접근 토큰

프로젝트 접근 토큰은 문장 첫 글자를 대문자로 사용하세요.

UI를 언급할 때 첫 번째 단어는 대문자로 시작하세요.

프로비저닝

클라우드 인프라를 프로비저닝할 때는 프로비저닝이라는 용어를 사용하세요. 인프라를 프로비저닝한 다음 애플리케이션을 배포합니다.

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

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

푸시 규칙

푸시 규칙은 소문자로 사용하세요.

너무

너무라는 단어는 사용하지 마세요 잦은 표현입니다.

README 파일

README 파일 또는 README.md 파일은 백틱과 소문자로 사용하세요.

가능한 경우 전체 구문을 사용하세요: README 파일

복수형의 경우 README 파일들을 사용하세요.

권장, 우리는 권장합니다

우리는 권장합니다 대신 당신은 해야 합니다를 사용하세요. 우리는 사용자를 동료처럼 대화하길 원하며, we와 them 간의 차별화를 피하고자 합니다.

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

자세한 내용은 권장되는 단계를 참조하세요.

등록

계정을 생성할 때는 등록을 사용하세요.

제거

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

객체가 완전히 삭제되면 삭제를 사용하세요.

리포터

리포터 역할에 대해 쓸 때:

  • 대문자 R을 사용하세요.
  • 전부 쓰세요.
    • 사용자가 리포터 역할을 할당받은 경우:
    • 대신: 사용자가 리포터인 경우
    • 리포터 역할이 최소 필수 역할인 경우:
    • 사용하세요: 최소 리포터 역할 이상
    • 대신: 리포터 역할 또는 그 이상

굵게 사용하지 마세요.

리포터 권한은 사용하지 마세요. 리포터 역할이 할당된 사용자는 관련 권한 집합이 있습니다.

Repository Mirroring

Repository Mirroring를 제목 형식으로 사용하세요.

resolution, resolve

문제를 해결하는 솔루션이 문제를 영구적으로 수정할 때 resolution을 사용하세요.

해결책은 일반적으로 문제를 수정하기 위한 파일 및 코드 변경을 포함합니다.

예를 들어:

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

또한 workaround를 참조하세요.

requirements

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

requirements는 사용하지 마세요.

reset

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

respectively

respectively를 피하고 대신 더 정확하게 표현하세요.

다음과 같이 사용하세요:

  • 사용자를 생성하려면 Create user를 선택하세요. 기존 사용자에 대해서는 Save changes를 선택하세요.

다음과 같이 하지 마세요:

  • 새 사용자를 생성하거나 기존 사용자를 편집한 경우 Create user 또는 Save changes를 선택하세요.

restore

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

review app

review app는 소문자로 사용하세요.

roles

사용자는 프로젝트 또는 그룹 에 대한 역할을 가지고 있습니다.

다음과 같이 사용하세요:

  • 그룹에 대해 Owner 역할이 필요합니다.

다음과 같이 하지 마세요:

  • 그룹에 대해 Owner 역할이 필요합니다.

roles와 permissions를 서로 바꾸어 사용하지 마세요. 각 사용자는 역할이 할당됩니다. 각 역할에는 일련의 권한이 포함됩니다.

두 가지 유형의 역할이 있습니다: custom 및 default.

역할은 access levels과 다릅니다.

Root Cause Analysis

Root Cause Analysis를 제목 형식으로 사용하세요.

페이지에 처음 언급할 때는 GitLab Duo Root Cause Analysis를 사용하세요.

그 이후에는 Root Cause Analysis만 사용하세요.

roll back

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

라이선스나 구독에 대해서는 roll back을 사용하지 마세요. 대신 change the subscription tier를 사용하세요.

runner, runners

runners는 소문자로 사용하세요. 이는 CI/CD 작업을 실행하는 에이전트입니다. GitLab Runner 및 이 문제도 참조하세요.

러너를 언급할 때, 고객의 GitLab 인스턴스에 설치된 러너라는 것을 명시해야 하는 경우 self-managed를 사용하세요. self-hosted는 사용하지 마세요.

러너의 범위를 언급할 때는 다음과 같이 사용하세요:

  • project runner: 특정 프로젝트와 연결됨.
  • group runner: 그룹의 모든 프로젝트와 하위 그룹에서 사용 가능.
  • instance runner: GitLab 인스턴스의 모든 그룹과 프로젝트에서 사용 가능.

runner manager, runner managers

runner managers는 소문자로 사용하세요. 이는 자동 스케일링을 위해 여러 러너를 생성할 수 있는 러너 유형입니다. GitLab Runner도 참조하세요.

runner worker, runner workers

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

러너 인증 토큰

러너 인증 토큰을 사용하고, 러너 토큰, 인증 토큰, 토큰과 같은 변형은 사용하지 마세요.

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

GitLab 호스팅 러너, SaaS 러너

Runner SaaS 또는 SaaS 러너를 사용하지 마세요.

GitLab-hosted runners를 GitLab.com 및 GitLab Dedicated에서 호스팅되는 러너를 설명하는 주요 기능 이름으로 사용하세요.

제공 사항 및 운영 체제를 지정하려면 다음을 사용하세요:

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

제공 사항 또는 운영 체제가 없는 호스팅 러너는 사용하지 마세요.

(s)

단어를 선택적으로 복수로 만들기 위해 (s)를 사용하지 마세요. 이는 이해를 저해할 수 있습니다. 예를 들면:

사용하세요:

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

대신에:

  • 원하는 작업(job)(s)을 선택하세요.

어떤 것을 여러 개 선택할 수 있다면, 단어를 복수형으로 작성하세요.

완전성 점검

sanity check를 사용하지 마세요. 대신 완전성 점검을 사용하세요. (Vale 규칙: InclusiveLanguage.yml)

확장성

추가 사용자를 위해 GitLab 성능을 향상시키는 것을 이야기할 때 scalability를 사용하지 마세요. scale 또는 scaling이라는 단어는 가끔 허용되지만, 추가 사용자를 위한 GitLab 성능 향상에 대한 언급은 GitLab 참조 아키텍처 페이지로 독자를 안내해야 합니다.

검색

검색할 때, 왼쪽 사이드바의 검색 상자에 문자열을 입력합니다.

검색 결과는 검색 페이지에 표시됩니다.

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

좌석

구독 청구 모델을 참조할 때:

  • GitLab SaaS의 경우, 좌석을 사용하세요. 고객은 좌석을 구매합니다. 사용자는 일부 예외에 따라 그룹에 초대될 때 좌석을 차지합니다.

  • GitLab 자기 관리의 경우, 사용자를 사용하세요. 고객은 지정된 수의 사용자를 위한 구독을 구매합니다.

섹션

페이지의 영역을 설명할 때 섹션을 사용하세요. 예를 들어, 페이지에 UI를 별도의 영역으로 구분하는 선이 있다면, 이러한 영역을 섹션으로 언급하세요.

우리는 종종 확장 가능/접을 수 있는 영역을 섹션으로 생각합니다. 섹션을 확장하거나 접는 것을 언급할 때 섹션이라는 단어를 포함하지 마세요.

사용하세요:

  • Auto DevOps 확장.

대신에:

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

선택

버튼, 링크, 메뉴 항목 및 목록과 함께 select를 사용하세요. Select는 더 많은 장치에 적용되며, click은 마우스에 더 구체적입니다.

그러나 오른쪽 클릭 및 클릭 투어 데모의 경우 예외를 만들 수 있습니다.

자체 호스팅 모델

고객이 호스팅하는 언어 모델을 지칭할 때는 self-hosted model(소문자)을 사용하세요. 이는 GitLab이 아닌 고객이 호스팅하는 언어 모델을 의미합니다.

언어 모델은 LLM(대형 언어 모델)일 수 있지만, 반드시 그렇지는 않을 수 있습니다.

자체 호스팅 모델

GitLab Duo Self-Hosted Models 기능에 대해 제목 표기법을 사용하세요.

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

이 구문은 기능 이름만 특정하여 언급할 때 적용됩니다.

자체 호스팅 모델에 대해 쓰고 있다면, 제목 표기법을 사용할 필요는 없습니다.

Self-Managed

Self-managed를 사용하여 고객의 GitLab 설치를 지칭합니다. Self-hosted는 사용하지 마세요.

Service Desk

Service Desk는 제목 케이스를 사용하세요.

Setup, Set Up

Setup는 명사로, set up은 동사로 사용합니다. 예를 들어:

  • 귀하의 원격 사무실 setup은 놀랍습니다.
  • 원격 사무실을 올바르게 set up하려면 작업 공간의 인체공학을 고려하세요.

Set up과 configure를 혼동하지 마세요.
Set up은 처음으로 무언가를 하는 것을 의미합니다. 예를 들어:

  1. 설치를 set up하세요.
  2. 설치를 configure하세요.

Settings

Setting은 제품의 기본 동작을 변경합니다. Setting은 일반적으로 하나 이상의 옵션이 있는 레이블로 나타내어지는 키/값 쌍으로 구성됩니다.

Sign In, Sign-In

로그인 행동을 설명하기 위해 사용하세요:

  • sign in.
  • 동사로서의 sign in to. 예: 비밀번호를 사용하여 GitLab에 sign in하세요.

또한 사용할 수 있습니다:

  • sign-in은 명사 또는 형용사로 사용합니다. 예: sign-in page 또는 sign-in restrictions.
  • single sign-on.

사용하지 마세요:

사용자 인터페이스에 다른 단어가 있다면 그 단어를 사용할 수 있습니다.

Sign Up

계정을 생성할 때는 sign up 대신 register를 사용하세요.

Signed-In User, Signed In User

Signed-in user 또는 signed in user 대신 authenticated user를 사용하세요.

Simply, Simple

Simply 또는 simple은 사용하지 마세요. 사용자가 프로세스가 간단하다고 느끼지 않으면, 우리는 그들의 신뢰를 잃습니다. (Vale 규칙: Simplicity.yml)

Since

Since라는 단어는 시간 범위를 나타냅니다. 예를 들어, Since 1984, Bon Jovi has existed. Since를 because의 의미로 사용하지 마세요.

사용하세요:

  • 당신은 Developer 역할을 가지고 있기 때문에, 위젯을 삭제할 수 있습니다.

대신에:

  • 당신은 Developer 역할을 가지고 있기 때문에, 위젯을 삭제할 수 있습니다.

Slashes

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

Slave

Slave는 사용하지 마세요. Secondary와 같은 다른 옵션을 사용하세요. (Vale 규칙: InclusiveLanguage.yml)

Storages

다음 내용과 관련하여:

  • Gitaly에서는 storage가 물리적이어야 하며 storage라고 불려야 합니다.
  • Gitaly Cluster에서는 storage가 다음 중 하나일 수 있습니다:
    • 가상이어야 하며 virtual storage라고 불려야 합니다.
    • 물리적이어야 하며 physical storage라고 불려야 합니다.

Gitaly storages는 물리적 경로를 가지며, virtual storages는 가상 경로를 가집니다.

Subgroup

Subgroup(하이픈 없음)을 사용하고 sub-group는 사용하지 마세요.
하위 그룹을 위한 대체 용어(예: child group 또는 low-level group) 사용을 피하세요.

(Vale 규칙: SubstitutionWarning.yml)

구독 티어

구독 또는 구독 티어를 라이선스와 혼동하지 마십시오.

사용자는 구독을 구매합니다. 그 구독에는 티어가 있습니다.

티어를 설명하려면:

대신 사용 사용하기
무료 티어 이상 모든 티어
무료 티어 이상 모든 티어
프리미엄 티어 이상 프리미엄 및 궁극적인 티어
프리미엄 티어 이상 프리미엄 및 궁극적인 티어
프리미엄 티어 이하 무료 및 프리미엄 티어

추천 리뷰어

추천 리뷰어는 제목 대문자로 사용합니다.

추천 리뷰어는 항상 복수형이어야 하며, 일반적인 경우에도 대문자가 사용됩니다.

예시:

  • 추천 리뷰어는 귀하의 병합 요청을 검토할 사람을 추천할 수 있습니다. (이 문구는 기능을 설명합니다.)
  • 입력 시 추천 리뷰어가 표시됩니다. (이 문구는 일반적이지만 여전히 대문자가 사용됩니다.)

탭

탭 이름은 굵게 사용합니다. 예:

  • 파이프라인 탭
  • 개요 탭

that

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

사용:

  • 저장하는 파일…

대신:

  • 당신이 저장하는 파일…

자세한 내용은 this, these, that, those를 참조하십시오.

터미널

터미널은 소문자로 사용합니다. 예:

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

Terraform 모듈 레지스트리

GitLab Terraform 모듈 레지스트리는 제목 대문자로 사용하지만, 비특정 모듈에 대해 이야기할 때는 소문자 m을 사용합니다. 예:

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

테스트 생성

테스트 생성은 제목 대문자로 사용합니다.

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

그 후에는 테스트 생성만 사용합니다.

텍스트 상자

UI 요소를 언급할 때는 텍스트 상자를 사용하고 필드 또는 상자 대신 사용하십시오.

있다, 존재하다

있다와 존재하다는 사용을 피하십시오. 이 문구는 주어를 숨깁니다.

사용:

  • 버킷에 구멍이 있습니다.

대신:

  • 버킷에 구멍이 존재합니다.

그들

특정 인물을 언급하지 않는 한 성별 특정 대명사의 사용을 피하십시오.

성 중립 대명사로서 단수 그들을 사용하십시오.

this, these, that, those

이러한 단어 뒤에는 항상 명사가 뒤따릅니다. 예:

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

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

  • 사용: 이 바지가 가장 좋습니다.

  • 대신: 이가 가장 좋습니다.

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

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

  • 사용: 그 설정들은 구성해야 합니다. (아니면 더 좋게, 그 설정들을 구성하세요.)
  • 대신: 그것들은 구성해야 합니다.

to which, of which

to which와 of which를 피하고, 문장의 끝에 전치사를 다루도록 합니다. 예시는 전치사를 참조하십시오.

to-do item

소문자와 하이픈을 사용하여 to-do 항목을 작성하십시오. (Vale 규칙: ToDo.yml)

To-Do List

To-Do List에 제목 대문자를 사용하십시오. (Vale 규칙: ToDo.yml)

toggle

토글을 켜거나 끄십시오. 예를 들어:

  • blah 토글을 켭니다.

TFA, two-factor authentication

대신 2FA 및 two-factor authentication를 사용하십시오.

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를 사용하십시오:

  • 더 높은 구독 등급을 선택하는 경우(프리미엄 또는 얼티밋).
  • 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를 참조하십시오.

유용한

유용한을 사용하지 마세요. 사용자가 이 프로세스를 유용하게 느끼지 않으면, 우리는 그들의 신뢰를 잃습니다.

(Vale 규칙: Simplicity.yml)

사용자 계정

사용자 계정을 생성합니다. 사용자 계정은 액세스 수준이 있습니다.

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

사용하는 것

대부분의 경우 사용하는 것을 피하세요. 주제를 숨기고 문장을 번역하기 더 어렵게 만듭니다.

by using, that use 또는 문장을 다시 작성하여 사용하세요.

예를 들어:

  • 대신: 파일이 저장소를 사용하여…

  • 사용: 저장소를 사용하는 파일…

  • 대신: 명령 줄을 사용하여 디렉토리를 변경합니다.
  • 사용: 명령 줄을 사용하여 디렉토리를 변경하세요. 또는 더 나은 방법: 디렉토리를 변경하려면, 명령 줄을 사용하세요.

활용하다

활용하다를 사용하지 마세요. 대신 사용하다를 사용하세요. 이는 더 간결하고 비원어민이 이해하기 더 쉽습니다.

(Vale 규칙: SubstitutionWarning.yml)

버전, v

GitLab의 버전을 설명할 때는 GitLab <버전 번호>를 사용하세요. 예를 들어:

  • GitLab 16.0 이상이어야 합니다.

다른 소프트웨어를 설명할 때도 해당 소프트웨어 문서와 동일한 형식을 사용하세요. 예를 들어:

  • Kubernetes 1.4에서는…

v 문자 뒤에 공간이 없는지 확인하세요. 의미 버전에서는 v 뒤에 공백이 없습니다. 예를 들어:

  • v1.2.3

통해

라틴 약어를 사용하지 마세요. 대신 with, through 또는 by using을 사용하세요.

(Vale 규칙: LatinTerms.yml)

취약점 설명

취약점 설명에 제목 케이스를 사용하세요.

페이지에서 처음 언급할 때는 GitLab Duo 취약점 설명을 사용하세요.

그 이후로는 취약점 설명만 사용하세요.

취약점 해결

취약점 해결에 제목 케이스를 사용하세요.

페이지에서 처음 언급할 때는 GitLab Duo 취약점 해결을 사용하세요.

그 이후로는 취약점 해결만 사용하세요.

우리

우리를 피하고 대신 사용자가 GitLab에서 무언가를 수행하는 방법에 집중하세요.

사용:

  • 작업을 정리해야 할 때 위젯을 사용하세요.

대신:

  • 사용자를 위해 위젯을 추가하는 기능을 만들었습니다.

우회 방법

문제 해결 솔루션이 임시 해결책인 경우 우회 방법을 사용하세요.

우회 방법은 일반적으로 즉각적인 해결책이며 지속적인 문제가 있을 수 있습니다.

예를 들어:

  • 우회 방법은 임시로 템플릿을 이전 버전에 고정하는 것입니다.

해결도 참조하세요.

동안

동안은 시간에 발생하는 것만 언급하는 데 사용하세요. 예를 들어,

프로세스가 실행되는 동안 창을 열어두세요.

비교를 위해 동안을 사용하지 마세요. 예를 들어,

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

대신:

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

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

동안

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

허용 목록

whitelist를 사용하지 마세요. 다른 옵션으로는 allowlist가 있습니다. (Vale 규칙: InclusiveLanguage.yml)

안에

가능한 경우 within 대신 in을 사용하세요. 단, 시간 프레임, 한계 또는 경계를 설명할 때는 제외합니다. 예를 들어:

  • 업그레이드는 4시간의 유지보수 시간 안에 발생합니다.
  • Wi-Fi 신호는 30피트 반경 내에서 접근할 수 있습니다.

(Vale 규칙: SubstitutionWarning.yml)

아직

제품이나 그 기능에 대해 이야기할 때는 yet를 사용하지 마세요. 문서는 현재의 제품을 설명합니다.

때때로 작업을 작성할 때 yet를 사용할 필요가 있을 수 있습니다. yet를 사용할 경우, 주변 구문이 현재 시제와 능동태로 작성되도록 하세요.

미래 기능에 대해 작성하는 방법에 대한 안내를 보세요.

당신, 당신의, 당신의 것

the user, the administrator 또는 the customer 대신 you를 사용하세요.

문서는 직접적으로 사용자에게 이야기해야 합니다. 이 사용자는 제품을 설치하는 사람, 구성하는 사람, 관리하는 사람 또는 사용하는 사람일 수 있습니다.

사용 예:

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

대신:

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

당신은 할 수 있습니다

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

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

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

  • 코드 검토 분석을 사용하여 병합 요청당 메트릭을 볼 수 있습니다. API도 사용할 수 있습니다.
  • 이름과 값 쌍을 입력하세요. 스트리밍 대상당 최대 20쌍을 추가할 수 있습니다.