[Chameleon] Chameleon and internationalization

[Christopher R. Thorne]

oops sorry for resending my last message. :)
what I want to say was:

That Paul's idea makes sense in using sqllite for some application specific thinks, the
xml widget docs is mostly for documentation widgets, rather than application content. the
is except for the embedded help content for this widget. 

The risk of adding more chameleon php extensions dependances eg. sablot, iconv.... is much
higher when of course managing text within xml.

Currently only the Doc builder utility depends on this. The help viewer also has XML
translation to HTML ability, but is defaulted on chameleon release to only view html.

Chris 


On Feb 11, Paul Spencer <pspencer at dmsolutions.ca> wrote:
> 
> 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
> > <a
href='http://lists.maptools.org/mailman/listinfo/chameleon'>http://lists.maptools.org/mailman/listinfo/chameleon</a>
> > 
> 
> -- 
> +-----------------------------------------------------------------+
> |Paul Spencer                           pspencer at dmsolutions.ca   |
> +-----------------------------------------------------------------+
> |Applications & Software Development                              |
> |DM Solutions Group Inc                 <a
href='http://www.dmsolutions.ca/|'>http://www.dmsolutions.ca/|</a>
> +-----------------------------------------------------------------+
> _______________________________________________
> Chameleon mailing list
> Chameleon at lists.maptools.org
> <a
href='http://lists.maptools.org/mailman/listinfo/chameleon'>http://lists.maptools.org/mailman/listinfo/chameleon</a>
>