Forum OpenACS Development: Re: named objects

12: Re: named objects (response to 11)
Posted by Timo Hentschel on
No, you can't be serious about that. That's exactly a design i want to avoid. Think about it. Adding a locale field will get you into deep trouble because what if you want to get the names of all objects in german, but most of them are not available in german? You should fall back to display whatever language is available (most likely the default language). I don't see a way to do that kind of query in a fast and scalable way or do you?. And caching the names of all objects? I don't think so. The system can be huge and although memory might be cheap, I just think that's too much.
13: Re: named objects (response to 12)
Posted by Dirk Gomez on

How do you intend to support I18N then? Not only for categorization, but also for *every* other package in the system?

In a document called "Best Practices for Globalization using the Oracle 9i Internet Application Server" to which I was pointed at by Mohan, Oracle suggests this:

-- fallback language is English which is abbreviated as 'US'.
CREATE VIEW default_message_view 
  AS SELECT msgid, message 
  FROM messages 
  WHERE langid = 'US'; 

-- create view for services, with fall-back mechanism
CREATE VIEW messages_view AS
SELECT d.msgid,
  CASE WHEN t.message IS NOT NULL 
    THEN t.message 
    ELSE d.message 
  END AS message
FROM default_view d,
  translation t
WHERE t.msgid (+) = d.msgid AND
t.langid (+) = sys_context('USERENV', 'LANG');

SELECT message FROM message_view where msgid = 'hello';

Looks kinda slick: If you don't find a translation with the first index lookup, you need a second one. Shouldn't be that much of a performance impediment: If an average index lookup takes 5 I/O accesses (that's already for a huge table), you add a maximum of 10 I/Os per row.

It *clearly* is much more expensive than returning the name from a row that Oracle has touched anyway (access costs amount to zero there).

The current I18N solution sacrifices performance for tight coupling of related objects. Is it good? I dunno. Is lose coupling - every translated object gets its own row in acs_objects - better. I dunno.

23: Re: named objects (response to 12)
Posted by Thomas Taylor on
Have a look at

This i18n package does not support names for objects or such, but at least some multilanguage design is possible.

24: Re: named objects (response to 23)
Posted by Timo Hentschel on
I didn't say that i18n is not possible at all. Actually, my categorization package is multilingual in that categories can be translated in any language. I'm just saying that doing i18n for object_names so that you can write fast queries without using a cache is a hard thing to do.