[Chameleon] Chameleon and internationalization

[Paul Spencer]

last time I checked, adodb was pretty 'heavy weight'.  It's nice to have 
the flexibility ... but Chameleon is already pretty bloated and I am 
actively trying to trim it down.  I'm not knocking adodb, we already use 
it for some stuff (there is a copy in php_utils cvs).  I guess I should 
update that version and try the latest to see how much overhead it adds...

Cheers,

Paul

Open Wereld wrote:
> Paul,
> 
> Why not consider using a database abstraction layer such as ADODB 
> (http://adodb.sourceforge.net/)? It supports SQLite, but it would also 
> give Chameleon users the option to use different databases like MySQL or 
> PostgreSQL for their user authentication. In case they would like to 
> combine Chameleon with CMS'es like Drupal or Tikiwiki, I would guess 
> they can use the same user data for both.
> 
> Greetings,
> John.
> 
> Paul Spencer schreef:
> 
>> Bart,
>>
>> I am just starting to build a user authentication system that will be 
>> integrated into the core of Chameleon.  The basis of this will be an 
>> sqlite database.  sqlite seems pretty amazing, a full SQL database 
>> engine without requiring a separate SQL server, everything is stored 
>> in a single file.  I'm thinking of moving all the language stuff to 
>> use sqlite.  I'm not exactly sure how this would solve this problem, 
>> but I think it will help.  We could then have a table for all the keys 
>> and separate tables for each language, with SQL statements to make the 
>> joins ...
>>
>> something like "select * from tbl_core, tbl_".$szCurrentLanguage." 
>> where tbl_core.id=tbl_".$szCurrentLanguage." and tbl_core.id=".$nResource
>>
>> um... that probably wouldn't do it completely ... but something like 
>> that.
>>
>> Waddyathink?
>>
>> I have a pile of German translations that were contributed, but 
>> haven't made it in for the same reason you have indicated.
>>
>> Paul
>>
>> bartvde at xs4all.nl wrote:
>>
>>> Hi list,
>>>
>>> the current Chameleon internationalization uses a language dbf file per
>>> widget, in which every language occupies a column in the dbf.
>>>
>>> With updates from Chameleon coming it, this is a difficult system to
>>> maintain. Maybe widgets have been updated with new keys in the dbf, 
>>> so the
>>> widget dbf file has been altered. This will mean you will need to get 
>>> your
>>> own language added to the new dbf again.
>>>
>>> What options would there be to simplify this process?
>>> -have separate dbf files per language, and make joins?
>>> -maintain the language resources in XML files, which can be validated
>>> whether or not they contain all the keys which need to be in there,
>>> assuming keys will end up being XML elements?
>>>
>>> Any other ideas? Are there any plans to change this system?
>>>
>>> Best regards,
>>> Bart
>>>
>>> _______________________________________________
>>> Chameleon mailing list
>>> Chameleon at lists.maptools.org
>>> http://lists.maptools.org/mailman/listinfo/chameleon
>>>
>>
> 
> 

-- 
+-----------------------------------------------------------------+
|Paul Spencer                           pspencer at dmsolutions.ca   |
+-----------------------------------------------------------------+
|Applications & Software Development                              |
|DM Solutions Group Inc                 http://www.dmsolutions.ca/|
+-----------------------------------------------------------------+