[Chameleon-dev] [Bug 817] [Chameleon - core] translations

[bugzilla-daemon at maptools.org]

http://www.maptools.org/bugzilla/show_bug.cgi?id=817





------- Additional Comments From pspencer at dmsolutions.ca  2005-05-09 09:35 -------
reviving this  bug, or at least bringing it to the top of the priority list.

I need input from the development community on this issue because I don't really
have a good answer and I would like to know what the most convenient mechanism
would be to maintain multiple languages.

Options so far:

1. status quo, using dbf files, one per widget plus a common one.

2. switch to sqlite, advantages being possibly faster, probably easier to
maintain.  Difficult to integrate new widgets for merging unless all widgets
kept separate

3. switch to php includes.  I've seen this done a couple of times, everything is
kept in 'language' folders with the resource file named for the language, i.e.
en-CA.php etc and this file is included at run time based on langauge.  Easier
to maintain (don't need special client).

Other issues:

* centralize/decentralize?  should all the language resources go in a single
file, single directory or be spread out amongst widgets?  Incentive to keep with
widgets is possible future enhancement to allow installation of multiple
versions of a given widget or group of widgets

* storage format: 
  - dbf is universally supported but limited to 8bit character sets and 255
characters per string.  Access is fast and file format is portable
  - sqlite offers SQL interface, performance seems reasonable, easy to
distribute since it doesn't require an SQL server.  Versions of this library are
not compatible (i.e. 2 and 3 are not compatible) which could cause problems when
sqlite versions are updated in php versions.  It has potentially unlimited
storage space per string, plus option to store non-character data.  Not sure how
extended character sets are handled.  Difficult to edit without some sort of app
interface
  - php included files.  Easy to maintain, easy to edit, probably optimally fast
and could fit either the centralized or decentralized model.

I am tending towards switching entirely to a php-include-file based system but I
want to know what others think. 



------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.


Please do NOT reply to this email, use the link above instead to 
login to bugzilla and submit your comment. Any email reply to this
address will be lost.