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

[Kazuya FUKAMACHI]

On Thu, 12 Dec 2002 15:51:48 -0800
Heiichiro NAKAMURA <nheiich@quantumfusion.com> wrote:

> I guess the problem is the difference of char-encoding naming
> convention: even among Posix-complient OSes, the naming of encodings
> are vender dependent (the situation is the same among RDBMS vendors).
> If I were to use Russian patch, I might put one abstraction in the
> char-encoding-name handling by providing some facilities like:

Probably you're right.
I do agree your approach bellow.

> def getDefaultPythonCharEncodingName():
>     if os.name == 'posix':
>         return charEncodingMap.get(locale.getlocale()[1], 'latin1')
>     else:  # For MS Windows
>        return os.environ.get('Z_CHAR_ENCODING', 'latin1')
[snip]
> IANACharEncodingMap = {
>     'SJIS': 'Shift_JIS'
>     ...
> }
> 
> 
> Sooner or later, I think this kind of mechanism will be required
> for the mature support of Unicode, as Unicode brings a lot of
> this kind of problems. Without the rational addressing of such issues,
> the support of Unicode shouldn't be called mature I think.
> 
> Still I don't like this patch's approach very much because
> this is the per-server-instance configuration, not useful
> for building M17N web site.

- per-server-instance configuration
- not useful for building M17N web site

I agree.


> > > 5) Toby's proposal
> 
> Probably it's a preferable choice.
> 
> My concern is I'm afraid if Toby is too busy to do that.

Yes, I'm also afraid so.
It's very difficult to provide a perfect solution.

> Since none of the choices(1-5) provide the perfect solution,
> all of them are just a temporary patch for the urgent fix of
> the severe issue (Collector 623).

As a temporary patch, 
+1
3) TAHARA's patch:
     http://lists.zope.org/pipermail/zope-dev/2002-November/018198.html
     - need fix of some problems

It has some problems but easy to patch and start to use,
and also easy to remove after complete solution is provided.
If Toby will take some time, I will use 3) for a while.

But, if it takes a few months or longer,
I will try to modify Russian patch as an experiment,
maybe taking in your approach in some degree.
Is that bad idea?

> So, I think it shouldn't take too much time (we shouldn't spend
> too much time).

Maybe, we should separate the problem into temporary patch
and complete solution, if it takes much time.