Since version 1.3.0, the entire package utilizes human language packs to output data to the terminal. The technical parts of the language pack system are quite complicated to the average translator. So, to make it easier for the translators to translate the english language pack to other languages, the human language pack system is seperated along several directories in the stick2xyz build tree.

This tutorial is made solely for the translators who do not plan on developing plugins for stick2xyz. Those who plan on doing any development work outside of the 'trunk/language' directory should read Creating Stick Figure Viewer/Converter Modules.

Human Language Pack Table of Contents

Definitions for the Human Language Pack System

stick2xyz_pctchar - The generic type for passing read-only strings to and from the human language packs. If UNICODE is defined, then stick2xyz_pctchar is defined as const wchar_t *; otherwise, stick2xyz_pctchar is defined as const char *.
L"text" - Constant UTF-16 strings typically found in the human language packs.
"text" - Constant UTF-8/ASCII strings also typically found in the human language packs.
stick2xyz_fprintf - If UNICODE is defined, resolves to fwprintf; otherwise, resolves to fprintf.
stick2xyz_fputs - If UNICODE is defined, resolves to fputws; otherwise, resolves to fputs.

Introduction to the Human Language Pack System

The trunk/language directory ('language' in the distribution tarball) is the only directory translators will have to modify. In the directory is a shell script that lets you start a directory structure for a new language. You will need to use an ISO two-character country code when creating a new language pack:

http://www.iso.org/iso/country_codes/iso_3166_code_lists/english_country_names_and_code_elements.htm

You will also need the autotools installed on your computer if you wish to test out your language pack. If you're trying to compile from source, you will most likely have the autotools already on your computer. To check for the autotools, type and check:

[kevin@planetsaphire stick2xyz]$ autoreconf --version
autoreconf (GNU Autoconf) 2.59
Written by David J. MacKenzie and Akim Demaille.

Copyright (C) 2003 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

Now, we are ready to show you how to produce a language pack.

The Human Language Pack Directory Creator

The shell script, 'langedit.sh', is a portable shell script that will create the directory structure for your language, and then add the new language pack to the build system of stick2xyz.

This script is your first step in producing a new human language pack. To make it produce the directory structure, type:

[kevin@planetsaphire language]$ ./langedit.sh --add jp

This command creates a new language pack directed for Japanese. Replace 'jp' with the two-character country code representing the language you are translating to. Once the directory structure is created and the autotools have run, you are ready to begin translating the English strings to the new language.

The Human Language Pack Headers

It is now time to modify the headers of the human language pack. Use any text editor of your choice. Then, walk around the headers within the trunk/language/<your language> directory, editing the text to the language you chose to convert to.

Submitting Completed Human Language Packs

When you feel your human language pack is fully converted, please consider contributing it to the main stick2xyz development tree. Doing this will also give you developer access to the stick2xyz subversion repository. File a bug report announcing you have produced a human language pack for stick2xyz, and that you are willing to contribute it to the SVN trunk of stick2xyz. Be sure to put your language pack in an archive (preferably in tar gzip or tar bzip2 format), and attatch it to the bug report.

There are reasons why you must file a bug report before your human language pack is initially committed to the SVN trunk. The most important reason is to have a bug report that we can set dependencies for other bug reports on. A good example would be a bug report describing typos in your human language pack. Other reasons include duplicate bugs/packs, facilitating takeovers of human language packs, and code preservation should SVN ever fail.