You need to log in before you can comment on or make changes to this bug.
It is not possible to translate chameleon in other language without change a lot of *.php, *.phtml, *.html. All visible words should be able to manage with *.dbf files. To improve a translation, it will be nice to have all *.dbf files in one folder. Example: 'Current' was found in a MapSize Widget file, and not MapSize.dbf.
This is an ongoing issue. Every piece of text that Chameleon displays should be retrieved from the translation service (MLT) but we have been somewhat lax in making sure this happens everywhere. If you can point out specific widgets that require changes, please record them in this bug and I will scan them for words and phrases that require translation and add them to the appropriate dbf files. We originally had all the dbf files in a common folder, however this proved to make it difficult to maintain and distribute widgets independently of Chameleon so we chose to put all files related to a single widget in the same directory. One thing that I think makes it difficult to translate is a lack of 'context', i.e. the words and phrases in the dbf file sometimes could have several translations depending on the context in which it is used in the interface. Determining where a given word is used requires inspecting the code in some cases, which is less than desirable. An optimal solution would be to: 1. provide a visual interface for modifying the language dbf files. This would list all the widgets, and when you clicked a widget it would present you with a table of all the values and their various translations. It would allow you to modify any text and add new values for use in the interface. 2. provide a global setting that would display the 'key' of every translateable word or phrase so that screen shots could be taken. For instance, if the word 'close' is key '4' in a given dbf file, then in this special translation mode, the phrase would be displayed as (4) close so that the translator can easily see where the phrase is on the screen and its context and can choose an appropriate translation based on this context.
Changed target to FUTURE.
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.
up'ing priority ... hoping to get this done for 2.2 final
Added myself to the cc.
Paul, I would tend to agree with you that option 3 would be the most convenient. Separate files per language, per widget. Would be nice if there would be a good warning system when a separate language file misses one of the keys defined in the widget php code. Maybe a script which can check this or something like that. Bart
add myself as cc
It seems that other php packages are using include files. I also agree that it would be better that way. Faster, easy to maintain, human readable. Let's mark it as future since it's clear it won't make it in 2.2.
I think the new MLT took care of this. Marking as FIXED
