# SOME DESCRIPTIVE TITLE.
# Copyright (C) 2023, Xorbits Inc.
# This file is distributed under the same license as the Xinference package.
# FIRST AUTHOR <EMAIL@ADDRESS>, 2024.
#
#, fuzzy
msgid ""
msgstr ""
"Project-Id-Version: Xinference\n"
"Report-Msgid-Bugs-To: \n"
"POT-Creation-Date: 2024-03-07 15:03+0800\n"
"PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n"
"Last-Translator: FULL NAME <EMAIL@ADDRESS>\n"
"Language-Team: ko <LL@li.org>\n"
"Language: ko\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=utf-8\n"
"Content-Transfer-Encoding: 8bit\n"
"Plural-Forms: nplurals=1; plural=0;\n"
"Generated-By: Babel 2.18.0\n"

#: ../../source/development/contributing_codebase.rst:3
msgid "Contributing to the code base"
msgstr "코드 라이브러리 개발 가이드"

#: ../../source/development/contributing_codebase.rst:6
msgid "Table of contents:"
msgstr "목차"

#: ../../source/development/contributing_codebase.rst:9
msgid "Code standards"
msgstr "코드 규범"

#: ../../source/development/contributing_codebase.rst:11
msgid ""
"Writing good code is not just about what you write. It is also about *how* "
"you write it. During Continuous Integration testing, several tools will be "
"run to check your code for stylistic errors. Good style is a requirement for"
" submitting code to Xinference."
msgstr ""
"좋은 코드를 작성하는 것은 단순히 무엇을 썼는지뿐만 아니라, 어떻게 작성했는지에도 달려 있습니다. 지속적 통합 테스트 중에는 여러 도구가"
" 코드의 스타일 오류를 검사합니다. 좋은 프로그래밍 스타일은 Xinference에 코드를 제출하기 위한 요구 사항 중 하나입니다."

#: ../../source/development/contributing_codebase.rst:15
msgid ""
"In addition, it is important that we do not make sudden changes to the code "
"that could have the potential to break a lot of user code as a result. "
"Therefore we need it to be as backwards compatible as possible to avoid mass"
" breakages."
msgstr ""
"또한, 코드에 갑작스러운 변경을 가하지 마십시오. 이는 많은 사용자 코드에 문제를 일으킬 수 있습니다. 따라서 대규모 장애를 방지하기 "
"위해 가능한 한 하위 호환성을 유지해야 합니다."

#: ../../source/development/contributing_codebase.rst:20
msgid "Autofixing formatting errors"
msgstr "자동 수정 포맷 오류"

#: ../../source/development/contributing_codebase.rst:22
msgid ""
"Moreover, Continuous Integration will run code formatting checks like "
"``black``, ``flake8``, ``isort``, and others using `pre-commit hooks "
"<https://pre-commit.com/>`_ Any warnings generated by these checks will "
"cause the Continuous Integration to fail. Therefore, it is advisable to run "
"the check yourself before submitting code. This can be done by installing "
"``pre-commit``::"
msgstr ""
"또한, 지속적 통합(CI)은 `pre-commit hooks <https://pre-commit.com/>`_ 을 사용하여 ``black``, ``flake8``, ``isort`` 등과 같은 코드 포맷 검사 도구를 실행합니다. 이러한 검사에서 생성된 모든 경고는 지속적 통합을 실패하게 만듭니다. 따라서, 코드를 커밋하기 전에 이러한 검사를 직접 실행하는 것이 좋습니다. Xinference 저장소의 루트 디렉터리에서 ``pre-commit``을 설치하여 이를 수행할 수 있습니다::"

#: ../../source/development/contributing_codebase.rst:30
msgid "and then running::"
msgstr "그런 다음 명령을 실행하십시오::"

#: ../../source/development/contributing_codebase.rst:34
msgid ""
"from the root of the Xinference repository. This setup ensures that all "
"styling checks are automatically executed each time you commit changes "
"without your needing to run each one manually. In addition, using ``pre-"
"commit`` will also allow you to more easily remain up-to-date with our code "
"checks as they change."
msgstr ""
"설치가 완료되면 매번 변경 사항을 커밋할 때 모든 스타일 검사가 자동으로 실행되어 수동으로 하나씩 실행할 필요가 없습니다. 또한 "
"``pre-commit``을 사용하면 코드 검사가 변경될 때 쉽게 동기화 상태를 유지할 수 있습니다."

#: ../../source/development/contributing_codebase.rst:39
msgid ""
"Note that if needed, you can skip these checks with ``git commit --no-"
"verify``."
msgstr "참고로, 필요 시 ``git commit --no-verify`` 명령어를 사용하여 이러한 검사를 건너뛸 수 있습니다."

#: ../../source/development/contributing_codebase.rst:41
msgid ""
"If you don't want to use ``pre-commit`` as part of your workflow, you can "
"still use it to run its checks with::"
msgstr "``pre-commit``를 워크플로의 일부로 포함하지 않으려면, 다음 명령을 실행하여 검사를 수행할 수 있습니다::"

#: ../../source/development/contributing_codebase.rst:46
#: ../../source/development/contributing_codebase.rst:52
msgid "without needing to have done ``pre-commit install`` beforehand."
msgstr "사전에 ``pre-commit install``을 실행할 필요가 없습니다."

#: ../../source/development/contributing_codebase.rst:48
msgid ""
"If you want to run checks on all recently committed files on upstream/main "
"you can use::"
msgstr "모든 최근에 제출된 파일에 대해 검사를 실행하려면 다음 명령을 사용할 수 있습니다::"

#: ../../source/development/contributing_codebase.rst:56
msgid ""
"You may consider periodically running ``pre-commit gc`` to clean up repos "
"which are no longer used."
msgstr ""
"정기적으로 ``pre-commit gc`` 명령을 실행하여 더 이상 사용되지 않는 저장소를 정리하는 것을 고려할 수 있습니다."

#: ../../source/development/contributing_codebase.rst:61
msgid ""
"If you have conflicting installations of ``virtualenv``, if could lead to "
"errors - refer to `here <https://github.com/pypa/virtualenv/issues/1875>`_."
msgstr ""
"만약 충돌하는 ``virtualenv`` 버전을 설치했다면 오류가 발생할 수 있습니다 - `여기 "
"<https://github.com/pypa/virtualenv/issues/1875>`_ 를 참조하세요."

#: ../../source/development/contributing_codebase.rst:64
msgid ""
"Also, due to a `bug in virtualenv "
"<https://github.com/pypa/virtualenv/issues/1986>`_, you may run into issues "
"if you're using conda. To solve this, you can downgrade ``virtualenv`` to "
"version ``20.0.33``."
msgstr ""
"또한, ``virtualenv``의 `버그 <https://github.com/pypa/virtualenv/issues/1986>`_ 로"
" 인해 conda를 사용하는 경우 문제가 발생할 수 있습니다. 이 문제를 해결하려면 ``virtualenv``를 버전 "
"``20.0.33``으로 다운그레이드하면 됩니다."

#: ../../source/development/contributing_codebase.rst:69
msgid "Backwards compatibility"
msgstr "하위 호환성"

#: ../../source/development/contributing_codebase.rst:71
msgid ""
"Please try to maintain backward compatibility. If you think breakage is "
"necessary, clearly state why as part of the pull request. Also, be careful "
"when changing method signatures and add deprecation warnings where needed. "
"Also, add the deprecated sphinx directive to the deprecated functions or "
"methods."
msgstr ""
"가능한 한 하위 호환성을 유지하세요. 변경이 반드시 필요하다고 판단되면, 풀 리퀘스트에서 그 이유를 명확히 설명하세요. 또한, 메서드 "
"시그니처를 변경할 때는 주의하고, 필요 시 폐기 경고를 추가하세요. 아울러, 폐기된 함수나 메서드에는 sphinx 지시어를 추가하세요."

#: ../../source/development/contributing_codebase.rst:76
msgid "You'll also need to"
msgstr "또한 당신은 ~해야 합니다."

#: ../../source/development/contributing_codebase.rst:78
msgid ""
"Write a new test that asserts a warning is issued when calling with the "
"deprecated argument"
msgstr "새로운 테스트 샘플을 작성하여, 더 이상 사용되지 않는 매개변수를 호출할 때 경고가 발생하도록 합니다."

#: ../../source/development/contributing_codebase.rst:79
msgid ""
"Update all of Xinference existing tests and code to use the new argument"
msgstr "모든 Xinference 기존 테스트 샘플과 코드를 새로운 파라미터를 사용하도록 업데이트하십시오."

#: ../../source/development/contributing_codebase.rst:82
msgid "Type hints"
msgstr "Type Hint"

#: ../../source/development/contributing_codebase.rst:84
msgid ""
"Xinference strongly encourages the use of :pep:`484` style type hints. New "
"development should contain type hints and pull requests to annotate existing"
" code are accepted as well!"
msgstr ""
"Xinference는 :pep:`484` 스타일의 타입 힌트 사용을 강력히 권장합니다. 새로운 개발에는 타입 힌트를 포함해야 하며, 기존"
" 코드에 주석을 추가하는 풀 리퀘스트도 환영합니다!"

#: ../../source/development/contributing_codebase.rst:88
msgid "Test-driven development"
msgstr "테스트 주도 개발"

#: ../../source/development/contributing_codebase.rst:90
msgid ""
"Xinference is serious about testing and strongly encourages contributors to "
"embrace `test-driven development (TDD) <https://en.wikipedia.org/wiki/Test-"
"driven_development>`_. This development process \"relies on the repetition "
"of a very short development cycle: first the developer writes an (initially "
"failing) automated test case that defines a desired improvement or new "
"function, then produces the minimum amount of code to pass that test.\" So, "
"before actually writing any code, you should write your tests. Often the "
"test can be taken from the original GitHub issue. However, it is always "
"worth considering additional use cases and writing corresponding tests."
msgstr ""
"Xinference는 테스트를 매우 중요하게 여기며, 기여자들이 `테스트 주도 개발(TDD) "
"<https://en.wikipedia.org/wiki/Test-driven_development>`_ 을 채택할 것을 적극 권장합니다."
" 이 개발 프로세스는 \"매우 짧은 개발 주기의 반복에 의존합니다: 먼저, 개발자는 필요한 개선 사항이나 새로운 기능을 정의하는 "
"(초기에는 실패하는) 자동화된 테스트 샘플을 작성하고, 그런 다음 최소한의 코드로 해당 테스트를 통과시킵니다.\" 따라서 실제로 코드를 "
"작성하기 전에 테스트 샘플을 먼저 작성해야 합니다. 일반적으로 테스트 샘플은 원래의 GitHub 이슈에서 얻을 수 있습니다. 그러나 "
"추가적인 경우를 고려하고 그에 맞는 테스트 샘플을 작성하는 것도 가치가 있습니다."

#: ../../source/development/contributing_codebase.rst:99
msgid ""
"Adding tests is frequently requested after code is pushed to Xinference. "
"Thus, it is worth getting in the habit of writing tests ahead of time so "
"this is never an issue."
msgstr ""
"코드를 Xinference에 푸시한 후에는 테스트 샘플을 추가하라는 요청을 자주 받게 됩니다. 따라서 미리 테스트 샘플을 작성하는 습관을"
" 들이는 것이 문제를 예방하는 데 매우 중요합니다."

#~ msgid "Pre-commit"
#~ msgstr "Pre-commit"
