1 2Welcome! 3======== 4 5This is the OS/2 port of GNU gettext internationalization library. 6 7 8Compatibility 9============= 10 11The library has been compiled with -Zmt flag, but it doesn't matter as soon 12as you use the EMX single-threaded runtime fix (emx-strt-fix-0.0.2.zip). 13 14The library is fully compatible with the previous port of gettext library 15(0.10.35) which is largely used especialy by XFree86/2 programs. All the 16old programs that I have with gettext support run fine with the new version 17of the DLL. 18 19 20Installation 21============ 22 23If you set the GNULOCALEDIR environment variable to point to your 24x:/xxx/share/locale directory, it will override any other setting. That is, 25unpack the binary distribution over /emx, set GNULOCALEDIR=x:/emx/share/locale 26(where x: is the drive letter of your EMX installation) and that's all. 27 28If you use the UNIXROOT environment variable, the default catalogue search 29paths will be like on Unices, e.g. $(UNIXROOT)/usr/lib and 30$(UNIXROOT)/usr/share/locale. GNULOCALEDIR always overrides this. 31 32Now if you haven't did it earlier, set the language identifier that you use. 33This is done by adding a "SET LANG=xxx" environment setting to your CONFIG.SYS, 34where xxx is the identifier of your language (example: en_UK for English in UK, 35ru_RU for Russian in Russia. Also you can use names like "russian", "italian" 36and so on - see the share/locale/locale.alias file). 37 38This port of gettext supports character set conversions. This means that if 39your .mo files were written using new gettext guidelines, e.g. they contain a 40message like this: 41 42msgid "" 43msgstr "Content-Type: text/plain; charset=koi8-r\n" 44 45the messages will be properly converted to your active codepage using OS/2 46Unicode API. For example, russian message catalog gettext.mo is in the 47KOI8-R (codepage 878) encoding while OS/2 uses codepage 866. Now when you 48run any of these tools it detects that the active OS/2 codepage is 866 and 49performs the translation from CP878 -> CP866 for every message. 50 51If you want to override the character set used to output messages (for example 52in XFree86 for Russian the KOI8-R encoding (codepage 878) is used) you can 53set the output character set by adding a postfix to the LANG environment 54variable, this way: 55 56set LANG=ru_RU.KOI8-R 57 58or (equivalent): 59 60set LANG=ru_RU.CP878 61 62or (same effect): 63 64set LANG=ru_RU.IBM-878 65 66If the output character set is ommited from the LANG variable, the default 67codepage is ALWAYS taken from the operating system (e.g. the codepage setting 68from locale.alias is always ignored, so "russian" stays just for "ru_RU" and 69not for "ru_RU.ISO-8859-5"); you may want to set it just if you want to 70override the active OS/2 codepage. 71 72 73XFree86 setup 74============= 75 76If you use XFree86 and the OS/2 default character set is different from the 77XFree86 default character set (e.g. for Russain CP866 vs KOI8-R), you can add 78the following (or similar) statement to your startx.cmd file (after the 79commands dealing with HOME and X11SHELL): 80 81call VALUE 'LANG', 'ru_RU.KOI8-R', env 82 83Otherwise you can get incorrect (wrong codepage) output from programs that 84previously worked (e.g. GIMP 1.22). This is because earlier versions of gettext 85didn't support character set translations. 86 87 88Implementation remarks 89====================== 90 91The codepage conversion code uses OS/2 Unicode API, thus it falls under the 92limits that OS/2 Unicode API has. For example, OS/2 Unicode API does not 93support the BIG5 East Asian character set nor ISO-8859-X where X > 9 (at 94least with Warp4 with fixpack 14 that I have). If someone knows the 95OS/2 API identifiers for BIG5 or ISO8859-10,... encodings, please tell me! 96 97Since gettext 0.11 iconv emulation layer supports correctly UTF-8. Also 98I have added theoretical support for the following East Asian encodings: 99EUC-JP, EUC-KR, EUC-TW, EUC-CN. However, these encodings are (I believe) 100supported only on East Asian editions of OS/2. The code pages for them are 101listed in the \language\codepage\ucstbl.lst file but the codepage files 102themselves are missing; I believe they are ommited from European OS/2's 103due to their large size. 104 105Also I have added "support" for the BIG5 codeset as an alias for IBM-950 106codepage. However, I'm not very sure about this; in any case OS/2 does not 107support (as far as I know) anything closer to BIG5. 108 109 110Additional API 111============== 112 113This package provides additionaly the iconv() API that can be used by 114developers for doing more feature-full Unix ports. The iconv() API is used 115to convert text between various codepages. The intl.h header file contains 116the prototypes and definitions needed for iconv(); if you configure software 117with autoconf it possibly will find intl.h and set up the software accordingly. 118 119All these functions are exported from INTL.DLL. The iconv.a import library 120imports all the iconv* functions from INTL.DLL. So, like on Unix, now you can 121#include <iconv.h>, then link with -liconv and you will get a fully functional 122iconv implementation. 123 124 125Rebuilding the library 126====================== 127 128The library is quite easy to rebuild. Since the OS/2 support is provided now 129out-of-the-box in gettext, you just have to download and unpack the source 130archive. Now there are two ways to rebuild the gettext library: 131 1321. If you're a masochist you can go the clumsy configure/make Unix way. This 133is not recommended however as I found no way to tell libtool to generate a 134slightly non-standard DLL which will be backward compatible with gettext 1350.10.35. The compatibility is achieved by prepending backward.def to the 136export definition file generated with emximp or somehow else. Thus it is 137highly recommended you build using the second way, if it is possible. 138 1392. Go to os2 and just run `make'. If you have all the required tools, 140it should painlessly compile. Finally, if you want a binary distribution 141archive, do `make distr'. The weak side of building this way is that makefile 142is somewhat fragile. This means that if the makefile is left unmodified and 143a new version of gettext is rolled out, it *may* not work. But every possible 144attempt was made to ensure that the makefile takes most important build 145parameters from their autoconf counterparts. 146 147WARNING: Due to bugs in GNU Make 3.76.1 (at least in its OS/2 port) you can 148get sometimes (depending on make version and makefile modification :) funny 149messages like these: 150 151zip warning: name not matched: emx/src/gettext-0.10.40/support/os2/iconv.h 152 153or even: 154 155*** No rule to make target `out/release/intl.a', needed by `all'. Stop. 156 157Such messages are a bad joke. Ignore it, and re-run make. This is a 158long-standing bug in GNU make, alas. 159 160If you want a debug version of library, you can do `make DEBUG=1'. 161 162If you don't have the LxLite tool installed, do `make LXLITE=0' 163 164NB: For best results, it is highly recommended that you use at least emxbind.exe 165and ld.exe from gcc 3.0.2 or later, since they contain a number of fixes that 166will help you generate a more optimal DLL. 167 168 169Contributors 170============ 171 172Hung-Chi Chu <hcchu@r350.ee.ntu.edu.tw> 173 the original port of gettext (0.10.35) 174 175Jun SAWATAISHI <jsawa@attglobal.net> 176 some more work on it and submitted the patches to GNU team, although 177 they were not completely integrated. 178 179Andrew Zabolotny <zap@cobra.ru> 180 Succeeded to remove almost all OS/2-specific #ifdef's from mainstream 181 source code, wrote the dedicated OS/2 makefile, wrote the iconv wrapper 182 around OS/2 Unicode API, added support for locale translations. 183