Login | Register For Free | Help
Search for: (Advanced)

Mailing List Archive: Zope: Dev

Have any ideas for aliasing meta type, role name, etc?

 

 

Zope dev RSS feed   Index | Next | Previous | View Threaded


kslee at plaza1

Mar 7, 1999, 8:43 PM

Post #1 of 2 (465 views)
Permalink
Have any ideas for aliasing meta type, role name, etc?

Hi, Zopistas,

I've been translating Zope frame work into Korean, as I told before and
almost nobody showed interest.
Now what I call KZope seems working, though many dtml files are to be
translated still.

Currently, KZope shows part Korean, part English screens. I guess the
relative easy of translating Zope into another human language comes from
that many key words of Zope frame work are stored as a value of
dictionary(right?).

BUT, there IS a Problem. What if one export/import Zope objects between
EZope & KZope? It shows wired things. And I guess this comes from that
object from EZope or KZope has different meta infos.

One possible solution is much further dissociation of "Presentation"
from "Logic". See the example below from OFS/Folder.py(don't worry of
strange characters or boxes in <from KZope> column. That is (or was)
Korean chars)

<from EZope> <from KZope>

class Folder(....): class Folder( ... ):
""" ... ...
"""
meta_type='Folder' <-a-> meta_type='Æú´õ'
id ='folder' <-b-> id ='folder'
title ='Folder object' <-c-> title ='Æú´õ °´Ã¼'
icon ='p_/folder' <-d-> icon ='p_/folder'

meta_type and title strings appear on the screen. So I translate them.
id will be a part of url, so I'd better not translate them. icon string
is Zope frame work default. So I do not.

I SEE a some lack of consistency here. Why should part of internal
python code(meta_type) will appear on the user screen? Don't you think
DTML part of Zope frame work should control what appears on the user
screen?

What, I guess, to be a solution is making meta_type, role, etc into a
tuple which inclues a dictionay. i.e.
meta_type=('Folder', {'default':'Folder', 'Korean':'Æú´õ',
'German':'XXX', 'Czech':'YYY'})
__ac_roles__=(
('Manager', {'default':'Manager', 'Korean':'°ü¸®ÀÚ',
'German':'xxx', 'Czech':'yyy'}),
('Anonymous', {...} )
)

Oh, yes, this is a HUGE & comples task and DC will not benefit from this
in a near future. And I do not ask DC to do so.

What I want is the suggestions from the more knowledgables. Could be
there much more simple and elegant way? tuplizing meta infomation will
punish the performance too much? Will the Zope frame work structure be
altered to make this kinds approach impossible?

Just think Globally. Dream of the soon-to-be-huge China market.
Possible BENEFITS of 'tuplizing' meta infos will include safer route to
upgrading individual Zope Products.

LEE Kwan Soo.

ps. If my English expressions are offensive, that's not my intention but
the showcase of how hard to use English.


brian at garage

Mar 8, 1999, 3:54 AM

Post #2 of 2 (447 views)
Permalink
Re: Have any ideas for aliasing meta type, role name, etc? [In reply to]

Hi there!

"LEE, Kwan Soo" <kslee [at] plaza1> wrote:

> Hi, Zopistas,
>
> I've been translating Zope frame work into Korean, as I told before and
> almost nobody showed interest.
I'm interested - I'm working on using Zope with Japanese.
Probably we are interested in doing similar things -

> Now what I call KZope seems working, though many dtml files are to be
> translated still.
Great! I have been translating only the parts which are visible to the
outside (error messages, etc.)

> One possible solution is much further dissociation of "Presentation"
> from "Logic". See the example below from OFS/Folder.py(don't worry of
> strange characters or boxes in <from KZope> column. That is (or was)
> Korean chars)
I agree with this idea - I have been thinking about a different way to
solve it, however. Specifically, I think that a better way might be to
create a special Product that would define the locale for the system on
a per-directory basis - call this Product ZLocale. It would consitute
something of an additional, separate API and compliant classes could
implement all of their management interfaces, and even parts of their
content by referring to variables contained in the locale object,
instead of to hard-coded strings embedded in the code (which is easiest
to do but also makes internationalization a pain in the neck).

I haven't thought enough about how this would work yet to implement it
(and implementing it would still mean a lot of work! - I guess the
up-side is that I would get to learn a lot about how Zope works internally)
but there would be a ZLocale class which could be inherited & acquired from
and would define all of the necessary strings. It would also be cool to
be able to change locale on the fly, or print out documents based on
browser language setting, etc.

Anyways, let's talk more about this! Good luck!

--brian hooper

Zope dev RSS feed   Index | Next | Previous | View Threaded
 
 


Interested in having your list archived? Contact Gossamer Threads
 
  Web Applications & Managed Hosting Powered by Gossamer Threads Inc.