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

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
3. includes/modules/pages/account_edit/header_php.php
4. includes/modules/pages/address_book_process/header_php.php
5. 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:

$zco_notifier->notify('NOTIFY_HEADER_START_ACCOUNT_EDIT');

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

$zco_notifier->notify('NOTIFY_HEADER_ACCOUNT_EDIT_VERIFY_COMPLETE');

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

$zco_notifier->notify('NOTIFY_HEADER_ACCOUNT_EDIT_UPDATES_COMPLETE');

and

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

<?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):

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

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

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:

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.

Hi, brief summary of work done the last week.
I had installed the Multi Language Country Names (MLCN) module, and after studying it, decided to implement a similar extension for zone names. The zone names (and zone codes) mix with country names in some parts of the admin code - I haven't yet worked on the non-admin code, except to list which files dealt with or depended on zone information, and to note that there are potentially far more files to modify than for country names.
Since I worked from the MLCN module, I could create an installer, finding out just how fragile that method is also (if it breaks somewhere in the initial installer code), so having an SQL uninstaller ready is also important for redoing the configuration easily.
For the multi language zone names, I used a table zones_name that takes over the fields of the zones table, and adds language_id as does the MLCN module, and also zone_code_iso which is the international code for zones of countries (ISO 3166-2), similar to the 2-letter and 3-letter ISO codes for countries.
When editing zones one now sees the zones for all languages (I have not implemented a filter per language), but when editing a zone one has the ability to edit the zone name and zone code for each language, as well as input the ISO zone code. This code is now also displayed in the zones listing.
About the same amount of core files were changed for the admin side to implement this feature (countries.php was not required to be edited further).
When I have finished on the non-admin files later this week I hope I can put up my files for others to benefit from.

Uploading Zones listing in English and Japanese as it stands now, with multi language support, display fixed to display by language only (ISO code not currently in the summary window, but it is visible in the edit interface). Example of edit interface for either language for Hyogo prefecture also shown.
With this part done for now, I plan to add the display functionality to the customer side over the next few days bit by bit (since there are many areas where zones are used).

Aside:
With the multi language country name (and I have done the same for zones) I noticed that inserting countries/zones only adds the name to the extended table, with no entry in the original table. I think it might be better to put something into the original table, either in English, or in the default language of the installation.
And, for deletion, only the entry from the orginal table is removed, the extended table entries remain (but will no longer be accessed).

Some updates:
I've documented all files changed for multi language zones, as well as whether I could override them or not, and where the additions are combined with changes needed for the multi language country name module. I'll put up the list later this weekend.

After completing that, I've tuned the <admin>/includes/stylesheet.css to help manage the admin navigation menu. Japanese wording makes the buttons larger and breaks the line into two lines, reducing font from 11px to 10px fixes this without making the English version any harder to read. Ideally, each page might have a language tag, allowing for different CSS files per language... in future.
Also, I set up a hopefully web-safe font selection that supports Japanese, maybe not the best choice (I think I have only variable-width fonts there) but if it works as I expect it will enable users on linux, Windows and Mac OSes to see the site reasonably well utilizing their system fonts. Verdana is still the preferred font family for English.

1. Added fixed size for links:

a.headerLink:link {
    font-size: 10px; /* Japanese fonts require smaller size */

2. replaced font with font-family choice, keeping other options the same.

a, body, html, table {
    /* font: normal normal 11px Verdana, sans-serif; */
    /* experiment for Japanese */
    font-style: normal;
    font-variant: normal;
    font-weight: normal;
    font-size: 11px;
    font-family : Verdana, "ヒラギノ角ゴ ProN", "Hiragino Kaku Gothic ProN", "ヒラギノ角ゴ Pro W3", "Hiragino Kaku Gothic Pro", Osaka, "Noto Sans Japanese", "游ゴシック", "游ゴシック体", "YuGothic", "Yu Gothic", "メイリオ", Meiryo, "ＭＳ Ｐゴシック", "MS PGothic", "ＭＳ ゴシック", "MS Gothic", HiraKakuProN-W3, "TakaoExゴシック", TakaoExGothic, MotoyaLCedar, "Droid Sans Japanese", Arial, sans-serif;

I've been mulling a few issues and wondering if I have missed something and/or how to approach them:1. I haven't touched any files where only the zone_id is required. This includes, geo zones, there are quite a few places where table TABLE_ZONES_TO_GEO_ZONES is used, but I think I don't need to touch this. I hope this is OK.
2. For Paypal modules, setting the state seems to be required for Japan, according to comments in the module file (paypalwpp.php, paypaldp.php), but as far as I can tell, nothing is set. I've posted a question in the support forum (Ref: https://www.zen-cart.com/showthread.php?223076-Requirement-for-state-setting-in-Paypal-modules-for-certain-countries) about this. If necessary, I'll probably create a lookup table specifically for Paypal.
3. Meaning of Japan country_id of 107. This is not an ISO country code as far as I can tell, is this only internal to Zen Cart? Paypal for example specifies some numerical codes for each country which seem to be ISO numerical codes (separate from the ISO 2-letter or 3-letter codes). Is there a need for the ISO numerical codes, and if so, is there a relationship to the Zen Cart country codes?
4. Adding different address formats for a single country: this is clearly an issue with many countries and cultures that do not use Latin alphabets, and where the order and punctuation of an address is different for local and English writing. I will probably need to create a separate table for Japanese addresses, and expose the choice of language and/or address format code in the GUI (not to mention giving examples of the format, since this might be required for comparison to Paypal and other payment/shipping modules).Best regards,
Gernot Hassenpflug

One further issue, while trying to set up categories and manufacturers. Categories are already multi-language with a language pack addition, but manufacturers do not seem to be. I am not sure whether this is a bug in the Japanese language pack I ported, but obviously I need to solve this by doing some more customizing (or finding a bug in my porting). The URL for manufacturer is customizable per language, but not the name.
Unlike for categories, there is no description either - I did see there are a few manufacturer-related add-on modules that might help (Manufacturers All About, for example).

Regarding address_format, after mulling over several options, and weighing up how much effort each would be to implement, versus the customer-side effort in understanding the logic, I came up with the following ideas:

1. Simplest idea

Extend or create a new table for address_format, including langauge_id.
In this case, the function zen_get_address_format_id could be extended to include language_id as a parameter (or just use $_SESSION['languages_id'] in the function itself) to return the address format suitable for the current language.
This would make it relatively easy for customers (and admins) to enter/edit addresses directly in their own and other languages, and choose the one to use later.
The downside is that the display of all addresses still follows only the address format in force.

2. More complex idea

Keep address_format table as is, but add formats to it to support whatever format is required for different languages (in particular, Japanese addresses written out in Japanese versus written out in English).
Extend address_book format to include address_format (and maybe language_id) to override the country default address_format.
Then, extend customer.php and various address_book and address display files (by my count 8 admin, 13 customer-side) as applicable to expose the choice of address_format (and maybe language), and display addresses dependent both on their format and language. The reason for exposing language is that for now the country and zone are (often/always?) auto-selected rather than being read from the address_book, so their display would need to be controlled to match the rest o the address.

Any thoughts welcome.

Extending manufacturers to be multi langauge involves at likely some or all of 7 admin and 12 customer facing files, and the creation of an extended set of tables, quite a large overhead for adding multi-language capability to just one field (name), especially since the URL is already multi-langage capable. Oh well, manufacturers would need a new table, but manufacturers_info would stay as it is.

Worked on extending the address_book to handle different formats for a single country. The countries table now contains the default address format, but each address can be specified to have its own one. Obviously various code parts will need to reference this instead of the countries field.

1. Added English address format and correct Japanese one in address_format table:
   1.1 updated Japanese format for Japan (last name first):
   update address_format set address_format='$lastname $firstname$cr$postcode$cr$state$city$cr$streets$cr$country$cr$telephone$cr$fax' where address_format_id=8;
   1.2 inserted English format for Japan:
   insert into address_format (address_format,address_summary) values ('$firstname $lastname$cr$streets$cr$city, $state$cr$postcode $country$cr$telephone$cr$fax','$city, $state');

2. Extended countries_name table:
   2.1 created new field:
   ALTER TABLE countries_name ADD address_format_id int(11) NOT NULL default 0;
   2.2 populated new field:
   UPDATE countries_name INNER JOIN countries ON countries_name.countries_id = countries.countries_id SET countries_name.address_format_id = countries.address_format_id
   2.3 updated English Japan to be format 9 (new English format inserted above):
   update countries_name set address_format_id = 9 where countries_name = 'Japan';
   2.3 updated countries table to also use default English format:
   update countries set address_format_id = 9 where countries_name = 'Japan';

3. Extended address_book table:
   3.1 added address_format_id and language_id fields:
   ALTER TABLE address_book ADD address_format_id int(11) NOT NULL default 1;
   ALTER TABLE address_book ADD language_id int(11) NOT NULL default 1;
   3.2 set address_format_id and language_id appropriately per existing addresses:
   For addresses in Japan, written in Japanese: address_format_id=8, language_id=3 (Japanese)
   For addresses in Japan, written in English: address_format=9, language_id=1 (English)

4. WIP: Update admin code that looks in address book to also get the address_format_id and language_id from there.
   So far handled customers.php and functions_customers.php to obtain following results:
   4.1 listed addresses for a customer using the format in the address_book for each address. This makes addresses entered in English and in Japanese appear in their respective formats.
   4.2 update address for a customer with addition of a language field, the setting of which chooses the address format to use for the address, based on the country chosen (by default, the same address format is in use for all languages, unless set differently in the multilanguage contries_name table).
   4.3. WIP: still figuring out how to handle the various forms of error (error, specific field error, no error), and whether to display drop-down, or text fields in which case (confusing for country and zone/state as well).
   4.4. TODO: still have to handle other parts of the admin code, like invoice, orders, packingslip.

5. TODO: Update the customer-facing GUI to expose address format and language for entering and updating addresses
   Not done this part yet, but since admin part logic is working, this should be fairly straightforward, though perhaps tedious.

Needed to work more on Javascript code to update country and state pull-down lists automatically based on (new) language_id format selection, and also set the default country and state pull-down to work with the (new) language_id format saved in address_book for each address.
Examples via screenshots, showing the different address formats per user for a single country including name/surname order, and address sub-section order changes (two different address_formats, each saved with the address), and how the language choice is incorporated into the customer address editing screen in the admin GUI.
I've made it that the state pull-down has the zone_id as the value, since it makes more sense to me, as country pull-down also has it this way.
Not sure why entry_state is only saved in the original code (as a state name) if zone_id is 0, but I am keeping it that way, so in practice not much has changed (only some DB lookups need to use zone_id, or in fact become superfluous since original code had to get the zone_id from zone_name).

Took a lot of time to learn the interaction of PHP and Javascript, defaults and onChange operations, still need to go through the related files on the admin side.

Already ported the new functions from admin side to customer side for general usage (html_output.php and functions_general.php), but not yet in use, nor checked the various usages in customer-facing files (multiple jscript_addr_pulldowns.php, on_load_main.js) and templates.

Progress on the customer facing-side, displaying addresses in the format appropriate both to country and language, as specified in the address_format_id and language_id fields added to address_book table.

I first attempted to tackle the shipping estimator, made up of the module file and template file.
I could successfully handle the display of the short form of the address in the pull-down menu in the shipping estimator pop-up, since that is set up by a MySQL search inside the module file.
However, despite adding some echo statements to if/else parts of the shipping estimator module file, I have not been able to grok how the full address display in the pop-up is generated or taken from. This address is referenced as order->delivery in the call to zen_get_address in the template file, and is updated when the pull-down menu selection is changed (using an onChange call which resubmits the entire form). I cannot figure out where order->delivery is set up or how it is updated on submit in the module file. As far as I can tell, for my case as a signed-in customer, no other Javascript is involved (other processing flows exist for users who are not signed in), so I surmise the original date and any updates must be processed in PHP somewhere (I have looked at order.php also briefly but I think the update processing is limited to the shipping estimator module file alone).
Any help in understanding would be most appreciated.

Problem solved! It appears that the class order.php is indeed the origin of the order->delivery information, via shipping_address, which is updated on each submit via the variable sendto (which is the selected address_id from the pull-down menu).
Modifying the MySQL query for shipping_address to use the new address_format_id from address_book (instead of from the countries table) and language_id, enabled me to obtain the correct format and language for country and zone in the full address in the shipping estimator pop-up.

Note: I added the Japanese postcode sign "〒" in front of postcode in the address format, but needed a space separation on either side, else whatever it was touching would be ignored. This worked fine. However, I was unable to do the same with "様" ( read as "sama") after the name, since this would then be parsed as part of the succeeding address component. I am not sure if one can add such a component in the address_format directly, but if so, it would be great to know.
The only alternative I see at present is to output it on demand each time in the code, depending on language_id I suppose.