MonoDevelop 2.0 Alpha 1이 새롭게 발표되었습니다. Visual Studio 2005와 점점 가까워지는 모습들을 보여주고 있으니 기대하셔도 좋을듯 합니다. :-)
* Visual Studio 2005 이상부터 사용하는 프로젝트 파일 포맷인 MSBuild 포맷을 기본으로 지원합니다. * 솔루션 폴더를 사용할 수 있으며 여기에 다른 프로젝트를 정리하여 넣을 수 있습니다. * Workspace라는 단위를 통하여 서로 관련이 있지만 종속적이지 않은 다수의 솔루션과 또 다른 Workspace를 관리할 수 있습니다. * 코드 완성 기능을 HTML과 ASP.NET 에디터에서 지원하기 시작합니다. * 태그 구조를 표시하는 바가 HTML 편집 모드 시 하단에 나타납니다. * 코드 접기 기능이 지원됩니다. * 증분 검색 기능이 지원됩니다. * 컬러 테마/스키마 기능이 지원됩니다. * 한 파일을 두 개의 창에서 나눠보는 기능이 지원됩니다. * GTK+ 2.12 버전 이상, Compiz 윈도우 관리자를 사용하고 있을 경우, 코드 완성 팝업을 띄운 상태에서 Ctrl 키를 누르면 투명 모드로 전환됩니다. * 클립보드 Snippet이 추가됩니다. * XML, XML 스키마 편집 기능이 지원됩니다. * 어셈블리 브라우저 및 어셈블리 코드 보기 (디스어셈블링이 아닌 시그니처 나열)가 지원됩니다. * 코드 메트릭 계산이 지원됩니다. * Ctrl + Tab키를 누르면 패드/문서 스위칭 도구를 띄울 수 있습니다. * Vala 프로그래밍 언어를 지원합니다. (C#과 유사하지만 GObject 시스템에 최적화된 것이 특징입니다.)
지난번에 이어서 이번 글에서는 MonoDevelop을 이용하여 지역화 프로그래밍을 다루는 방법을 소개하고자 합니다. 이미 이전 글에서 언급하였듯이 Mono에서는 지역화를 위하여 libintl 기반의 프로그래밍 기법을 사용합니다. Microsoft .NET Framework가 사용하는 방법과는 다소 차이가 있으며 접근 방법도 조금 다릅니다.
국제화 기능을 적용해보기 위하여 새로운 프로젝트를 하나 만들어 보도록 하겠습니다.
새로운 프로젝트를 여느떄와 같이 작성합니다.
하단의 Translation 항목을 체크하면 추가할 지역화 대상 언어를 관리할 수 있는 리스트박스와 UI가 나타나는 것을 볼 수 있습니다. Add 버튼을 클릭합니다.
언어와 함께 지역 코드를 선택할 수 있는 세부 대화 상자가 나타납니다. 우리가 여기서 시험해 볼 것은 단순한 번역이므로 지역 코드는 사용하지 않고 언어만을 선택하기로 합니다. Korean (한국어)를 선택하고 OK 버튼을 클릭합니다. 같은 방법으로 Japanese (일본어)도 추가합니다.
C# 프로젝트 외에 지역화 프로젝트가 추가된 것을 볼 수 있습니다. 지역화 프로젝트를 사용하기 전에 C# 프로젝트에도 약간의 추가 작업이 필요하므로 다음 단계를 계속하기로 합니다.
C# 프로젝트의 References 폴더를 오른쪽 버튼으로 클릭한 다음, "Edit References" 메뉴를 클릭하면 위와 같이 대화 상자가 나타납니다. 수많은 어셈블리 참조들이 있는데 이 중에서 Mono.Posix 항목 앞의 체크 박스를 클릭하고 OK 버튼을 클릭합니다. Mono.Posix 어셈블리의 유틸리티 클래스를 기준으로 번역할 메시지를 찾고, 여기에 맞는 파일을 제공할 수 있습니다.
C# 코드 편집기에서 사용이 편할 수 있도록 Mono.Unix 네임스페이스를 using 절에 추가합니다. Mono.Unix 네임스페이스를 가지고 프로그래밍하는것은 잠시 후에 다시 살펴보겠습니다.
이번에는 국제화 프로젝트 항목을 오른쪽 버튼으로 클릭하여 Options 메뉴를 클릭합니다.
Init String 항목을 잘 살펴보시기 바랍니다. 이 항목에 나타나있는대로 libintl을 초기화해야 실질적인 연동이 가능합니다. 여기서 참고해야 할 것은, 지역화 프로젝트도 여러 개가 존재할 수 있다는 점입니다. Package Name 부분을 달리 설정하면 이러한 내용이 반영됩니다. Package Name을 입력하면 Init String 항목도 같이 바뀌는 것을 볼 수 있습니다.
위의 Init String 항목의 내용을 기억하여 호출할 때 전달할 인수를 정확히 지정해야 합니다. 아래는 C# 코드에서 카탈로그를 실제로 초기화한 예제입니다.
이렇게 함으로서 런타임 상에서의 libintl 연동이 가능해졌습니다. 그렇다면 실제로 다국어 번역을 어떻게 이끌어낼 수 있을까요?
Catalog 클래스 내의 GetString 메서드를 사용하여 기준이 되는 영어 문장을 먼저 입력합니다. 만약 복수 명사를 구분하여 취급할 필요가 있다면 GetPluralString을 대신 이용합니다. 여기서는 간단한 인사 메시지 번역을 해볼 것이므로 GetString 메서드를 이용합니다. 번역할 대상이 있으면 GetString 메서드에 전달된 인수에 대응되는 국제화 프로젝트 내의 실제 문자열로 치환되어 반환될 것이며, 그렇지 않으면 Fallback 모드로 대응되어 전달한 인수 그대로 반환됩니다.
C# 프로젝트를 우선 다시 빌드합니다. 문법적인 오류가 없음을 확인합니다.
이어서 국제화 프로젝트를 오른쪽 버튼으로 클릭한 뒤 Update Translations 메뉴를 클릭하여 번역 대상 문자열 리소스들을 MonoDevelop가 수집할 수 있도록 명령을 내립니다.
이제 시험삼아서 일본어 PO 파일을 열어보겠습니다. 놀랍게도, Catalog.GetString 메서드로 호출한 대상 메시지만을 정확하게 가져온 것을 볼 수 있습니다. 이제 Translated 란에 해당 일본어 메시지를 입력하고, Comments에 약간의 부연 설명도 달아봅니다. 만약, 번역이 어려운 상태의 문장이라면 상단의 리스트 뷰에서 Fuzzy 열의 체크 박스를 클릭해놓아도 됩니다.
이제 같은 방법으로 한국어도 번역을 완성합니다. 참고로, MonoDevelop VMware Image에서는 기본적으로 한국어/일본어/중국어 입력이 지원되지 않는데 이를 해결하기 위하여 전용 IME를 설치하지 않는 대신 호스트 컴퓨터에서 해당 문자열을 클립보드로 복사하여 가상 머신에 붙여넣기하는 방식으로 가져왔습니다. :-)
다국어 프로젝트를 다시 빌드하도록 합니다. 다국어 프로젝트의 산출물은 EXE 파일이나 DLL 파일 외부에 배포되기 때문에 별도로 빌드해야 합니다. 이제, 콘솔을 열어서 해당 디렉터리까지 이동해 봅니다.
우리가 작성한 로케일 파일인 ja와 ko 파일이 있는 것을 볼 수 있습니다. 우선 일본어 파일의 내용을 제대로 반영하고 있는지 확인해보기 위하여 다음과 같이 명령을 내립니다.
LANGUAGE=ja mono i18n_test.exe
그리고 한국어도 같은 방법으로 테스트할 수 있습니다.
LANGUAGE=ko mono i18n_test.exe
만약 LANGUAGE 변수 설정 없이 시작하면 어떨까요? 기본 문자열이 나타나겠지요. :-)
** 노트: 정정사항이 있습니다. 다음 그림에서처럼 빌드 유형에 대하여 실행 방법을 정의하여 외부 콘솔 프로그램에서 띄워볼 수 있도록 할 수도 있습니다.
다음번에는 GTK# 디자이너인 Stetic을 이용한 간단한 응용프로그램 디자인 및 테스트를 다루어보기로 하겠습니다. 감사합니다. :-)
MonoDevelop를 이용하여 새로운 프로젝트를 만들 때 Packaging 기능을 이용하여 소스 코드를 재배포하거나, 바이너리를 재배포하는 작업을 편리하게 할 수 있다는 것을 지난번 강좌를 통하여 확인하였습니다. 그런데 Packaging 옵션이 굉장히 다양한 것을 볼 수 있었는데 이들 옵션이 실제로 어떻게 적용되는지 살펴볼 필요가 생겼습니다.
지난 번과 마찬가지로 새 프로젝트를 만들어보기로 합니다. 기존 솔루션에 새로운 프로젝트를 추가하는 방법도 좋습니다. 양쪽 모두 Packaging을 비롯한 추가 옵션을 묻는 대화 상자가 나타나도록 되어있습니다.
각각의 특성을 알아보기 위하여 Packaging 옵션으로 선택할 수 있는 모든 것들을 다 선택해보겠습니다. 다른 부분들은 체크하지 마시고 OK 버튼을 클릭하시면 Packaging 프로젝트와 함께 새로운 C# 프로젝트가 생성될 것입니다.
위의 그림에서 보듯이 오른쪽 화면의 솔루션 트리뷰에 Packages라는 이름의 Packaging 프로젝트가 새로 생성된 것을 보실 수 있습니다. 이름이 정형화되어있어서 마치 예약된 기능처럼 보여지지만 Packaging 프로젝트는 같은 솔루션 안에서 개수의 제한 없이 얼마든지 추가할 수 있습니다. 그리고 이 프로젝트 아래에 다양한 Sub Item들이 추가된 것을 볼 수 있습니다. 이제 이 각각의 아이템들을 살펴보기로 합니다.
Linux Binaries 항목을 오른쪽 버튼으로 클릭하고 속성을 살펴보니 위와 같은 대화 상자가 나타납니다. 프로젝트가 생성하는 EXE나 DLL 파일 (Visual Studio에서는 이것을 프로젝트 출력 (Project Output)이라는 말로 표현하고 있었습니다.)을 플랫폼 별로 구분하여 배포할 수 있게 한 것이 보입니다.
여기서 선택한 대상 플랫폼이 현재 버전의 Mono나 MonoDevelop에서 정확한 의미를 가지는 것은 아닙니다. 하지만 향후 개발 계획에 따라서 Mono나 MonoDevelop가 특정 OS에만 국한되는 내용이 들어있지는 않은지 판정하거나 하는 데 이용될 수 있습니다. 그리고 현 시점에서 우리는 특정 OS에만 국한되는 내용을 걸러내기 위한 목적으로 이러한 기준들을 이용하고 프로젝트에서 선택할 수 있습니다.
이제 그 옆에 있는 프로젝트 선택 탭을 클릭해 보기로 하겠습니다. C#이나 다른 프로젝트를 여기서 추가할 수 있는데, 같이 배포하기를 희망하는 프로젝트 노드 앞에 체크 박스를 클릭하면 됩니다.
마지막으로 파일 탭을 클릭해보기로 합니다. 앞서 선택한 프로젝트 내에 속하는 파일들 중 실제로 포함할 파일들만 선택적으로 여기서 다시 설정할 수 있습니다. Linux와 Windows 플랫폼을 나누어서 배포해야 한다면, 이 탭을 이용하여 리눅스 버전에서만 사용할 수 있는 C# 모듈이나 라이브러리 따로, Windows 버전에서만 사용할 수 있는 C# 모듈이나 라이브러리 따로 관리하도록 하면 됩니다.
실제로 다른 프로젝트를 추가해보기로 하겠습니다. 파일 탭에 선택한 내용이 나타날까요?
잘 보이는군요. :-)
이번엔 Source Packaging 항목을 살펴보기로 하겠습니다. File Format을 클릭하니 크게 세 가지 형식을 고를 수 있도록 되어있습니다. 우선, MonoDevelop IDE (지금 우리가 사용하고 있는 IDE입니다.) 파일 포맷을 선택할 수 있습니다. 그리고 Windows 환경에서 Visual Studio를 대신하여 널리 사용되는 오픈 소스 기반 .NET IDE인 SharpDevelop용 파일 포맷이 보입니다. 마지막으로, Visual Studio용 Solution 파일 포맷도 됩니다. 이전에 언급한대로 Visual Studio용 Solution 파일 포맷의 경우 msbuild에서도 로드하여 사용할 수 있다고 하였습니다.
소스를 묶어서 압축 파일로 만들 때 사용할 포맷도 지정할 수 있습니다. tar, tar.gz, tar.bz2, zip 포맷이 지원되는 것을 볼 수 있습니다.
그리고 마지막으로 Tarball 파일을 보기로 합니다. Tarball 파일은, 자동화된 것은 아니나, Windows 환경에서 사용하는 MSI 파일이나 CAB 파일과 마찬가지로 Linux 환경에서 소스 코드를 빌드하고 시스템에 설치할 수 있도록 도움을 주는 고유한 Installer입니다. 소스까지 같이 제공하므로 오픈 소스 정신에도 가까운 것입니다. Tarball 파일 안에 들어갈 Makefile에 대한 설정을 지정할 수 있는데, 일단 디버그 빌드와 릴리즈 빌드 중에서 선택이 가능합니다. 그리고 Autotools 기반인지, 편집하기에 용이한 일반 Makefile을 만들것인지도 선택할 수 있습니다.
새로운 패키지를 생성하거나 추가할 때 위와 같은 단계별 마법사 대화 상자를 볼 수 있습니다. 그리고 각 패키지 별로 세부 설정을 마법사 수준에서 마찬가지로 지정할 수 있으므로 패키지 설정의 어려움은 없을 것입니다.
다음번에는 Unix Integration이 어떻게 동작하는지에 대한 내용과 Translation을 위하여 사용하는 i18n을 위한 Portable Object 파일을 프로그래밍 방식으로 접근하는 방법에 대해서 살펴보기로 하겠습니다.
당신의 의견을 작성해 주세요.