Daiki Ueno wrote: > KO Myung-Hun <[email protected]> writes: > >> I'm using this in libiconv. On OS/2, a charset is not specified >> generally. Just only a locale is specified. And all LC_xxx are not >> specified. Just only LANG is specified. For examples, set LANG=ko_KR for >> Korean. And the case that charset aliases are used is that '.' to >> specify a charset is not found or a buffer is overflowed, which is >> impossible if a charset is correct. So charset-to-charset mapping is not >> useful on OS/2. > > Thanks for the update. > >>> Also if it changes anything in the OS/2 port of gettext, consider >>> updating this file: >>> http://git.savannah.gnu.org/cgit/gettext.git/tree/os2/README.OS2 >>> >> >> Ok. If I work on gettext later, I'll consider. > > I meant to ask if the patch could potentially change the behavior > described in that documentation. Would you mind double-checking that? > > For example, it says: > > If the output character set is ommited from the LANG variable, the > default codepage is ALWAYS taken from the operating system (e.g. the > codepage setting from locale.alias is always ignored, so "russian" > stays just for "ru_RU" and not for "ru_RU.ISO-8859-5"); you may want > to set it just if you want to override the active OS/2 codepage. >
This patch does not change any behaviors of OS/2 port of gettext. Because this patch embeds charset aliases into localcharset.c instead of using charset.alias file, and fixes the problem a locale instead of a charset if a charset is not specified is returned. In addition, localcharset.c module itself does not use locale.alias. It is used in localealias.c. Frankly, I don't know that how localcharset.c and localealias.c have a relation to each other. -- KO Myung-Hun Using Mozilla SeaMonkey 2.7.2 Under OS/2 Warp 4 for Korean with FixPak #15 In VirtualBox v4.1.32 on Intel Core i7-3615QM 2.30GHz with 8GB RAM Korean OS/2 User Community : http://www.ecomstation.co.kr
