[Chameleon] Chameleon and internationalization

[Christopher R. Thorne]

Bart,
I totally agree with you on this and this is a complicated issue. 

I have been working on the xml widget doc framework and your issues with multi-lingual
content for: widget documentation and application specific content (eg. Maptips, online
help, other app text) is exactly what I hope to be able to handle in the widget docs. :)

Unfortunately, Between Paul and I we have only been talking about this and have not
defined a plan of attack.

In the meantime, I personally don't have a solution for better managing your languages
content in the dbf files. 

maybe you could write a dbf script routine that appends the language column to the new
installation of Chameleon????? I don't know.

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>
>