Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Settings and initial contents for Korean localization #291

Merged
merged 3 commits into from
Jan 14, 2022
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
9 changes: 9 additions & 0 deletions config.toml
Original file line number Diff line number Diff line change
Expand Up @@ -58,6 +58,7 @@ description = "The CNCF Cloud Native Glossary Project is intended to be used as
languageName ="English"
# Weight used for sorting.
weight = 1

#[languages.no]
#title = "CNCF Glossary"
#description = "Docsy er operativsystem for skyen"
Expand All @@ -66,6 +67,14 @@ weight = 1
#time_format_default = "02.01.2006"
#time_format_blog = "02.01.2006"

[languages.ko]
title = "클라우드 네이티브(Cloud Native) 용어집"
description = "CNCF 클라우드 네이티브 용어집 프로젝트는 클라우드 네이티브 애플리케이션을 주제로 대화를 나눌 때 참조할 수 있는 공통의 용어 제공을 목표로 한다."
languageName ="한국어(Korean)"
contentDir = "content/ko"
weight = 2


[markup]
[markup.goldmark]
[markup.goldmark.renderer]
Expand Down
24 changes: 24 additions & 0 deletions content/ko/_index.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,24 @@

---
title: "클라우드 네이티브 용어집"
---

# 클라우드 네이티브 용어집

클라우드 네이티브 용어집(Cloud Native Glossary)은 CNCF 비지니스 벨류 서브커미티(BVS, Business Value Subcommittee)가 주도하는 프로젝트다. 이 프로젝트의 목적은 사전 기술 지식이 없이도 명확하고 간단한 언어로 클라우드 네이티브 개념을 설명하는 것이다. [여기서 PDF 버전을 보거나 다운로드할 수 있음(영문)](https://github.com/cncf/glossary/blob/main/cloudnative-glossary.pdf).

## 기여하기
네이티브 용어집에 대한 변경, 추가 및 개선은 모든 사람에게 열려있다. 우리는 이 공유된 어휘(lexicon)를 개발 및 개선하기 위해서 CNCF가 관리하는 커뮤니티-주도 프로세스를 사용한다. 이 용어집은 클라우드 네이티브 기술들에 대한 공유 어휘를 관리하기 위해서 벤더-중립적 플랫폼을 제공한다. 본 프로젝트의 목적과 헌장(charter)을 준수하는 모든 참여자의 기여를 환영한다.

기여를 하고 싶은 사람은 GitHub 이슈를 제출하거나 풀 리퀘스트(pull request)를 생성하면 된다. 더 자세한 정보는 [기여 방법](/ko/contribute/)을 확인하길 바라며 [스타일 가이드](/ko/style-guide/)를 준수가 필요하다.

## 감사의 글

클라우드 네이티브 용어집은 CNCF 마케팅 커미티(CNCF Marketing
Committee) (비지니스 벨류 서브커미티)를
포함한 [Catherine Paganini](https://www.linkedin.com/in/catherinepaganini/en/), [Chris Aniszczyk](https://www.linkedin.com/in/caniszczyk/),
[Daniel Jones](https://www.linkedin.com/in/danieljoneseb/?originalSubdomain=uk), [Jason Morgan](https://www.linkedin.com/in/jasonmorgan2/), [Katelin Ramer](https://www.linkedin.com/in/katelinramer/), [Mike Foster](https://www.linkedin.com/in/mfosterche/?originalSubdomain=ca) 기여자의 기여를 통해서 개시되었다.

## 라이선스

모든 코드 기여는 Apache 2.0 라이선스 하에 있다. 문서는 CC BY 4.0에 따라 배포된다.
17 changes: 17 additions & 0 deletions content/ko/cloud_native_tech.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,17 @@
---
title: 클라우드 네이티브 기술
status: Completed
category: 개념
---

## 개념

클라우드 네이티브 스택(the cloud native stack)이라고도 하는 클라우드 네이티브 기술은 [클라우드 네이티브 애플리케이션](/cloud_native_apps/)을 구축하는 데 사용되는 기술이다. 조직이 퍼블릭, 프라이빗 및 하이브리드 클라우드와 같은 현대적이고 역동적인 환경에서 확장 가능한 애플리케이션을 구축 및 실행할 수 있도록 함으로써, '클라우드의 약속(promise of the cloud)'을 지키고 클라우드 컴퓨팅 이점을 최대한 활용하게 한다. 이 기술은 클라우드 컴퓨팅 및 컨테이너, 서비스 메시(mesh), 마이크로서비스(microservices), 이뮤터블 인프라(immutable infrastructure)의 특징 및 기능(capabilities)을 활용하도록 처음부터 설계되었다.

## 다루는 문제

클라우드 네이티브 스택에는 다양한 기술 범주를 포함하며 다양한 문제를 해결한다. [CNCF 클라우드 네이티브 랜드스케이프(Cloud Native Landscape)](https://landscape.cncf.io/)를 보면 얼마나 다양한 영역을 다루는지 알 수 있다. 그러나 전체적으로 보면, 기존 IT 운영 모델의 단점을 해결한다는 한 가지 주요 문제 해결을 목표로 한다. 이러한 도전적 문제((challenges)에는 확장 가능하고(creating scalable), 내결함성(fault-tolerant)이 있으며 자가 복구 가능한(self-healing) 애플리케이션을 생성하는 문제들뿐만 아니라, 상호 비효율적인 자원 활용 문제도 포함한다.

## 문제 해결 방식

각 기술들은 각자 매우 특정한 문제를 해결하는 반면, 그룹 형태의 클라우드 네이티브 기술은 탄력적(resilient)이고 관리 가능(manageable)하며 관찰 가능(observable)한 상호 느슨하게 결합된 시스템(loosely coupled systems)을 제공한다. 이 기술은 강건한(robust) 자동화와 결합하여, 엔지니어가 최소한의 노력으로 빈번하고 영향이 큰 변경을 예측 가능한 방식으로 수행할 수 있도록 한다. 클라우드 네이티브 시스템의 바람직한 특성은 클라우드 네이티브 스택을 통해서 더 쉽게 달성할 수 있다.
42 changes: 42 additions & 0 deletions content/ko/contribute/_index.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,42 @@
---
title: 기여 방법
toc_hide: true
menu:
main:
weight: 10
pre: <i class='fas fa-pen-square'></i>
---

All the content for the Cloud Native Glossary is stored in [this GitHub repo](https://github.com/cncf/glossary). You'll find there a list of [issues](https://github.com/cncf/glossary/issues), [PRs](https://github.com/cncf/glossary/pulls), and [discussions](https://github.com/cncf/glossary/discussions) about the glossary.

## General guidelines
To propose specific changes to a glossary entry, edit that entry in your branch and issue a pull request. To request that an entry be clarified, updated, or reconsidered, you may alternatively open an issue. To propose a new entry to the glossary, either create an issue or, if you have the definition drafted, add the entry to your branch and create a pull request.


## Issues

Please jump in and help us out by reviewing [open issues](https://github.com/cncf/glossary/issues) and making pull requests to resolve them. The easiest ones have been marked with the “good first issue” or “help wanted” tags. Choose one that hasn't already been assigned to someone:

![issues](/images/how-to/3.png)

Other that haven't yet been assigned may have been "claimed" by someone. Click on the issue to learn more about it. The example below is already claimed:

![claims](/images/how-to/4.png)

You can submit a new issue by clicking "Report issue" in the right sidebar of any page in the Glossary.

## Updating a term (aka submitting a PR)
Follow these steps to update a glossary entry:
1. Navigate to the term you'd like to edit
2. Click "Edit this page" link in the right sidebar
3. Create your own fork of the repository
3. Make your changes to the content
5. Create a pull request

Please title your pull requests appropriately, summing up what your commits are about. Also, please raise separate pull requests for each change as this makes it easier to discuss and shepherd updates in self-contained units. Provide links to third-party uses that support your issue or pull request. After successfully submitting your PR, you should see it here:

![success](/images/how-to/5.png)

If you run into problems please reach out on [Slack](https://slack.cncf.io/) in the #marketing-business-value channel. We'll be happy to help!

See the [Style Guide](/style-guide) for information on the format and style of glossary entries.
104 changes: 104 additions & 0 deletions content/ko/style-guide/_index.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,104 @@
---
title: 스타일 가이드
toc_hide: true
menu:
main:
weight: 10
pre: <i class='fas fa-ruler-horizontal'></i>
---

The following style guide is designed to help you understand the glossary definition structure and maintain a consistent style throughout.

The Cloud Native Glossary follows the [default style guide](https://github.com/cncf/foundation/blob/master/style-guide.md) located in the CNCF's repository. Additionally it follows the following rules:

1. [Avoid colloquial language](https://en.wikipedia.org/wiki/Colloquialism)
2. [Use literal and concrete language](http://guidetogrammar.org/grammar/composition/abstract.htm)
3. [Omit contractions](https://en.wikipedia.org/wiki/Contraction_(grammar))
4. [Use passive voice sparingly](https://www.ef.com/ca/english-resources/english-grammar/passive-voice/)
5. [Aim to phrase statements in a positive form](https://examples.yourdictionary.com/positive-sentence-examples.html)
6. [No exclamation marks outside of quotations](https://www.grammarly.com/blog/exclamation-mark/)
7. Do not exaggerate
8. Avoid repetition
9. Be concise

## Definition Template

Each glossary term is stored in a markdown file and follows this template:

```md
---
title:
status:
category:
---

## What it is

A quick summary of the technology or concept.

## Problem it addresses

A few lines about the problem it's addressing.

## How it helps

A few lines on how the thing solves the problem.
```

### Title

The **title** label will always be at the top of a definition layout and its value should be in title case.

```md
---
title: Definition Template
```

### Status

The **status** label will come after the title label. The status label indicates whether definitions are thoroughly vetted or require more effort.

Valid values are:

- Completed
- Feedback Appreciated
- Not Started

You can always open an issue against a completed definition. While a definition is in flux, its status will be changed to *Feedback Appreciated*.

```md
---
title: Definition Template
status: Feedback Appreciated
```

### Category

The **category** label will come after the status label. Its value should be one of the following values:

- Technology
- Property
- Concept

```md
---
title: Definition Template
status: Feedback Appreciated
category: Concept
---
```

### Definition

The definition contains three subheadings to give the readers context: "What it is", "Problem it addresses", and "How it helps". All three are required for terms in the Technology and Concept categories, however, Property definitions do not require these headings. 


## Audience

The glossary is for a technical AND non-technical audience. So please ensure definitions are explained in simple terms and don't assume technical knowledge. When appropriate, use real-world examples that help readers (especially non-technical readers) better understand when and why the concept you're explaining is relevant. Also, link directly to glossary terms when used in your definition (only the first mention should be hyperlinked) and make sure to run your text through a spell check program.

As an example, take a look at the "What it is" section of the [service mesh definition](/service_mesh). It links back to the microservices, service, reliability, and observability definitions and uses a real-world example so (non-technical) readers can better relate to network challenges (comparing it to a wifi network everyone is familiar with).

Before getting started, please read some of the published terms on this site so you get a feeling for the level of detail and difficulty as well as when examples are appropriate.

The definition of a term should be based on empirical evidence of contemporary usage as published in literature, academic articles, talks, and white papers. In some cases, a term will suffer from conflation, imprecise usage, or, even worse, outright conflicting definitions. In these cases, the Glossary Committers will consider proposed clarifications or focused definitions on a case-by-case basis.
61 changes: 61 additions & 0 deletions i18n/ko.toml
Original file line number Diff line number Diff line change
@@ -0,0 +1,61 @@


# UI strings. Buttons and similar.

[ui_pager_prev]
other = "이전"

[ui_pager_next]
other = "다음"

[ui_read_more]
other = "더 읽기"

[ui_search]
other = "이 사이트 검색하기…"

# Used in sentences such as "Posted in News"
[ui_in]
other = "내부"

# Used in sentences such as "All Tags"
[ui_all]
other = "모든"

# Footer text
[footer_all_rights_reserved]
other = "All Rights Reserved"

[footer_privacy_policy]
other = "개인 정보 처리 방침"


# Post (blog, articles etc.)
[post_byline_by]
other = "의해서"
[post_created]
other = "생성된"
[post_last_mod]
other = "최근 수정"
[post_edit_this]
other = "이 페이지 수정하기"
[post_create_child_page]
other = "하부 페이지 생성하기"
[post_create_issue]
other = "이슈 리포트하기"
[post_create_project_issue]
other = "프로젝트 이슈 생성하기"
[post_posts_in]
other = "포스트된 곳"
[post_reading_time]
other = "읽은 시간(분)"

# Print support
[print_printable_section]
other = "이 섹션을 다중 페이지로 프린트할 수 있는 화면 보기."
[print_click_to_print]
other = "프린트하기"
[print_show_regular]
other = "일반 화면으로 돌아가기"
[print_entire_section]
other = "전체 섹션 프린트하기"