Bug 961 - ClearWFSFilter contains hardcoded message in English
: ClearWFSFilter contains hardcoded message in English
Status: RESOLVED FIXED
: Chameleon
Widget
: 2.0
: PC Windows XP
: P2 normal
: ---
Assigned To:
:
:
:
:
:
  Show dependency treegraph
 
Reported: 2005-02-16 07:47 by
Modified: 2006-03-13 17:10 (History)


Attachments


Note

You need to log in before you can comment on or make changes to this bug.


Description From 2005-02-16 07:47:33
The message for the javascript confirm in ClearWFSFilter.widget.php (line 198)
is hardcoded in English. This should be done according to the language that is
set (using clearwfsfilter.dbf).
------- Comment #1 From 2006-02-14 14:49:11 -------
I know this bug was found on Windows so I will still have to investigate a
little bit on this platform.  There is a case sensitive problem on Linux.  This
is not a problem related only to this widget but a more general one.  

The widget files name and their directory in which they are located, are written
by using upper/lower case characters.  In Widget.php, the MLT loadResource
method is called with two parameters return by the "get_class" PHP function
(~line 287, see code snippet below).  This function does not keep the original
notation when used with PHP 4.0.  Also the MLT loadResource and get methods
change the parameters notation with the strtolower function.

When Chameleon tries to load the resource the files are never found and the MLT
structure is not filled with the languages resource.


-----------------------------------------
Code around line 287

        // pass a copy of the application MLT object to the widget
        $this->moMLT = &$this->moApp->moGlobalMLT;

        // load the resourcre file into memory
        if ( is_object( $this->moMLT ) )
        {

            $this->moMLT->loadResource( get_class( $this ),
                str_replace("\\","/",dirname(__FILE__) ).'/'.
                get_class( $this ) );
------- Comment #2 From 2006-02-15 10:52:35 -------
I investigated on Windows and I found that it was not really a bug.  Chameleon
uses the "$aszLang" session variable to create the MLT instance.  This variable
is initialized by the "CWCAddRegionalTemplate" Chameleon method call in the
application file.  If this variable is not initialized, the "maszLanguage" MLT
member is empty and the resource is never loaded by the "loadResource" MLT method.

Solution:  We have to call "CWCAddRegionalTemplate" Chameleon method with the
name of the template we used eventhough we are using only one language.

Suggestion:  In chameleon.php we could add a test to verify if the "$aszLang"
session variable is empty, if yes we could use "mszCurrentLanguage" Chameleon
member instead (see code snippet below).

---------------------------------

if( count($_SESSION['aszLang']) )
{
    $this->moGlobalMLT = new MLTPHPInclude( $szUniqueFileName,
                         $_SESSION['aszLang'], MLT_NOCACHE );
}
else if ( isset( $this->mszCurrentLanguage) )
{

    $this->moGlobalMLT = new MLTPHPInclude( $szUniqueFileName,
                       $this->mszCurrentLanguage, MLT_NOCACHE );
}
------- Comment #3 From 2006-03-06 12:52:02 -------
Added a test in chameleon.php to verify that aszLang session variable is set, if
not set, use mszCurrentLanguage instead when MLTPHPInclude is instanciated
(comment #2).

Moved the code presented in comment #1 from Widget.php to WidgetManager.php and
used the widgetname instead of the get_class method.

Removed strtower($szID) from MLTPHPInclude loadResource() and get() methods.
------- Comment #4 From 2006-03-06 13:14:32 -------
There is another problem related to this bug.  The language portion of the
language resource files name is written by using a lower case notation (e.g.
ClearWFSFilter.en-ca.txt).  In chameleon.php the MLTPHPInclude instance is
created with the language string set through CWCAddRegionalTemplate() or the
default_language context value found in the configuration file.  This string is
written with upper and lower cases (e.g. en-CA).  The mlt loadResouce() method
used this string to built the language resource file name.  The resulting file
name looks like:  widgetname.en-CA.txt.  So the loadResource does not found the
language resource file.  The ISO protocol said that the language should be
specified with lower and upper cases (e.g. en-CA).  There are two solutions to
this problem:

1)Add a strtolower() function to the mlt loadResource() method.
2)Rename all language resource files to follow ISO notation.

I prefer the second solution.
------- Comment #5 From 2006-03-10 15:27:45 -------
I renamed the language resource files (comment #4).  I need to test that
everythin is working well.
------- Comment #6 From 2006-03-13 17:10:18 -------
Tested on Linux.