[home] [home]
[home] HTDB : Docs : Roadmap : Internationalization Architecture
[home] [home] [home] [home]
[home]
About
Overview
Philosophy
Features
News
Download
Help Us!

Docs
Overview
Designers
Developers
Roadmap
Cobranding#1
Cobranding#2
Ramblings
URI maps
Architecture

Community
Powered By

[home]
there's a certain heirarchy to the storage of HTDB documents, namely:
htdb/[LANG]/[BRAND]/*.htdb
in htdb/config.htdb, there are a couple of important defs:
#define confDefaultLanguage en
#define confDefaultBranding adjective.com
this is how the system knows where the default source documents are located at
htdb/en/adjective.com
why are things like this? because someday, we may need to run "parallel" websites with content in multiple languages, or with an all-encompassing cobranding presence.

how does this work?

the default value of ${confDefaultLanguage} can be over-ridden by setting "user.language". the default value of ${confDefaultBranding} can be over-ridden by setting the value of "affiliate.cobrand".

here's how it works:

  • for every page request, everything works as normal - all the documents needed for a page are read. *then*, if the language and/or brand values have been over-ridden, it goes and reads the same files down in htdb/[LANG]/[BRAND]/.
  • here's the sexy bit - you don't have to have a complete parallel website - you only need to redefine those values you want to clobber the standard values. so the templates and frameworks only need to be defined once, and you over-ride the standard text by setting them in the parallel world.
and here's where it doesn't work:
  • cached files. we haven't always had cached files. in essence for this to work again, all resource values, when stored, need to have two bits also set: language and branding. this way, the same named resource can reside in the cached namespace, but we'll be able to retrieve the right value when it is needed.
  • images. /images/ really needs to be renamed /images/[LANG]/[BRAND]/ and the value of ${images} needs to dynamically be defined down the right path. note that unlike text definitions, all images will truly need to be made completely in parallel.
  • the future. the end-game for HTDB is to always have all resources completely in memory all the time and all evaluations done at use-time. we're partly there with script functions already, since they're cached. in such a world, the language/brand attributes of resources as stored becomes key. at such time a persistent "resource server" can replace the in-memory storage altogether. tuxedo anyone? java servelets? image that htdb_getval("name") is actually a wrapper for: htdb_low_getval("user.language", "affiliate.cobrand", "name") and you get the idea.
why am i even bringing this up?

i dunno. because i just made parts of the site appear in french to me and realized that some work remains to be able completely support multi languages again. and that we're not too far off if we ever really need to.

-del
Thu, 4 Oct 2001 22:48:13 -0700 (PDT)

   
5,850 impressions