~-[[ko/FrontPage|런치패드 도움말]] > [[ko/Translations|번역]] > 일반 번역 지침 -~ ||<>|| = 개요 = 이 번역 지침은 소프트웨어를 자국어로 번역하는 방법에 대한 내용을 담고 있습니다. 어떤 문자열을 번역해야 하고 하지말아야 하는지, 복수형의 형태 등 런치패드 번역(로제타)이나 다른 도구를 이용하여 소프트웨어를 번역하는데 숙지해야 될 사항들에 대한 내용입니다. 런치패드 번역(로제타)를 번역 도구로 사용하는 방법에 대해서는 다루지 않습니다. 이에 대한 정보는 [[ko/Translations/StartingToTranslate|번역 시작하기]] 문서를 참조하십시오. = 언어별 특별 지침 목록 = '''각 언어별 특별 지침을 보기 전에, 이 일반 번역 지침을 먼저 읽어주시기 바랍니다.'''. 이 지침을 번역하여 여러분의 자국어 특별 지침에 포함시키거나 자국어를 위한 개발 지침에 포함시켜도 됩니다. 자국어 번역물의 품질 유지를 위하여, 신규 번역자들에게 이 지침이나 비슷한 지침을 따를 것을 권고하는 것이 좋습니다. [[ko/Translations/GuidesList|언어별 특별 지침 목록]] = 번역 품질 확인을 위한 기본 규칙 = 번역 품질을 향상시키기 위해 아래의 일반 규칙들을 따라 번역을 하는 것을 권장합니다. * 지침서의 모든 내용을 숙지하고, 다른 번역자들과 지속적으로 연락할 것 * 문자열을 번역하는 경우, 자국어에 맞게 정확히 번역되었는지, 오류는 없는지 재확인할 것 * 번역한 문자열이 어색한 경우, 다시 한번 확인할 것 * 가능하다면 다른 사람에게 번역물을 리뷰해 줄 것을 요청할 것 * 번역어의 일관성은 번역 품질 유지에 중요한 부분이다. [[http://open-tran.eu| Open Tran]] 웹사이트를 이용하여 다른 자유 소프트웨어 프로젝트에서 각 단어와 문구를 어떻게 번역하였는지 확인할 것 * 용어 사전 * 팀에 새 멤버를 받아들이기 전에, 이전에 번역한 작업물이 있는지, 팀의 번역 지침을 숙지했는지 확인할 것 = 복수형 형태 = 영어에 2가지의 복수형 형태이 있는 것처럼 2개 이상의 복수형을 가진 언어가 있습니다. 이러한 복수형 처리는 초보 번역자들이 가장 먼저 묻거나 부딪히는 문제이기도 합니다. 번역 지침에 자국어의 복수형 형태에 관한 정보와 예제를 포함하는 것을 권장합니다. 예제 {{{ 루마니아어는 3개의 복수형 형태를 가지고 있습니다. 원문 : msgstr[0] %d thing msgstr[1] %d things msgstr[2] %g things 번역문 : msgstr[0] %d lucru msgstr[1] %d lucruri msgstr[2] %d de lucruri }}} ||팁 :|| [[http://www.gnu.org/software/gettext/manual/gettext.html#Plural-forms|Gettext 문서의 복수형 형태 섹션]]에서 더 자세한 정보를 확인할 수 있습니다.|| ||팁 :|| 일반적으로 한국어에는 복수형 형태를 이용하여 복수를 표현하지 않습니다. '~들'이라는 복수형 어미가 있지만, 이는 특수한 경우에만 사용됩니다.(허나 최근에는 남용되고 있음. 사람들, 국민들은 잘못된 예. -[[www.andongkwon.or.kr/newspaper_2/image/96/9611.pdf|안동권씨종보 능동춘추 '漢字도 우리글']])|| = 메뉴 단축키 / 바로가기 = 개발 언어나 프레임워크에 따라 문자열 중 키보드 바로 가기를 의미하는 글자를 표시하는 방법이 다릅니다. 하지만 많은 프로젝트에서 키보드 바로 가기 키로 사용하는 문자앞에 밑줄(예: Save _As)이나 엔퍼샌드(예: Print previe&w)를 붙여 표시합니다. 각 기능에 할당된 바로 가기가 중복되지 않았는지 확인해야 하며, 번역 전에 단축키 목록을 살펴보거나 프로그램을 사용해보는 것이 좋습니다. 키보드 바로 가기 키로 사용할 문자앞에 원문에서 사용된 밑줄이나 엔퍼샌드를 붙입니다. 한국어의 경우 문자열 뒤에 괄호와 함께 바로 가기 키를 표시하며 대문자를 사용합니다. (예: 다른 이름으로 저장(_A), 인쇄 미리보기(&W)) 프로그램에서 여러 가지 옵션/탭/체크상자 등에 같은 바로 가기를 사용한 경우, 바로 가기 키를 여러번 누르면 해당 메뉴에 접근할 수 있습니다. 언어별 바로 가기에 대한 자세한 정보는 http://bazaar-vcs.org/BzrTranslations/Tips 를 참조하십시오. 메뉴 바로 가기 예제: {{{ _File New &Tab ~Downloads }}} = DocBook (XML) 파일 번역 = 런치패드 번역 기능을 이용하여 XML 파일을 번역할 수 있습니다. xml2po를 이용하여 XML 파일을 pot 파일로 변환한 뒤, 로제타로 불러옵니다. XML 파일을 번역할 때는 다음 사항에 주의해야 합니다. == XML 태그는 대소문자를 구별합니다. == xml2po 이나 po2xml 을 이용하는 경우, xml 태그와 속성은 대소문자를 구별하여 인식됩니다. 예제: {{{ 원문: See the 틀림: 를 참조 옳음: 를 참조 }}} == 메뉴선택(menuchoice) 태그 == "menuchoice" 태그는 "guibutton | guiicon | guilabel | guimenu | guimenuitem | guisubmenu | interface" 등입니다. 이 외의 다른 태그를 포함하거나 태그 바깥쪽에 텍스트를 입력하지 마십시오. 예제: {{{ 원문: ApplicationsMultimediaMovie Player 틀림: 프로그램멀티미디어동영상 플레이어 옳음: 프로그램멀티미디어동영상 플레이어 }}} = 번역하지 말아야 할 것들 = 여기서는 번역하지 말아야 할 문자열과 그러한 문자열을 확인하는 방법에 대한 일반적인 내용을 다룹니다. 일반적으로 프로그램 개발자들이 남긴 메모를 통해 번역하지 말아야할 문자열을 확인할 수도 있습니다. 따라서 각 문자열에 포함된 메모를 늘 확인해야 합니다. == 데이터 자리 표시자 및 변수명 == 많은 개발 언어에서 %s 나 %d 와 같은 자리 표시자를 이용하여 문자열에 데이터를 삽입하는 기능을 사용할 수 있습니다. 또는 %(variablename)s, $name, ${name} 등과 같은 복잡한 변수를 사용하기도 합니다. 이러한 변수나 자리 지정자는 원문 그대로 복사하여 대상 언어의 적절한 위치에 삽입합니다. 이해가 안되는 부분이 있으면, 다른 번역자에게 문의하십시오. 예제: {{{ 원문: I found $name ethernet device. 틀림: $nume 이더넷 장치를 발견하였습니다. 옳음: $name 이더넷 장치를 발견하였습니다. }}} {{{ 원문: Delete %(name)s ? 틀림: %(nume)을(를) 삭제하시겠습니까? 틀림: %(nume)s을(를) 삭제하시겠습니까? 틀림: %(name)을(를) 삭제하시겠습니까? 옳음: %(name)s을(를) 삭제하시겠습니까? }}} ||팁 :|| 위 예제에서 '%(name)s' 의 's'는 복수형을 의미하는 것이 아니라 변수의 일부입니다. || == 서식/XML 태그 == 문자열에 과 같이서식 텍스트를 위한 HTML/XML 태그가 포함되는 경우도 있습니다. 이러한 태그들은 그대로 복사하여 적절한 위치에 삽입합니다. 닫음 태그에 유의하여야 하며, XML 태그 역시 같은 방법으로 처리합니다. 예제: {{{ 원문: File name 틀림: 파일명 옳음: 파일명 }}} xml 태그 속성과 속성값은 번역하지 않습니다. 예제: {{{ 원문: 옳음: 틀림: }}} == 프로그램 매개 변수 == 명령줄 매개 변수는 번역하지 않습니다. Example {{{ 원문: "The command line options are:\n" " --quick speeds up the processing\n" " --slow slows everything down." 틀림: "명령줄 옵션:\n" " --빨리 빠르게 처리합니다.\n" " --느리게 느리게 처리합니다." 옳음: "명령줄 옵션:\n" " --quick 빠르게 처리합니다.\n" " --slow 느리게 처리합니다." }}} == TRUE/FALSE, GTK 상수 == "TRUE", "FALSE" 와 같은 문자열이나, "gtk-ok", "gtk-cancel", "toolbar-icon" 등과 같은 gtk 상수는 번역하지 않습니다. 번역 파일에 포함된 이러한 문자열은 포함되지 말아야할 것들이므로, 프로그램 개발자에게 연락하여 해당 문자열들을 삭제하도록 요청하십시오. == GCONF 설정키 == 예제: {{{ 원문: The port which the server will listen to if the 'use_alternative_port' key is set to true. Valid values are in the range from 5000 to 50000. 틀림: '다른_포트_사용' 키값이 참이면, 서버에서 해당 포트를 엽니다. 유효한 값은 5000 에서 50000 사이입니다. 옳음: 'use_alternative_port' 키값이 참이면, 서버에서 해당 포트를 엽니다. 유효한 값은 5000 에서 50000 사이입니다. }}} == 문맥 텍스트(Context text) == 일부 오래된 GNOME 번역물을 보면, 번역문에 원문이 포함된 경우가 있습니다. 이에 대한 자세한 사항은 다음 문서를 참조하십시오. : http://leonardof.org/2007/12/01/context-in-gnome-translations/en/ 예제: {{{ 원문: "Orientation|Top" 틀림: "방향|위쪽" 틀림: "Orientation|위쪽" 옳음: "위쪽" }}} 이러한 문자열을 발견하면 프로그램 개발자에게 버그로 보고하십시오. = 번역 상황 통계 = 런치패드 번역 전반에 걸쳐, 번역에 대한 통계가 제공됩니다. 이러한 통계를 통해 번역자들이 번역 상황을 파악하는데 도움을 줍니다. 아래 예제는 우분투에 포함되는 특정 패키지의 특정 언어 번역 상황 통계 화면입니다. {{attachment:Translations/Guide/LP-translation-stats.png}} == 상태 막대의 색상 == Depending on their status translation statistics can show different colors to indicate each particular status of the strings. Here is what the colours in the Launchpad Translation statistics mean: * Translated strings: * '''Green''': the translation imported from the upstream project and the one in Launchpad are identical. * '''Blue''': changed in Launchpad. The translation was imported from an upstream project, but translator chose to change it in Launchpad. The changed string will override the upstream one and be used in the distributed translations. Translators should keep these modifications to a minimum, and manually send them back to upstream if necessary. * '''Purple''': newly translated in Launchpad. The string is only translated in Launchpad. Translations imported from upstream did not have a translation for the string. * Untranslated strings: * '''Red''': untranslated. These strings have neither been translated in the upstream project nor in Launchpad ||Quick tip:|| You will find more information in the related [[https://answers.launchpad.net/rosetta/+faq/172|Launchpad Translations FAQ entry on the meanings of "Changed in Launchpad" and "Newly translated in Launchpad"]].|| == Lifecycle == During the lifecycle of translations, and while translators do their work, there are some different paths in which the colours can change. Here is a description of the most common scenarios: * '''Red > Purple > Green'''. In this scenario, the string was untranslated (Red), the translator translated it in Launchpad and there was no translation upstream (Purple). In the next translation import, the upstream translation has been done and coincides with the Launchpad one. This was because either an upstream translator made exactly the same translation or because the translator sent the translations back to upstream. * '''Red > Purple > Blue > Green'''. The string was untranslated (Red), the translator translated it in Launchpad and there was no translation upstream (Purple). In the next translation import, the upstream translation has been done and is different to the Launchpad one. This was probably because there was no communication between the upstream translator and the downstream one: the latter did not send his/her changes back to upstream, so upstream didn't know someone had already translated this somewhere else and translated it again, but differently. The way to get this translation to green is for the two translators to agree in a common translation, and either change it in Launchpad or upstream, depending on which one they might want to adopt. * '''Red > Green'''. The translation has been done upstream and it has been imported into Launchpad. * '''Green > Blue'''. A translator deliberately overrode an upstream translation. Upstream and Launchpad translations differ. These should be kept to a minimum, if necessary at all. = Running a localization team = == Suggestions for sections included in your guidelines == Below are some ideas, hints, for some information that could be included into the guildelines for your language: * A section describing the current focus for translations. What packages should be translated, their priority, due date... etc * Create or provide a communication channel for all translators. It can be a forum, mailing list, IRC channel. The main usage of this channel is to support team work, ask for help or suggestions. * Provide information about other team working on translations, links to other upstream projects. Try to keep in touch/sync with their work. * Decide what grammatical mode or tense is used when translating into your language. * Decide grammatical person and if you are going to use a formal or informal approach when translating software. T-V distinction. * Decide a common set of terminology or dictionary to be used by all translators. This will help creating uniform translations. * A section, or a dedicated page, containing examples of common errors, together with an explanation of the error and the suggested solution * A section, or a dedicated page, containing examples of strings that should not be translated. == Common/Best practice == Below you will find a set of common practices for running a team * Don't forget about other translators or translations groups. In many cases you or your are not the only one doing translation in the free software ecosystem. Always keep in touch with that other teams are doing and make sure the translation teams for your language are translating free software using the same "language". Try to create or join a communication channel channel common to all translation teams for your language and use it for talking about important aspect that affect all translations. * Define a procedure for accepting new team members. * The acceptance level may vary according to the percentage of already finished translations. For languages with few translators and translations already done team acceptance could be lower than in the case of a language with many translators, translations made and the presence of GTP, OpenOffice , etc upstream translation projects. * Before accepting a member you may ask him/her to provide some translation. If the translations are great you may accept the new member. Otherwise giving feedback about why the translation are not good is a great help. Try to use a forum, mailinglist or IRC channel for giving feedback to potential new members. * Create a webpage/wikipage for the translations guide. This guide should contain: * First rule: "If a translation does not make sense for you / your grandmother, definitely it is wrong!". * Second rule: "Make your translation useful and adapt to the context. Don't follow always the original text". Like for example "Tile children" may sound funny in many languages so try "Arrange windows as tile". The original text is not always the correct one. * a common terminology or a link to a common terminology dictionary or glossary. Don't forget about [[http://open-tran.eu | open-tran.eu ]] . You can also install [[http://www.i18n.ro/glosar | the glossary used by Romanian teams]] ([[ko/ http://diacritice.svn.sourceforge.net/viewvc/diacritice/trunk/ | here is the code]]) * information about what should be translated and what not * specific rules for translating into your language * a list of frequent errors. * explaining the plural form for your language and how to use them * how you should translate menu accelerators / shortcuts * inform the translators about other translation project and how we should cooperate and work together * Make sure you have a good communication channel for all members of the team or subteam. Try to reach all communication types: mailinglist, forum, IRC channel. * Let Launchpad know about your translation guide * Create a webpage / wiki where people could find general information about your team, such as: * short and long term team goal * new membership acceptance conditions * translation guide * common terminology (ex a link to a glossary, terminology list, dictionary) * how to get in contact with the team (team contact or team members) * Make sure the team act as a team. * Keep the team members up to date with the latest actions * keep in contact with team members and try to collect feedback and status * guide new members and help them get along with the team and translation work * try to recruit new members into your translation team. * From time to time take a look at what other people are doing. In many cases you are not the only team/person translating software in your language. = Next steps = Details on joining and creating [[ko/Translations/Groups|translations groups and teams]] http://translatewiki.net/wiki/Portal:Ko/Dictionary#.ED.86.B5.EC.9D.BC.EC.84.B1 || ~-[[ko/Translations/StartingToTranslate|< 번역 시작하기 ]] -~ || ~- [[ko/Translations/Groups|번역 그룹과 팀 >]] -~ ||