[Dev] internationalization -- string translations in the repository

[Brian Douglas Skinner]

Hi Ducky,

Thanks for pointing out the internationalization issue that comes up in the
event manager.  That maybe leads to a more general question about where
localized strings should be stored...

For some strings, the localized versions can be bundled with the executable
Chandler app.  They could be in some central directory like
"osaf/chandler/Chandler/locale/", or they could be divided up by parcel, so
that when you install a new parcel it has its own self-contained set of
localizations.

But that only works for parcels.  There's the other use case where people
create new domain schemas without writing any python code to go with them.
For example, let's say somebody at Stanford makes a "Geography" domain
schema, for items that represent Cities and States, and Countries.  And they
populate it with items like Moscow and Texas and Spain.  And then someone at
Universitat de Barcelona wants to add Spanish language localizations, with
translations for the names of Kinds, like "Cities", and for the names of
Attributes, like "population", and maybe for the names of some individual
Items, like "Spain".  Those localizations need to be stored in the
repository, not in a python parcel.

In our data model meetings last week, we talked about having the data model
support the idea of "polyglot strings" -- strings that can have key-value
pairs of localized translations, keyed by language.

If the repository has built in support for polyglot strings, then we could
use them not only for domain schemas, but for storing all our text
localizations for any string that Chandler shows to the end-user, including
the eventDescriptions used by the event manager.  There are pros and cons to
storing the strings in the repository instead of in parcels, but it might be
worth thinking about.

- Brian





-----Original Message-----
Date: Tue, 03 Jun 2003 11:17:21 -0700
From: Kaitlin Duck Sherwood <ducky@osafoundation.org>
To: andy@differnet.com
CC: dev@osafoundation.org
Subject: [Dev] Re: TWiki . Main . EventModel

Andy Hertzfeld wrote:

> The initial draft of an event manager API (which is one of the key
> building blocks for agents) is up on the public wiki for your review.
> Let me know if you have any questions, comments or suggestions.

Andy --

There is an internationalization issue with the event manager API.  They
probably aren't deadly, but bear a mention.

First, if the eventDescription will be shown to the end-user sometimes,
it will need to be localizable.   Gettext can do localization on the
event-generating side, e.g.
    emailArrivalEvent.SetDescription(self, _("A message arrived."))
but I can imagine some pathological cases where an event is generated in
one language and the description is viewed in another (this could easily
happen when events are generated remotely).  If Nakamura-san sends me a
meetingChangedEvent, it will be less useful to me if the description is
in Japanese.

This means that you want to use the eventName on the event receiving
side as a key to get the eventDescription on the receiving side.   (Of
course, then you need to deal somehow with cases where there is no
eventName<->eventDescription pair on the receiving side -- probably by
using the eventDescription that comes with the posted event, even if it
is in Japanese.)

(It also might be that if you receive an unrecognized event, you should
just drop it on the floor.  Even simply displaying the eventDescription
sounds undesirable: I *really* don't want to be getting hundreds of
blort2861Events with eventDescriptions of "Call 1-900-BUY-TOYS now!"
getting presented to me.)



Also, unrelated to internationalization: I presume that
    FindEvent returns an event if it finds one and Null otherwise,
and that
   PostEvent returns true if successful and false otherwise,
but it would be good to say so explicitly in the spec.