[Zope-dev] Zope 2.6.0 ZMI Problem for CJK(Collector 623) patch.

[Heiichiro NAKAMURA]

On Tue, 17 Dec 2002 12:32:11 +0900
Kazuya FUKAMACHI <kf@atransia.co.jp> wrote:

> I'm not sure which is better;
>=20
> 1) adopting new environment value, Z_SOMETHING
>    ie. Z_DEFUALT_CHARSET ?
>=20
> 2) using locale.getlocale()[1]
>    needs some abstruction layer



umm, let's try some locale configuration:


----------------------- script start -----------------------------
=66rom locale import setlocale, getlocale, LC_ALL
import sys
print sys.platform
for l in (
    'en_US',
    'en_US.ASCII',
    'en_US.US-ASCII',
    'en_US.latin-1',
    'en_US.ISO-8859-1',
    'en_US.ISO-8859-2',
    'en_US.UTF-8',
    'el_GR.ISO-8859-1',
    'el_GR.ISO-8859-2',
    'el_GR.ISO-8859-5',
    'el_GR.ISO-8859-7',
    'el_GR.ISO-2022',
    'el_GR.EUC-JP',
    'ja_JP.UTF-8',
    'ja_JP.EUC-JP',
    'ja_JP.ISO-2022',
    'ja_JP.ISO-2022-JP',
    'ja_JP.ISO-2022-JP-1',
    'ja_JP.AJEC',
    'ja_JP.PCK',
    'ja_JP.ujis',
    'ja_JP.Shift_JIS',
    'ja_JP.x-sjis',
    'ja_JP.SJIS',
    'ja_JP.sjis',
):
    setlocale(LC_ALL, l)
    print '%-24s'% l, getlocale()
----------------------- script end -----------------------------



result on RHL6.2(En)
----------------------- result -----------------------------
linux2
en_US                    ['en_US', 'ISO8859-1']
en_US.ASCII              ['en_US', 'ISO8859-1']
en_US.US-ASCII           ['en_US', 'ISO8859-1']
en_US.latin-1            ['en_US', 'ISO8859-1']
en_US.ISO-8859-1         ['en_US', 'ISO8859-1']
en_US.ISO-8859-2         ['en_US', 'ISO8859-1']
en_US.UTF-8              ['en_US', 'ISO8859-1']
el_GR.ISO-8859-1         ['el_GR', 'ISO8859-7']
el_GR.ISO-8859-2         ['el_GR', 'ISO8859-7']
el_GR.ISO-8859-5         ['el_GR', 'ISO8859-7']
el_GR.ISO-8859-7         ['el_GR', 'ISO8859-7']
el_GR.ISO-2022           ['el_GR', 'ISO8859-7']
el_GR.EUC-JP             ['el_GR', 'ISO8859-7']
ja_JP.UTF-8              ['ja_JP', 'eucJP']
ja_JP.EUC-JP             ['ja_JP', 'eucJP']
ja_JP.ISO-2022           ['ja_JP', 'eucJP']
ja_JP.ISO-2022-JP        ['ja_JP', 'eucJP']
ja_JP.ISO-2022-JP-1      ['ja_JP', 'eucJP']
ja_JP.AJEC               ['ja_JP', 'eucJP']
ja_JP.PCK                ['ja_JP', 'eucJP']
ja_JP.ujis               ['ja_JP', 'eucJP']
ja_JP.Shift_JIS          ['ja_JP', 'eucJP']
ja_JP.x-sjis             ['ja_JP', 'eucJP']
ja_JP.SJIS               ['ja_JP', 'eucJP']
ja_JP.sjis               ['ja_JP', 'eucJP']
----------------------- result end -----------------------------


Wow, maybe we could say something like that?:


> 1) adopting new environment value
  - platform-neutral: no different behaviour on different platform
  - could set an encoding which mismatches with C's locale behaviour

> 2) using locale.getlocale()[1]
  - better accordance of locale setting and encoding setting
  - may affect on the behaviour of other components which depends on C's lo=
cale
  - the supported encodings are limited to the available ones on the platfo=
rm
  - eliminate irregular combination of locale(lang+territory) + encoding




Regards,
---
Heiichiro NAKAMURA <nheiich@quantumfusion.com>