From f5fb07c72bc7d01b470ecb71a655a9a62c2473dd Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?=EA=B3=A0=EC=A2=85=ED=99=98?= <jonghwankoh@ajou.ac.kr> Date: Sat, 23 Dec 2023 02:56:43 +0900 Subject: [PATCH] =?UTF-8?q?=EA=B8=B0=EB=A7=90=20=EB=B3=B4=EA=B3=A0?= =?UTF-8?q?=EC=84=9C=20=EC=B4=88=EC=95=88=20=EC=9E=91=EC=84=B1?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- README.md | 119 +++++++++++++++++++----------------------------------- 1 file changed, 41 insertions(+), 78 deletions(-) diff --git a/README.md b/README.md index dfb4341..d6ce777 100644 --- a/README.md +++ b/README.md @@ -1,92 +1,55 @@ -# foss-final +# 오픈소스SW입문 기말과제 보고서 +201920710 고종환 +get GNU/Linux!라는 웹사이트를 webslate에서 번역 기여하였다. -## Getting started +## 동기 +기말 과제를 위한 주제를 webslate에서 탐색하다가 이 웹사이트를 발견하였다. +리눅스 기반의 자유 오픈소스 OS에는 어떤 것이 있고 어떤 장단점이 있을지 흥미가 생겼기 때문에 이 사이트에 본격적으로 알아보고 내용을 읽어보았다. +확인해보니 이 웹사이트는 의외로 어떻게 그누 리눅스 기반 자유 오픈소스 운영체제를 다운로드하고 소개하는 것에 그치는 수준이 아니라 다양하고 유용한 정보를 제공해주는 사이트였다. -To make it easy for you to get started with GitLab, here's a list of recommended next steps. +특히 오픈소스 OS와 관련해서 현재 윈도우 OS가 가지는 단점과 자유 오픈소스 소프트웨어의 장점과 의의 그리고 여러가지 이슈들에 대해 상세하게 설명되어 있는 점이 정말 유익했다. -Already a pro? Just edit this README.md and make it your own. Want to make it easy? [Use the template at the bottom](#editing-this-readme)! +평소에 자유 오픈소스 소프트웨어 운동에 대해 흥미를 갖고 있고, 많은 사람들이 알았으면 좋겠다고 생각했기 때문에 이 웹사이트를 번역하는 것이 정말 좋겠다고 생각했다. +이 웹사이트를 번역하게 되면 많은 사람들이 리눅스와 오픈소스 소프트웨어의 가치에 대해 더 잘 이해할 수 있게 될 수 있을 것이라고 생각했다. -## Add your files +그러나 내용이 생각보다 방대하고 아직 한국어 번역에 대한 진행사항이 존재하지 않아 무려 9889 단어를 번역해야하는 것이 문제였다. +현실적으로 이 내용을 전부 커버하기는 힘들어서 우선순위가 높은 내용을 약 50%를 채우는 것으로 목표했다. -- [ ] [Create](https://docs.gitlab.com/ee/user/project/repository/web_editor.html#create-a-file) or [upload](https://docs.gitlab.com/ee/user/project/repository/web_editor.html#upload-a-file) files -- [ ] [Add files using the command line](https://docs.gitlab.com/ee/gitlab-basics/add-file.html#add-a-file-using-the-command-line) or push an existing Git repository with the following command: +## 발생했던 문제점 -``` -cd existing_repo -git remote add origin https://git.ajou.ac.kr/jonghwan/foss-final.git -git branch -M main -git push -uf origin main -``` +1) 번역 분량 +번역할 내용이 생각보다 방대하고 아직 한국어 번역에 대한 진행사항이 존재하지 않아 무려 9889 단어를 번역해야하는 것이 문제였다. +현실적으로 이 내용을 전부 커버하기는 힘들어서 우선순위가 높은 내용을 약 50%를 채우는 것으로 목표했다. -## Integrate with your tools +2) 원문 유지의 적절 +예를들어, Trusted computing이라는 용어를 번역할 때 고민이 되었는데, 생소한 용어라 한국어로 번역하는 것이 이해를 도울 것 같았지만, +"신뢰할 수 있는 컴퓨팅"이라고 번역하기에는 완전한 명사형으로 떨어지는 단어가 아니라서 오히려 오해를 불러일으키게 되는 것 같다. +결국 원문을 유지하여 Trusted Computing으로 하기로 했었다. -- [ ] [Set up project integrations](https://git.ajou.ac.kr/jonghwan/foss-final/-/settings/integrations) +3) 자연스러운 맥락 전달 +다양한 문장을 하면서 한국어에서는 거의 쓰지 않은 다양한 표현을 번역하는 것이 조금 난감했다. +영어와 한글이 때로는 같은 뉘앙스나 자연스러움으로 전달되기 매우 어렵다는 것을 깨달았고 번역의 퀄리티를 충족시키면서 번역하는 것이 매우 어려운 작업임을 느꼈다. -## Collaborate with your team +4) 용어의 통일성 +같은 단어를 다르게 번역하는 실수가 간혹 발생하게 되는 것이 문제였다. 또한, 다른 사람이 번역할 때 같은 용어를 다른 사람이 번역하게 될 가능성이 높다는 것을 느꼈다. +이것을 방치하면 번역의 퀄리티를 낮춰 이용자에게 혼란을 줄 수 있으므로 webslate의 용어집을 활용하여 혼란을 줄만한 단어 번역 사례를 용어집으로 정리했다. -- [ ] [Invite team members and collaborators](https://docs.gitlab.com/ee/user/project/members/) -- [ ] [Create a new merge request](https://docs.gitlab.com/ee/user/project/merge_requests/creating_merge_requests.html) -- [ ] [Automatically close issues from merge requests](https://docs.gitlab.com/ee/user/project/issues/managing_issues.html#closing-issues-automatically) -- [ ] [Enable merge request approvals](https://docs.gitlab.com/ee/user/project/merge_requests/approvals/) -- [ ] [Set auto-merge](https://docs.gitlab.com/ee/user/project/merge_requests/merge_when_pipeline_succeeds.html) +5) 배경지식의 필요 +실제로 배경지식을 알아야 정확한 해석을 할 수 있는 문제가 있었는데 이를 해결하기 위해 자료조사를 하여 해당 내용을 이해하여 더 정확한 번역을 할 수 있게 되었다. +예를들어... -## Test and Deploy +6) +자연스러운 문장 구조의 구성으로 맞추는 것이 맞을 지 어색하더라도 최대한 원본 형식에 맞추는 것이 맞을지 고민하는 경우 등이 있었다. +이러한 경우 실제로 mdn, 위키 등의 번역된 문서를 참조하면서 일반적으로 사용되는 스타일에 맞게 작성하도록 노력했다. -Use the built-in continuous integration in GitLab. - -- [ ] [Get started with GitLab CI/CD](https://docs.gitlab.com/ee/ci/quick_start/index.html) -- [ ] [Analyze your code for known vulnerabilities with Static Application Security Testing(SAST)](https://docs.gitlab.com/ee/user/application_security/sast/) -- [ ] [Deploy to Kubernetes, Amazon EC2, or Amazon ECS using Auto Deploy](https://docs.gitlab.com/ee/topics/autodevops/requirements.html) -- [ ] [Use pull-based deployments for improved Kubernetes management](https://docs.gitlab.com/ee/user/clusters/agent/) -- [ ] [Set up protected environments](https://docs.gitlab.com/ee/ci/environments/protected_environments.html) - -*** - -# Editing this README - -When you're ready to make this README your own, just edit this file and use the handy template below (or feel free to structure it however you want - this is just a starting point!). Thank you to [makeareadme.com](https://www.makeareadme.com/) for this template. - -## Suggestions for a good README -Every project is different, so consider which of these sections apply to yours. The sections used in the template are suggestions for most open source projects. Also keep in mind that while a README can be too long and detailed, too long is better than too short. If you think your README is too long, consider utilizing another form of documentation rather than cutting out information. - -## Name -Choose a self-explaining name for your project. - -## Description -Let people know what your project can do specifically. Provide context and add a link to any reference visitors might be unfamiliar with. A list of Features or a Background subsection can also be added here. If there are alternatives to your project, this is a good place to list differentiating factors. - -## Badges -On some READMEs, you may see small images that convey metadata, such as whether or not all the tests are passing for the project. You can use Shields to add some to your README. Many services also have instructions for adding a badge. - -## Visuals -Depending on what you are making, it can be a good idea to include screenshots or even a video (you'll frequently see GIFs rather than actual videos). Tools like ttygif can help, but check out Asciinema for a more sophisticated method. - -## Installation -Within a particular ecosystem, there may be a common way of installing things, such as using Yarn, NuGet, or Homebrew. However, consider the possibility that whoever is reading your README is a novice and would like more guidance. Listing specific steps helps remove ambiguity and gets people to using your project as quickly as possible. If it only runs in a specific context like a particular programming language version or operating system or has dependencies that have to be installed manually, also add a Requirements subsection. - -## Usage -Use examples liberally, and show the expected output if you can. It's helpful to have inline the smallest example of usage that you can demonstrate, while providing links to more sophisticated examples if they are too long to reasonably include in the README. - -## Support -Tell people where they can go to for help. It can be any combination of an issue tracker, a chat room, an email address, etc. - -## Roadmap -If you have ideas for releases in the future, it is a good idea to list them in the README. - -## Contributing -State if you are open to contributions and what your requirements are for accepting them. - -For people who want to make changes to your project, it's helpful to have some documentation on how to get started. Perhaps there is a script that they should run or some environment variables that they need to set. Make these steps explicit. These instructions could also be useful to your future self. - -You can also document commands to lint the code or run tests. These steps help to ensure high code quality and reduce the likelihood that the changes inadvertently break something. Having instructions for running tests is especially helpful if it requires external setup, such as starting a Selenium server for testing in a browser. - -## Authors and acknowledgment -Show your appreciation to those who have contributed to the project. - -## License -For open source projects, say how it is licensed. - -## Project status -If you have run out of energy or time for your project, put a note at the top of the README saying that development has slowed down or stopped completely. Someone may choose to fork your project or volunteer to step in as a maintainer or owner, allowing your project to keep going. You can also make an explicit request for maintainers. +## 감상 +이번 보고서를 통해 자유 오픈소스 OS의 장점에 대해서 오픈소스OS를 사용하는 것이 타당한 근거에 대해 다양하게 알게 되었다. +특히, DRM과 Trusted Computing의 개념에 대한 설명을 번역하는 과정에서 윈도우에 비해 리눅스가 가지는 장점을 알게 됐다. +자유 오픈소스 소프트웨어의 의의와 그 가치를 좀 더 제대로 이해하게 되었고, 오픈소스SW의 역사에 대해 한층 넓은 지식을 가지게 됐다. +이러한 배경 지식이 오픈소스에 대한 흥미를 더 이끌어내고 있는 것 같고, 나중에는 한번 실제로 리눅스 OS를 이용하여 데스크톱을 사용해보는 것도 좋을 것 같다는 생각이 들었다. +또한, 나의 번역이 잘못되었을 수도 있기 때문에 나중에 검토가 된다면 한번 확인해봐야할 것 같다. +그리고 아직 번역하지 못한 남은 부분이 있기 때문에 영어 공부도 할겸 이후에 꾸준히 작성하면서 내용을 완성할 계획이다. +지금까지 내가 오픈소스를 통해 얻었던 수혜에는 한참 못미치겠지만 이러한 기여를 통해 조금이나마 도움을 받는 사람이 있었으면 좋겠고, 나의 번역이 수용되어 기여를 인정받았으면 좋겠다는 생각이 들었다. +또한 그렇게 완성되면 다른 사람에게도 이 사이트를 추천하고 싶다. 그만큼 파격적인 면도 있으면서 흥미로운 점이 많은 웹사이트였기 때문에 추천할만한 가치가 있다고 생각된다. -- GitLab