Hello,
Carmelo wrote:
> About the gettext, I agree with you, Alexander, actually I think
> that a gettext function can be usefull for messages( error, warnig,
> etc) or labels and all sort of short phrases or words but not for
> objects. So if we want to internationalize we need to make some
> changes to the database.
Yes, it was the way I went when created Russian Midgard: database was
replaced with completely new version of Admin Site with russian
messages. But I didn't change anything beyond database content.
> I think I will work on version 2 of midgard. I already began to
> design a first draft for the database so we can have a word about
> it. I send the model on a jpeg image as an attached file. I used the
> midgard 2 scheme to begin my work, and I put all the common
> properties in one table object, which will make it easier if whe
> need to add properties(fields) to our objects. Then each object has
> its specific table with its specific properties(fields), now if we
> add a clang field in the specific tables for the objects that need
> translations( here page, pageelement and element) , we will only
> then to have one record for each language, the primary key is then
> the object id and the language code in the specific table. the
> object table will only have one record per object and then to fetch
> an object we only have to add the language code in the url :
> for instance where we have actually "http://path" we will have "http://LC/path"
>where LC
> stand for a two letter iso code for the language( EN for english, FR
> for french, etc). This way we will be able to cache pages for each
> language, because if we had the same url (we could using an internal
> variable) for two different languages, we would not be able to cache
> pages. We only need then to look in the language table to have the
> charset for each language to make the formatting.(the language table
> can be hard coded for performance since it's not a data that is
> likely to change often).
Yes, I suggested the same idea some time ago. This modification at the
database level will require also changes in mod_midgard in order to
allow dynamical rewritting of URI that will be processed by Midgard
engine (http://LC/path -> http://path and setting up special field
'language' in $midgard system variable). In such situation we'll get
system that automatically selects right content from database using
$midgard->language field as a language ID.
Also the following problem will arrive: with this rewritting of path
(which is required for proper object aquision) we'll get problems with
absolute URLs in user's code, because it should be care about actual
path of document. I think that it could be solved by dynamic
rewritting of 'prefix' field of host (simply add LC value for current
request when mgd_get_host() function is called) and by using links
like <a href="&(prefix);some_document">text</a>. It is required anyway
for completely 'location-aware' sites - I already used such techniques
(&(prefix); for hrefs) in Russian Midgard's Admin Site in order to
allow placement of site anywhere on the path.
Thus, site could be placed, for example, at
http://my.domain.com/some/path/EN/real/document/ or
http://my.domain.com/some/path/FR/real/document/ or
http://my.domain.com/some/path/RU/real/document/ and it should be
correctly processed with prefix set up to '/some/path/', LC set up to
one of EN,FR,RU, and requested document will be find in database at
'/real/document/' location. And when user requests host information,
i.e., for creating $prefix variable used in previous example:
$host=mgd_get_host($midgard->host);
$prefix=$host->prefix;
this $host->prefix will already contain current 'LC' value.
(mgd_get_host() will use stored $midgard->language value which will be
filled previously by the mod_midgard engine).
Of course, this behaviour should be optional, for example, it could be
modified in Apache's configuration by some directive like
MidgardMultiLang (on/off/disable).
Best regards,
Alexander mailto:[EMAIL PROTECTED]
--
This is The Midgard Project's mailing list. For more information,
please visit the project's web site at http://www.midgard-project.org
To unsubscribe the list, send an empty email message to address
[EMAIL PROTECTED]
