Future Japanese Language Pack Status, version 1.5.5 and beyond...

Quote:

---

Originally Posted by mc12345678

With regards to some of the "overrides". It depends on what is needed to be done, obtained or modified, but the following files have notifiers that can be used by an observer class to modify the data that is present without modifying the files specifically:

2. includes/classes/order.php
4. includes/modules/pages/account_edit/header_php.php
5. includes/modules/pages/address_book_process/header_php.php
6. includes/modules/pages/contact_us/header_php.php


While I haven't looked at what changes may be considered necessary to includes/application_top.php it seems that there would likely be some other way to make the changes necessary to support the additional software/configurations.

---

Regarding the use of notifiers/observers, I've written a lot below, but it I think it will help you moving forward with using notifiers where it is possible to
do so without duplicating too much code or otherwise modifying the original file(s).

I haven't looked into the specific code change(s) for any of these files, but let me identify a way that you can access the data that exists at the point a notifier is encountered.

Looking at item 4 of the above list: 4. includes/modules/pages/account_edit/header_php.php

If you open the file, you should see several notifiers:

Code:

---

$zco_notifier->notify('NOTIFY_HEADER_START_ACCOUNT_EDIT');

---

Code:

---

// check external hook for duplicate email address, so we can reject the change if duplicates aren't allowed externally
  // (the observers should set any messageStack output as needed)
  $nick_error = false;
  $zco_notifier->notify('NOTIFY_NICK_CHECK_FOR_EXISTING_EMAIL', $email_address, $nick_error, $nick);
  if ($nick_error) $error = true;

---

Code:

---

$zco_notifier->notify('NOTIFY_HEADER_ACCOUNT_EDIT_VERIFY_COMPLETE');

---

Code:

---

$zco_notifier->notify('NOTIFY_NICK_UPDATE_EMAIL_ADDRESS', $nick, $db->prepareInput($email_address));

---

Code:

---

$zco_notifier->notify('NOTIFY_HEADER_ACCOUNT_EDIT_UPDATES_COMPLETE');

---

and

Code:

---

$zco_notifier->notify('NOTIFY_HEADER_END_ACCOUNT_EDIT');

---

Each one of these offers a "stopping" point to read data that is present up to that point, in some cases to directly edit the data sent to the observer, the ability to access global data that is present at the time and to possibly redirect to some other place if desired...

From the store side this is typically done from files that are properly formatted and loaded in the includes/classes/observers directory.

As of ZC 1.5.3, there has been a way to let the observer auto load (if it is ok to load "late" in the process) or like has been available since 1.3.x at some point to identify the load point.

Basically, a class is created that extends the base class so that when these notifiers announce that the code has reached that point, then the observer can perform its magic.

The "guidelines" for the auto load process are identified in the comments of: includes/init_includes/init_observers.php

Those comments also elude to a way to incorporate an observer using the "old-style" of having an includes/auto_loaders file that processes data to provide an observer class.

an example of the ZC 1.5.3 and above observer loaded at load-point 180 would be something like:

filename: includes/classes/observers/auto.japanese_observer.php
contents:

Code:

---

<?php
class zcObserverJapaneseObserver extends base {

    function __construct() {
        $attachNotifier = array();

        $attachNotifier[] = 'NOTIFY_HEADER_START_ACCOUNT_EDIT'; // included if  want to observe the data and/or manipulate the data at that point.
        $attachNotifier[] = 'NOTIFY_NICK_CHECK_FOR_EXISTING_EMAIL';
        //  ... Etc for each notifier that this particular Japanese Observer should "listen" for.

        $this->attach($this, $attachNotifier);

        // Set any other class related data that may be needed to pass between  functions or otherwise be maintained to support the overall process when  using this observer
    }

    // To support use of new  functionality added and supported in ZC 1.5.3 and above "unique"  observers formed by "camelizing" (Removing underscore
    //  and  then capitalizing the first letter of the next word.  At this time, PHP  does not differentiate functions that use or don't use capitalization;
    //  however, it makes the text easier to read and maintaining such  consistency is a good practice especially if in the future  capitalization becomes
    //  necessary.
    //  This is the  function that is called when the notifier is met in a ZC 1.5.3+ system  and it is expected by attempting to access the notifier:
    //  NOTIFY_NICK_CHECK_FOR_EXISTING_EMAIL
    //  My recommendation when writing such code is to include the  non-camelized notifier at/around the function that is written this way  to make
    //    finding it's use easier.
    //  Also, I  recommend adding pertinent information about how the notifier was  "first" used in the base code so that if/when it changes the changes
    //    can further be handled/addressed.  It has been known to change  between ZC versions and tracking down why code isn't working can be
    //    a little harder because this code is not "visually" inline with the execution point.
    function updateNotifyHeaderStartAccountEdit(&$callingClass,  $notifier) { // Note, no other parameters are provided here because the  notifier does not include any additional parameters.  Others could be  added for this style of function without default value as the base code  will send data for each of the first 12 parameters.
        //  Perform whatever is desired/necessary when this point in the code is  reached.  If there is data desired to be obtained at this point
        //  (ie. if there are modifications before this notifier or between  this notifier and the next that is to be "generated" or collected, then  need to
        //  use 'global $variable;' where $variable is the  item to be retrieved.  If there is data such as $_POST, $_GET,  $_SESSION, etc... that is to be
        //  used, then generally  speaking that information should be available without the use of global;  however, there are exceptions and sometimes it
        //  is necessary to use the $GLOBALS[] style code.)

        //  Note that any variable that is specifically identified to the class  that has made the call (class could be the base class in this case) is
        //    accessible and modifiable by use of $callingClass->OBJECT_OR_FUNCTION_OR_VARIABLE_ETC.
        //  $notifier contains the name of the notifier that was used to get to  this point which in a more "advanced" situation could be different by
        //    the code of one observer function calling the code of this  observer function.  The other observer function will have received the  name of
        //    notifier that triggered it and then that  notifier variable could be sent to this code.  Within this code  alternate action could be taken if the
        //    the notifier was  not 'NOTIFY_NICK_CHECK_FOR_EXISTING_EMAIL' or it could be taken if it  is a specific notifier, etc...
    }

    // This is the  second notifier presented as an example.  Note from the code at the top  that the notifier has three parameters. The first parameter
    //  ($email_address) is provided as a "read-only" style parameter.  This is  the case for all notifiers even as far back as at least ZC 1.3.9 (I  believe
    //  it was the case further back; however, it is  discouraged to try to support anything pre-1.3.9 due to significant  security concerns and even 1.3.9
    //  had its own issues.
    //    The second and third parameters are possible to be writeable  parameters if the below function is also written to support making  it/them
    //      writeable (&$variable). The base code as of  ZC 1.5.3 supports having 9 total writeable parameters that follow the  one readable only parameter. (10 total when considering the class  variable at the beginning of the parameters below).
    //    ZC  1.5.3 and above will send an empty array for the read-only parameter and  NULL value for all remaining parameters that were not included in
    //      the initial notifier. (ie. if a &$param3, &$param4,  &$param5, etc.. were included in the below function, then each of  those would be NULL)
    // 'NOTIFY_NICK_CHECK_FOR_EXISTING_EMAIL'
    function updateNotifyNickCheckForExistingEmail(&$notifierClass,  $notifier, $observe_email_address, &$observe_nick_error,  &$observe_nick) {
        // Variable names used above beginning  with observe_ were chosen to demonstrate that they can be so named.  They could also be identified
        //  as the variable name that  existed in the original code (ie. $email_address instead of  $observe_email_address) Maintaining consistency between
        //  the original code and this observer can help mentally remember/understand what is being affected.

        //  Again global variables may be needed in this function such as  'global $db;' to support performing operations using $db such as a  query.
        //  Further, depending on where the calling code is  within the global space, typically unless the code is located or loaded  within a function or a
        //    class then the code is in the global space and anything that is present there can be made present here.
        //  For example, passing the value $nick_error in this notifier is  technically unnecessary as it could be accessed by use of 'global  $nick_error;', but
        //    it is better programming form to  include the things that are expected to be used or needed.  It just  wasn't required...

        //  So in here do whatever is desired  to be done with the data.  If the result of processing in this function  were to need to advise of an error,
        //  then changing  $observe_email_error to true would set $error = true back in the  original code.  Again, this is another reason that $nick_error
        //  did not need to be included because $error also could have been  brought into this code using 'global $error;'.  Regardless, there are  some
        //  considerations to be made.  Because a notifier is  provided, it could be used by any code that wants to use it.  This means  that it is possible
        //  that another observer has set  $nick_error to true by the time this code has been loaded.  Therefore  some consideration must be made about
        //  what to do if an  existing $nick_error has occurred.  Should any of the code in here be  processed? Should it be processed regardless? Will the
        //  processing resolve any $nick_error that might have existed and require the status to be changed back to false?
        //  Basically getting to the concept that unless the issue that has  set $nick_error to true is completely resolved within this code  regardless of
        //    why it was set to true, $nick_error  should not be returned or changed to false.  Doing so could cause  problems downstream in the code.

        //  Any changes made to  $observe_nick will be carried over and back to the original code.  Changes made to $observe_email_address will be "lost"
        //    when the code returns.

    }

    //  With this particular calling file and there being so many notifiers  within it, there may be data that exists at one notifier, that is  needed to be
    //    used in another notifier section with it in  the condition/state as originally provided.  Meaning, it may be  necessary to store a value in the class
    //    to be used later in  processing or to replace something that had been set.  Note that such  "storage" is basically by session, so do not get
    //    yourself  wrapped up in what is happening within the class because of someone else  also navigating unless you are changing database settings
    //    or for some reason there is a need to account for all people doing something specific.


    // Then there is the update() function which has existed since observers were generated (or thereabouts).
    // The update() function in a pre-ZC 1.5.3 store only receives the  first three parameters similar to the above function.  It does not  receive any of
    //  the remaining parameters.  Therefore, the  remaining parameters in a pre-ZC 1.5.3 store also will not have any  default value assigned to them by
    //  ZC core code.  This is  important to recognize if this code could possibly be installed on a  pre-ZC 1.5.3 store.  Why? without a default value
    //  assigned,  when the notifier is encountered (also assuming it exists in the "older"  code), then the code/store will stop execution because the
    //  variables do not have an assignment (if a default assignment is not provided like below).
    // The update() function in ZC 1.5.3 and above will for the first 12  parameters receive the value provided in the notifier or a value of NULL  if the
    //  parameter is not provided. In this case, the code  will execute fine if the below function does not have a default value  assigned like what has
    //  been done.  So the question becomes,  why would the below update function code be provided/produced to cause a  store to basically crash
    //  instead of to either silently not support this added functionality or actually support the operation?

    //  The other part about this function is that the update function is  called in ZC 1.5.3 and above if the camelized function(s) like above are  not
    //    found.  So, as a point of note, if the code above is  not executed, it may be that the function is "misspelt". The misspelling  could be on purpose
    //    so that the code of the update function is called, or it could be by accident.

    //  Here is a format for the update() function that would support any version to date that has an observer system.
    function update(&$callingClass, $notifier, $read_array,  &$param1 = NULL, &$param2 = NULL, &$param3 = NULL,  &$param4 = NULL, &$param5 = NULL, &$param6 = NULL,  &$param7 = NULL, &$param8 = NULL, &$param9 = NULL) {
        // So now that the update function has been called, because either the  camelized notifier function doesn't exist or this software was installed  on a
      //  pre-ZC 1.5.3 system, how does one proceed?
        //  Remember that the second parameter (called $notifier here) contains  the notifier "name" such as 'NOTIFY_NICK_CHECK_FOR_EXISTING_EMAIL'.
      //  If wanted to execute specific code when that notifier has been executed/called then:
      if ($notifier == 'NOTIFY_NICK_CHECK_FOR_EXISTING_EMAIL') {
        // Perform the operation necessary for this notifier, which could include calling the above camelized observer function
        //  (updateNotifyNickCheckForExistingEmail) to contain/pass along the variables necessary.
          // Again though, if this were a pre-ZC 1.5.3 system, then $param1  through $param9 would be NULL because of the above default values.
          //  Generally speaking this should be fine because the function should  be able to know what to do if the values are NULL and handle the  value(s)
        //    correctly or as necessary.  Of course back on  the discussion of what data was necessary and where the notifier is  located, all of the
        //    associated data could be made global here and then basically passed to the above function(s). ie.:
        global $email_address;
        global $nick_error;
        global $nick;
        $this->updateNotifyNickCheckForExistingEmail($callingClass, $notifier, $email_address, $nick_error, $nick);
          // The above will collect the three variables by the same name as they  were in their original code, which does make them fully modifiable here;
          //  however, by expected process, the goal is/was not to modify  $email_address otherwise it would have been passed as a modifiable  variable.
        //  Those values will be sent to the applicable  camelized update function, any saveable modifications made would be  returned here, and then
        //    by the nature of the variables being global, those "saved" modifications would be made back to the base data.
          //  Some alternative operations/considerations could be made such as if  $email_address is not NULL the assign the variable $email_address to
          //    whatever value is received with $read_array (All versions of ZC  that support observers), $param1 would either be NULL (because pre-ZC
        //    1.5.3 would not set anything to that or it would be the value that was  sent to this observer (likely a false value) but in ZC 1.5.3+ only if  the
        //    camelized function name doesn't exist. )
      }
    }
}

---

Hi,
Many thanks for walking me through the observers/notifiers methodology. I had read what I could find previously, so I think I could follow the logic. What was new to me was that one can attach the same observer to multiple notifiers, clearly this is an important point.
I will try to work on this in the coming days.

For the past few days I had been testing functionality, and fixing email setting issues to get ZenCart to talk via SMTP to my local exim4 smarthost (my TLS certificate is not accepted apparently, so I eventually had to resort to just password authentication to the smarthost using the PHP mailer).

With the very useful and critical (to many people it seems) EZPages multi-language plugin, administration for multiple languages worked, but a bug prevented the store front pages from actually displaying (see support thread for bug fixes in query).

I also worked through the remaining various configuration changes for the Japanese localizaiton, and while testing user registration understood the meaning of some of them (such as 1 character limit on names and address components).

I attach the improved SQL file with the additional localization (apart from the address format additions and zones which are in different files). I used procedures to ensure (hopefully) that the correct changes are made regardless of the particular row positions in the tables or their index number.

Update to general additions: order status terms needed to be added also.

(note: I cannot figure out how to delete my older attachments in the attachment manager)

Debugging why kana support was not activated according to the logic.
If I set the below code in includes/extra_configures/set_kana_support.php (the file content is previously uploaded in this thread inside the zip archive JapanZones-AddressChanges-KanaSupportDefines.zip):

Code:

---

// decide on whether to use furigana - taken from Japanese 1.5.1-JP and checked:
//      if no match then strpos returns false; if result is a boolean then set "false", else set "true".
if (defined('FURIGANA_NECESSARY_LANGUAGES') &&
  !is_bool(strpos(strtolower(FURIGANA_NECESSARY_LANGUAGES), strtolower($_SESSION['language']))))
  define('FURIGANA_NECESSARY', true);
else
  define('FURIGANA_NECESSARY', false);

---

then FURIGANA_NECESSARY is empty in tpl_modules_create_account.php
However, adding the code directly to includes/application_top.php makes the definition work and be set to 1 in the create account template (checked with echo statement).
I cannot tell why it is being ignored if in a separate file in the includes/extra_configures directory, no error logs result, it seems the file is either ignored, or I am missing something (comparing to similar files there does not appear to be anything special about the file contents, for example email_use_8bit.php or media_manager.php).
I expected to be able to put the kana support in a separate file, but now I have added the lines directly to the end of application_top.php to at least have it working for now.

Mostly if I understood correctly because the file is loaded as an additional configure (loaded before the database is loaded) instead of as an additional datafile (loaded after the database is loaded.)

Of course the file needs to be a php file instead of a text file as previously described as well...

Hmm, I seem to have missed that explanation, sorry. I understood that the extra_configures is an extension of application_top.php, I guess I need to read more on the init system to get the breakdown of what happens inside that file and how extra information is related to it. Certainly, the other files in extra_configures have define statements, I guess it depends what that define is referencing.
Still, even if I move set_kana_support.php from extra_configures to extra_datafiles, I don't get any effect.
As you say, the extra file is a php file, in my initial upload I only notes the contents required, I did not specify any particular name for the file, expecting that more contents might need to be added finally. Nevertheless, in the interests of clarity, here is the current file, called set_kana_support.php in view of its current only funtionality:

Code:

---

<?php
/**
 * define for use with Japanese: furigana support based on language chosen
 *
 * @package languages
 * @copyright Copyright 2003-2005 Zen Cart Development Team
 * @license http://www.zen-cart.com/license/2_0.txt GNU Public License V2.0
 * @version $Id: media_manager.php 2842 2006-01-13 06:21:11Z drbyte $
 * @author Japanese localization team,gernot
 */
/**
  * Decide to use Furigana or not
**/
if ( defined('FURIGANA_NECESSARY_LANGUAGES') &&
    !is_bool(strpos(strtolower(FURIGANA_NECESSARY_LANGUAGES), strtolower($_SESSION['language']))) )
  define('FURIGANA_NECESSARY', true);
else
  define('FURIGANA_NECESSARY', false);

---

This has no effect as far as I can tell either in extra_configures or in extra_datafiles. But directly in application_top.php, it works.

It seems I was wrong about the meaning of the zones_code in the zones table, it is actually the short form for the display! And ordering is alphabetical in the pull-down list, another surprise.
Well, in order to support multi-lingual country and zone names, I finally found the plugin I need (I had thought this was part of 1.6 development code when I first found it on github):
https://www.zen-cart.com/downloads.php?do=file&id=2006
Time to work on this.

!is_bool(strpos(strtolower(FURIGANA_NECESSARY_LANGUAGES), strtolower($_SESSION['language']))) )
define('FURIGANA_NECESSARY', true);
else
define('FURIGANA_NECESSARY', false);
[/CODE]This has no effect as far as I can tell either in extra_configures or in extra_datafiles. But directly in application_top.php, it works.[/QUOTE]

So then, perhaps it needs to load later in the load sequence possibly in its own init_ file? I know you mentioned that the define changed a little to be more relative to what it does, to confirm when that change is applied it only seems to work in application_top.php? If that does seem to be the case then do believe back to using an includes/auto_loaders/config.xxxxx.php (where xxxxx is whatever you want) that loads your define somewhere later than when it is placed as an extra_datafiles option.

It looks like the extra_datafiles files are loaded well before the session data has been loaded which is one reason why it doesn't work. That loadpoint is 10 for extra_datafiles and 70 for session data. Then languages are loaded at 110. I'd recommend picking a load point between 70 and 110 (but not really either number just somewhere between) to load the define regarding the languages or... move the define into the file/area where it gets used or used first in a series of uses...

Hello,
Thank you for the extra details on the init sequence. It takes a bit of getting used to, hopefully I will be up to speed on this pretty soon.
I will experiment with an auto_loader between loadpoints 70 and 110. Despite your explanations, I am not sure right now what the pre-conditions are for the code to have an effect. That a session of some kind needs to be active first is one I understand, but as for languages loading or not, how is that related? I would have thought that the languages need to be loaded as well, since the code should only be used if the language chosen in the user's session is Japanese.
We'll see what happens once I get an auto_loader going and am free to set its loadpoint.

Then, I am unclear what this implies. You write:

Quote:

---

move the define into the file/area where it gets used or used first in a series of uses...

---

Even if I list all the files there the code should be effective, I don't understand whether there is any priority interaction between them to use in determining where one might best put the code.
Here is the list (shortened form of core file list previously posted, limited to only files edited for adding the kana support), leaving out the actual code currently put in application_top.php:

• admin/customers.php
• includes/modules/CUSTOM/checkout_new_address.php
• includes/modules/CUSTOM/create_account.php
• includes/pages/account_edit/header_php.php
• includes/pages/address_book_process/header_php.php
• includes/templates/CUSTOM/templates/tpl_account_edit_default.php
• includes/templates/CUSTOM/templates/tpl_modules_address_book_details.php
• includes/templates/CUSTOM/templates/tpl_modules_checkout_new_address.php
• includes/templates/CUSTOM/templates/tpl_modules_create_account.php

I missed this part of your post:

Quote:

---

Originally Posted by mc12345678

So then, perhaps it needs to load later in the load sequence possibly in its own init_ file? I know you mentioned that the define changed a little to be more relative to what it does, to confirm when that change is applied it only seems to work in application_top.php?

---

I did not change the logic, I only renamed the constants and the description, because it was not quite sensible. Originally there were spelling mistakes (FURIKANA_NESESSARY) which I changed to FURIGANA_NECESSARY, and the configuration key name was FURIKANA_NECESSARY_COUNTRIES which I changed to be FURIGANA_NECESSARY_LANGUAGES since that is really what is being compared. The actual reference "Japanese" for the comparison has not changed.