On Thu, 2004-02-05 at 15:46, Shaunak Kashyap wrote: > > My inclination would be to just use the DB, have linked tables with > > languages and pieces of text in various languages. A single query could > > get a full language preference setting for a site, and a little array > > munging could turn it into a usable set of key/value pairs, where the key > > is the context of the text, and the value if the text itself. > > > > (Been thinking about this alot, since I'm being asked to develop a hybrid > > flash/html site that needs to be in Spanish and English) > > > > Yes, I would also recommend the DB approach. The tables in your DB that > contain language-sensitive information would probably have a languageId > field which you could use to limit your result set to a specific language.
InterJinn uses a mixed approach. When declaring the base template and source file to use to create a target page you can declare a set of language targets to create. When this is done InterJinn automatically retrieves the appropriate language based templates and source files to compile each language target page and when no such language specific content exists falls back on the default. In this way language specific content can be segregated into easily manageable templates. On the second level InterJinn supports a property system which can be language based. In this case the language of the page is used to determine which language specific property to retrieve (fallback is again to the site's default language when no such language specific property exists). Using this system developers can override the default language properties with language specific ones and the retrieval is transparent to the application. As part of the property system, InterJinn also supports properties which are set to the result set of a query. For simplicity when declring properties, some properties recognize an expandable [[LANG]] macro (configurable individually for each property if the developer needs some other macro) which is filled with the current language at query time. So then retrieving a dataset of language specific entries is as simple as desiging a table with a language field. This all sounds very heavy on processing, and it is, but the results are cached (unless the property is set to volatile which is rare) and so the expensive hit only occurs the first time. Cheers, Rob. -- .------------------------------------------------------------. | InterJinn Application Framework - http://www.interjinn.com | :------------------------------------------------------------: | An application and templating framework for PHP. Boasting | | a powerful, scalable system for accessing system services | | such as forms, properties, sessions, and caches. InterJinn | | also provides an extremely flexible architecture for | | creating re-usable components quickly and easily. | `------------------------------------------------------------' -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
