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

Currently I have an English/Japanese store (version 1.5.4) that works fine with Japanese Language Pack.

Yesterday I began playing around with version 1.5.5 on a new store for an English/Japanese based site. I have not installed any Japanese files yet.

I have not seen any activity surrounding the Japanese Language Pack for a few years so I'm wondering if the current language pack will work in 1.5.5 and upcoming version 1.6 (and beyond!).

Would appreciate an overview of the situation as I need to know if I should stick with Zen or not.

Thanks in advance!

Quote:

---

Would appreciate an overview of the situation as I need to know if I should stick with Zen or not.

---

As you must also speak & write in Japanese - you can edit the english.php replacing English words with Japanese then renaming it to japanese.php and along with other language files.
You could then offer it as a language pack for ZenCart v1.5.5

Actually my Japanese ability is limited but I'll look into it... If the 1.5.5 version is not too different I should be able to handle it.

I think there is also a Japanese fork on github of the Zen Cart repository. Not sure is it is actively maintained or up to date.

here is the link https://github.com/zencart-ja

I only have Japanese version 1.5.1, where did you find 1.5.4?

The annoying part I find about ZenCart JP version is the admin configuration menus are fixed in Japanese, they should be multilingual but are not.

I believe my version is 1.5.1, too. Anyway, whatever version it is, it seems to work fine with 1.5.4.

I can choose English or Japanese for the Admin area. I usually download the English version and add the Japanese language files to it...

I've decided to try and update the Japanese Language files to suit version 1.5.5.

I've done a search but can't seem to find specific instructions as to the procedure or a list of files that need to be updated for both the store and the admin.

Could someone point me in the right direction?

Thanks!

Quote:

---

Originally Posted by Peace Freak

I've decided to try and update the Japanese Language files to suit version 1.5.5.

I've done a search but can't seem to find specific instructions as to the procedure or a list of files that need to be updated for both the store and the admin.

Could someone point me in the right direction?

Thanks!

---

Not sure I'm answering the right question, but all of the language files are in the appiicable languages directories. The action would be as I see it, assuming that the japanese version of the code is or will be the same as the english version of the code, would be to compare the includes/languages folders for all english files against the japanese language pack. Any defines in english not in japanese need to be translated, copied, or moved. Any define in the japanese version not in the english version to also be evaluated for removal/movement.

There is also a plugin I thought that also looks for "multiple" definitions of a constant or something similar to help eliminate "unnecessary" duplication of definitions/identify the "best" location for a single define to be applicable for all cases.

If the japanese version of ZC is or is to be different than the english version then the applicable constants would need to be evaluated for such.

Further, as I just thought about the actual process, because every define that exists will be different most likely in each case, a process may need to be considered, to ease the comparison... Right? Remember each define line has a constant, followed by the information for that language. And each language is "different". There might be cases where the english and japanese are the same because of cultural acceptance, but one should assume first that they are not.

So, two ways I see to do this and it depends on the capability of the comparison software. Either the comparison is done with something like a regex expression that ignores the second half of the below:

Code:

---

define(.*,.*);

---

this regex is not written to accomodate that aspect, and would require investigation.
Or 2, a backup copy of each file is made, the file is modified to remove the second part of the expression and the comparison made to identify the missing field(s) as identified in the previous post. This would/could be more like this with a search filter of:

Code:

---

define((.*), .*);

---

Replace with:

Code:

---

define($1

---

Then in case there are comments that follow a define, as part of the comparison, ignore the non-functional/minor differences between files...

Then when a difference is found, the original file is reviewed to evaluate why the difference and what the "statement's" intent is to support translation.

A bit tedious, but a first attempt at a process.

Thank you for both posts mc12345678. This is going to be quite a job... I've an earlier Japanese version of the includes/languages/japanese that I'm manually comparing to the 1.5.5 English version... I'm beginning to understand the process.

I'd also like to have a Japanese Admin but in version 1.5.5 I don't see any admin folder to add language files to. What do I need to do?

Thanks!

Quote:

---

Originally Posted by Peace Freak

Thank you for both posts mc12345678. This is going to be quite a job... I've an earlier Japanese version of the includes/languages/japanese that I'm manually comparing to the 1.5.5 English version... I'm beginning to understand the process.

I'd also like to have a Japanese Admin but in version 1.5.5 I don't see any admin folder to add language files to. What do I need to do?

Thanks!

---

In which version ZC 1.5.5 are you not seeing the languages folder for admin? The english version has one as can be seen here in the folder listing. I had thumbed through the japanese version at one point but didn't look for such differences.

Fyi, I just an internet search on 'beyond compare regex' and one of the results included how to use regex to define "unimportant" text as minor... Such a "setup" could simplify the compare if you are using that program as a comparison tool. Other tools may offer the same capability.

Thanks mc12345678. I re-downloaded the most recent beta and it was included. It might have been in the earlier version I downloaded but perhaps I forgot to upload it to the server...

I'm working on updating japanese.php (in includes/languages) and have been comparing the new English 1.5.5 version with an older Japanese version that I'm updating.

The older version had a few lines of code that I believe I can delete, but I'd like to check before I do so. There are five lines of code in red with the words "no longer needed?" beside them.

Can I remove them without causing problems? The English version (1.5.5) does not have that code so I guess it's not needed.

Thanks!

Japanese Version 1.3.8 adjusted to 1.5.5:

<?php
/**
* @package languageDefines
* @copyright Copyright 2003-2014 Zen Cart Development Team
* @copyright Portions Copyright 2003 osCommerce
* @license http://www.zen-cart.com/license/2_0.txt GNU Public License V2.0
* @version GIT: $Id: Author: ajeh Modified in v1.5.4 $
*/

// FOLLOWING WERE moved to meta_tags.php
//define('TITLE', 'Zen Cart!');
//define('SITE_TAGLINE', 'The Art of E-commerce');
//define('CUSTOM_KEYWORDS', 'ecommerce, open source, shop, online shopping');
// END: moved to meta_tags.php

define('FOOTER_TEXT_BODY', 'Copyright &copy; ' . date('Y') . ' <a href="' . zen_href_link(FILENAME_DEFAULT) . '" target="_blank">' . STORE_NAME . '</a>. Powered by <a href="http://www.zen-cart.com" target="_blank">Zen Cart</a>');

// look in your $PATH_LOCALE/locale directory for available locales..
$locales = array('ja_JP', 'ja_JP.UTF-8', 'jp', 'Japanese_Japan.1041');
@setlocale(LC_TIME, $locales);
define('DATE_FORMAT_SHORT', '%Y/%m/%d'); // this is used for strftime()
define('DATE_FORMAT_LONG', '%Y年%m月%d日(%a)'); // this is used for strftime()
define('DATE_FORMAT', 'Y/m/d'); // this is used for date()
define('DATE_TIME_FORMAT', DATE_FORMAT_SHORT . ' %H:%M:%S');

// if mbstring is not load, use mb-emulator (no longer needed?)

// EMAIL config
define('EMAIL_CHARSET', 'utf-8'); (no longer needed?)
define('EMAIL_ENCODING', '7bit'); (no longer needed?)
define('EMAIL_MIMEHEADER', 'B'); (no longer needed?)
define('EMAIL_IS_MULTIBYTE', TRUE); (no longer needed?)

////
// Return date in raw format mm/dd/yyyy
// $date should be in format yyyy/mm/dd -- Change for Japanese date format
// raw date is in format YYYYMMDD, or DDMMYYYY
if (!function_exists('zen_date_raw')) {
function zen_date_raw($date, $reverse = false) {
if ($reverse) {
return substr($date, 8, 2) . substr($date, 5, 2) . substr($date, 0, 4);
} else {
return substr($date, 0, 4) . substr($date, 5, 2) . substr($date, 8, 2);
}
}
}

// if USE_DEFAULT_LANGUAGE_CURRENCY is true, use the following currency, instead of the applications default currency (used when changing language)
define('LANGUAGE_CURRENCY', 'JPY');

// Global entries for the <html> tag
define('HTML_PARAMS','dir="ltr" lang="ja"');

// charset for web pages and emails
define('CHARSET', 'utf-8');

// footer text in includes/footer.php
define('FOOTER_TEXT_REQUESTS_SINCE', 'requests since');

1.5.5 E Version:

<?php
/**
* @package languageDefines
* @copyright Copyright 2003-2014 Zen Cart Development Team
* @copyright Portions Copyright 2003 osCommerce
* @license http://www.zen-cart.com/license/2_0.txt GNU Public License V2.0
* @version GIT: $Id: Author: ajeh Modified in v1.5.4 $
*/

// FOLLOWING WERE moved to meta_tags.php
//define('TITLE', 'Zen Cart!');
//define('SITE_TAGLINE', 'The Art of E-commerce');
//define('CUSTOM_KEYWORDS', 'ecommerce, open source, shop, online shopping');
// END: moved to meta_tags.php

define('FOOTER_TEXT_BODY', 'Copyright &copy; ' . date('Y') . ' <a href="' . zen_href_link(FILENAME_DEFAULT) . '" target="_blank">' . STORE_NAME . '</a>. Powered by <a href="http://www.zen-cart.com" target="_blank">Zen Cart</a>');

// look in your $PATH_LOCALE/locale directory for available locales..
$locales = array('en_US', 'en_US.utf8', 'en', 'English_United States.1252');
@setlocale(LC_TIME, $locales);
define('DATE_FORMAT_SHORT', '%m/%d/%Y'); // this is used for strftime()
define('DATE_FORMAT_LONG', '%A %d %B, %Y'); // this is used for strftime()
define('DATE_FORMAT', 'm/d/Y'); // this is used for date()
define('DATE_TIME_FORMAT', DATE_FORMAT_SHORT . ' %H:%M:%S');

////
// Return date in raw format
// $date should be in format mm/dd/yyyy
// raw date is in format YYYYMMDD, or DDMMYYYY
if (!function_exists('zen_date_raw')) {
function zen_date_raw($date, $reverse = false) {
if ($reverse) {
return substr($date, 3, 2) . substr($date, 0, 2) . substr($date, 6, 4);
} else {
return substr($date, 6, 4) . substr($date, 0, 2) . substr($date, 3, 2);
}
}
}

// if USE_DEFAULT_LANGUAGE_CURRENCY is true, use the following currency, instead of the applications default currency (used when changing language)
define('LANGUAGE_CURRENCY', 'USD');

// Global entries for the <html> tag
define('HTML_PARAMS','dir="ltr" lang="en"');

// charset for web pages and emails
define('CHARSET', 'utf-8');

// footer text in includes/footer.php
define('FOOTER_TEXT_REQUESTS_SINCE', 'requests since');

Best "test" is to comment out those lines (adding // at the beginning of each line) that way, at least if it doesn't work, then the solution is to uncomment rather than re-develop.

An alternative action could be to start a github repo, that way you can pose and track questions like that and others can add/chime in.

This is also case where you may want to have the Japanese version "running" to use the dtk to discover if that code is needed, to try it out, etc...

https://github.com/zencart-ja/zc-v1-...s/japanese.php
Japanese language file is here.(for v1.5.5)

Quote:

---

Originally Posted by yama

https://github.com/zencart-ja/zc-v1-...s/japanese.php
Japanese language file is here.(for v1.5.5)

---

Yeah, that generally makes sense, if the software is the same other than the "language pack" then the base languages file and all subdirectory language files would be a good "comparison" to ensure that the text displayed in the english ZC shows the proper japanese when selected. The above referenced file is just the base language file and generally would not be expected to contain all of the defines for modules, pages, etc... Those would be (expected to be) in the applicable subdirectory(ies).

Thank you Yama for the file. It was useful and I made corrections to my version. Are you working on updating the Japanese version to 1.5.5, too?

mc12345678, regarding the dtk (Developers Tool Kit), I wonder if you could give me an example on how to use it for checking things.

My process has been to manually compare the Japanese version I have to the latest version. when I find differences, I adjust the old version to match the new.

Today I "completed" the language files in admin and includes and uploaded them to the server. The store "appears" to be fine (I've not done any serious testing yet), but in admin I see a yellow "MISSING LANGUAGE FILES OR DIRECTORIES ... Japanese Japanese" warning and the "Define Language" selector only has English listed, I can't switch the admin to Japanese.

Would appreciate if someone would point me in the right direction...

Thanks!

https://github.com/zencart-ja/zc-v1-...s/japanese.php
Sorry, Updated now.

I seem to be doing something similar, trying to match older Japanese version with English 1.5.4. I am upgrading our store from 1.5.1. Japanese names have many different readings, to get the correct reading the name should have "Kana" fields. The old Japanese ZenCart could do that but I haven't been able to do that with newer versions I modified. Name order is the opposite of English, Family Name First Name. The address order too is different starting with the postal code, prefecture, street address. When the user is in English mode the name and address order should revert and the Kana fields not appear. Have you been able to make any of this work?

Quote:

---

Originally Posted by cjcraven

I seem to be doing something similar, trying to match older Japanese version with English 1.5.4. I am upgrading our store from 1.5.1. Japanese names have many different readings, to get the correct reading the name should have "Kana" fields. The old Japanese ZenCart could do that but I haven't been able to do that with newer versions I modified. Name order is the opposite of English, Family Name First Name. The address order too is different starting with the postal code, prefecture, street address. When the user is in English mode the name and address order should revert and the Kana fields not appear. Have you been able to make any of this work?

---

When you say that regardiing swtching from japanese to english that the katana fields should "revert" are you. Implying that a customer's name entered with katana should show as english or something? Or which change is expected?

I ask because the customers table which includes the first and last name of the customer only supports entry of one name per customer, not two+ or a translation.

The Japanese localize script adds 2 fields to the database;

ALTER TABLE address_book ADD entry_firstname_kana varchar(32) NOT NULL default '';
ALTER TABLE address_book ADD entry_lastname_kana varchar(32) NOT NULL default '';
ALTER TABLE customers ADD customers_firstname_kana varchar(32) NOT NULL default '';
ALTER TABLE customers ADD customers_lastname_kana varchar(32) NOT NULL default '';
ALTER TABLE orders ADD customers_name_kana varchar(64) NOT NULL default '';
ALTER TABLE orders ADD delivery_name_kana varchar(64) NOT NULL default '';
ALTER TABLE orders ADD billing_name_kana varchar(64) NOT NULL default '';
INSERT INTO configuration (configuration_title, configuration_key, configuration_value, configuration_description, configuration_group_id, sort_order, set_function, date_added) VALUES ('ふりがなが必要な国', 'FURIKANA_NECESSARY_COUNTRIES', 'Japanese', 'ふりがなが必要な国名をカンマで区切って入力してください', '5', '100', '', now());

There are various changes to the core files too but I can't find them all at the moment.

I tried before to get Kana to work but without luck. Please see my old post:

http://www.zen-cart.com/showthread.p...21#post1244221

Besides the database changes, the customers.php file needs to be changed in a number of places to account for kana fields. Also at least the below files need changing too.

admin\includes\application_top.php
admin\customers.php
includes\modules\pages\account_edit\header_php.php
includes\modules\pages\account_edit\jscript_form_check.php
includes\modules\pages\address_book_process\header_php.php
includes\modules\pages\login\jscript_form_check.php
includes\modules\checkout_new_address.php
includes\modules\create_account.php
includes\templates\template_default\templates\tpl_account_edit_default.php
includes\templates\template_default\templates\tpl_modules_address_book_details.p hp
includes\templates\template_default\templates\tpl_modules_checkout_new_address.p hp
includes\templates\template_default\templates\tpl_modules_create_account.php
includes\application_top.php

In order to get the address format correct the database table "Address_Format" needs to be modified.

Add one row
address_format_id "7"
address_format "$lastname $firstname 様$cr$postcode$cr$state$city$cr$streets$cr$country$cr$telephone$cr$fax"
address_summary "$statename $city"

This is from the 1.5.1 admin/customers.php file, notice about 5 modifications for Kana. Download the Japanese version to better see these changes.

$customers_firstname = zen_db_prepare_input(zen_sanitize_string($_POST['customers_firstname']));
$customers_lastname = zen_db_prepare_input(zen_sanitize_string($_POST['customers_lastname']));
// ->furikana
$customers_firstname_kana = zen_db_prepare_input($_POST['customers_firstname_kana']);
$customers_lastname_kana = zen_db_prepare_input($_POST['customers_lastname_kana']);
// <-furikana


// ->furikana
if (FURIKANA_NESESSARY)
$sql_data_array = array('customers_firstname' => $customers_firstname,
'customers_lastname' => $customers_lastname,
'customers_firstname_kana' => $customers_firstname_kana,
'customers_lastname_kana' => $customers_lastname_kana,
'customers_telephone' => $customers_telephone,
'customers_fax' => $customers_fax,
'customers_email_address' => $customers_email_address,
'customers_group_pricing' => $customers_group_pricing,
'customers_newsletter' => $customers_newsletter,
'customers_email_format' => $customers_email_format,
'customers_authorization' => $customers_authorization,
'customers_referral' => $customers_referral
);
else

$sql_data_array = array('customers_firstname' => $customers_firstname,
'customers_lastname' => $customers_lastname,
'customers_email_address' => $customers_email_address,
'customers_telephone' => $customers_telephone,
'customers_fax' => $customers_fax,
'customers_group_pricing' => $customers_group_pricing,
'customers_newsletter' => $customers_newsletter,
'customers_email_format' => $customers_email_format,
'customers_authorization' => $customers_authorization,
'customers_referral' => $customers_referral
);
// <-furikana

if (ACCOUNT_GENDER == 'true') $sql_data_array['customers_gender'] = $customers_gender;
if (ACCOUNT_DOB == 'true') $sql_data_array['customers_dob'] = ($customers_dob == '0001-01-01 00:00:00' ? '0001-01-01 00:00:00' : zen_date_raw($customers_dob));

zen_db_perform(TABLE_CUSTOMERS, $sql_data_array, 'update', "customers_id = '" . (int)$customers_id . "'");

$db->Execute("update " . TABLE_CUSTOMERS_INFO . "
set customers_info_date_account_last_modified = now()
where customers_info_id = '" . (int)$customers_id . "'");

if ($entry_zone_id > 0) $entry_state = '';

// ->furikana
if (FURIKANA_NESESSARY)
$sql_data_array = array('entry_firstname' => $customers_firstname,
'entry_lastname' => $customers_lastname,
'entry_firstname_kana' => $customers_firstname_kana,
'entry_lastname_kana' => $customers_lastname_kana,
'entry_street_address' => $entry_street_address,
'entry_postcode' => $entry_postcode,
'entry_city' => $entry_city,
'entry_country_id' => $entry_country_id);
else
$sql_data_array = array('entry_firstname' => $customers_firstname,
'entry_lastname' => $customers_lastname,
'entry_street_address' => $entry_street_address,
'entry_postcode' => $entry_postcode,
'entry_city' => $entry_city,
'entry_country_id' => $entry_country_id);
// <-furikana

// ->furikana
if (FURIKANA_NESESSARY)
$customers = $db->Execute("select c.customers_id, c.customers_gender, c.customers_firstname,
c.customers_lastname, c.customers_dob, c.customers_email_address,
c.customers_firstname_kana, c.customers_lastname_kana,
a.entry_company, a.entry_street_address, a.entry_suburb,
a.entry_postcode, a.entry_city, a.entry_state, a.entry_zone_id,
a.entry_country_id, c.customers_telephone, c.customers_fax,
c.customers_newsletter, c.customers_default_address_id,
c.customers_email_format, c.customers_group_pricing,
c.customers_authorization, c.customers_referral
from " . TABLE_CUSTOMERS . " c left join " . TABLE_ADDRESS_BOOK . " a
on c.customers_default_address_id = a.address_book_id
where a.customers_id = c.customers_id
and c.customers_id = '" . (int)$customers_id . "'");
else
$customers = $db->Execute("select c.customers_id, c.customers_gender, c.customers_firstname,
c.customers_lastname, c.customers_dob, c.customers_email_address,
a.entry_company, a.entry_street_address, a.entry_suburb,
a.entry_postcode, a.entry_city, a.entry_state, a.entry_zone_id,
a.entry_country_id, c.customers_telephone, c.customers_fax,
c.customers_newsletter, c.customers_default_address_id,
c.customers_email_format, c.customers_group_pricing,
c.customers_authorization, c.customers_referral
from " . TABLE_CUSTOMERS . " c left join " . TABLE_ADDRESS_BOOK . " a
on c.customers_default_address_id = a.address_book_id
where a.customers_id = c.customers_id
and c.customers_id = '" . (int)$customers_id . "'");
// <-furikana

<?php
// ->furikana
if (FURIKANA_NESESSARY) {
?>
var customers_firstname_kana = document.customers.customers_firstname_kana.value;
var customers_lastname_kana = document.customers.customers_lastname_kana.value;
<?php
}
// <-furikana
?>

<?php
// ->furikana
if (FURIKANA_NESESSARY) {
?>
if (customers_firstname_kana == "" || customers_firstname_kana.length < <?php echo ENTRY_FIRST_NAME_MIN_LENGTH; ?>) {
error_message = error_message + "<?php echo JS_FIRST_NAME_KANA; ?>";
error = 1;
}

if (customers_lastname_kana == "" || customers_lastname_kana.length < <?php echo ENTRY_LAST_NAME_MIN_LENGTH; ?>) {
error_message = error_message + "<?php echo JS_LAST_NAME_KANA; ?>";
error = 1;
}
<?php
}
// ->furikana
?>

<?php
// ->furikana
if (FURIKANA_NESESSARY) {
?>
<tr>
<td class="main"><?php echo ENTRY_FIRST_NAME_KANA; ?></td>
<td class="main">
<?php
if ($error == true) {
if ($entry_firstname_kana_error == true) {
echo zen_draw_input_field('customers_firstname_kana', $cInfo->customers_firstname_kana, zen_set_field_length(TABLE_CUSTOMERS, 'customers_firstname_kana', 50)) . '&nbsp;' . ENTRY_FIRST_NAME_KANA_ERROR;
} else {
echo $cInfo->customers_firstname_kana . zen_draw_hidden_field('customers_firstname_kana');
}
} else {
echo zen_draw_input_field('customers_firstname_kana', $cInfo->customers_firstname_kana, zen_set_field_length(TABLE_CUSTOMERS, 'customers_firstname_kana', 50), true);
}
?></td>
</tr>
<tr>
<td class="main"><?php echo ENTRY_LAST_NAME_KANA; ?></td>
<td class="main">
<?php
if ($error == true) {
if ($entry_lastname_kana_error == true) {
echo zen_draw_input_field('customers_lastname_kana', $cInfo->customers_lastname_kana, zen_set_field_length(TABLE_CUSTOMERS, 'customers_lastname_kana', 50)) . '&nbsp;' . ENTRY_LAST_NAME_KANA_ERROR;
} else {
echo $cInfo->customers_lastname_kana . zen_draw_hidden_field('customers_lastname_kana');
}
} else {
echo zen_draw_input_field('customers_lastname_kana', $cInfo->customers_lastname_kana, zen_set_field_length(TABLE_CUSTOMERS, 'customers_lastname_kana', 50), true);
}
?></td>
</tr>
<?php
}
?>

<?php

In order to properly sell in the Japanese market these issues need to be resolved, unfortunately I'm not a programmer and it is beyond my skill.

Recently upgraded its website 1.5.5 works far better. Site of Bulgarian and for Auto Accessories http://hopshop.bg/ ... I put my package language 1.3,8 because there is no new language Bulgarian .. Admin me in English .. Where did I find that missing something in the language add or change further for now .. everything is ok .. Thank creators and people who develop ZenCart ...

I'm also looking at adding Japanese language support to my (experimental) online shop here in Tokyo, which runs 1.5.5d perfectly well in English.
I've looked at the Japanese ZenCart 1.5.1 language files, extra modules for shipping and payment, and the localization script.
Since the Japanese Zencart is---I think---a pure localization, for support of multiple languages I surmise that parts of the localization script (and parts of other files that simply replace English terminology with Japanese) should be removed and put into language files and templates.
Is that the correct approach to take?

Welcome to Zen Cart. This FAQ somewhat describes the LANGUAGE system, though does not heavily go into the "override" portion of the system: https://www.zen-cart.com/content.php...-are-they-used
The override system is a little more explained here: https://www.zen-cart.com/content.php...verride-system
And there is a file that can be downloaded from the plugins area to be used/viewed on your local computer to better understand the override system: https://www.zen-cart.com/downloads.php?do=file&id=1393

Basically, it is recommended that words not be incorporated into the code, instead that defined variables be used and other tools to support language related display such as in addresses that the house number appear on the "correct" side of the street name, or that a quantity appears in the correct location of the "sentence".

Thank you mc12345678, I will check out the cheatsheet, though I notice it only is applicable correctly up to 1.5.5b. Since I began at 1.5.5c before upgrading to 1.5.5d, I will need to some to check what differences there might be.
I spent about 8 months looking into Zencart before deciding on the international 1.5.5c (at that time the latest) rather than the old Japanese 1.5.1(something), and run only in English at the moment.
I contacted the Facebook page of the Zencart Japan team last year, no reply at all despite my offer to work with them to update the Japanese version to 1.5.5c (and now 1.5.5d). The website also appears dead, and the forums do not function (at least search does not) when looking for modules.
Since the main changes appear to be not that difficult, in terms of name and address changes, my main problems are conceptual: does making localization changes to name and address formats mean that all users in all languages will be forced to use a format, or can one easily separate sets of fields to use per language (not that that is a major problem if one can only use a single type of format for names and addresses).
The only modules added to the Japanese 1.5.1 Zencart version appear to be addition of credit card and convenience store payments using Remise (a payment brand in Japan), and the addition of two express mail delivery services (Sagawa and Kuroneko Yamato) in the shipping modules. I am not sure if cod_table (pay on delivery) is a Japanese addition or not, and need to check the modules in 1.5.5d actually to compare.
So as far as I am concerned, since I am quite fluent in Japanese, with some cooperation with like-minded people here on this forum we could prepare a Japanese language and module update for 1.5.5d, assuming programming changes in the modules for updating from 1.5.1 to 1.5.5d is not too difficult (or necessary even).
I'll get spend some time on the cheatsheet this weekend and see if I understand whether all or some of the Japanese localization can be handled by the language (no extension of functionality, just translations) and override system (additions/modifications of functionality - but it seems language files also fall under override). One thing I am really eager to understand is whether localization falls within the ambit of the override system.
Many thanks in advance,
Gernot Hassenpflug

After revisiting several related threads on Japanese language packs (a misnomer I find) dating back to 2006 (version 1.3.8 or so), and the contributions therein, I conclude that there are three major areas included in what could be referred to a Japanese language pack-age.
I don't know if I got the breakdown correct, but here goes.

1. Japanese language definitions for site users/visitors/customers.
   This would be standard language-package territory.
2. Japanese language and other related definitions for site administrators.
   I guess this is standard language pack territory also, but perhaps not.
3. Core and module changes required to operate in Japan.
   This includes email templates (which if I understand correctly do not fall under teh template hierarchy), name definitions, addition of Japan-centric modules, and changes to some modules (such as seemed to be the case with Paypal back in 2006) to work in Japan. If I understand correctly, this impacts the entire Zencart system, regardless of language chosen by users and/or admins.

I'll spend some time checking if the 1.5.1 Japanese distribution modules have changes in them compared to the 1.5.1 and 1.5.5d standard versions. More time needed...

After looking at the Japanese 1.5.1 paypal files and the current 1.5.5e files, I don't see anything customized in the Japanese ones that hasn't been already put into the 1.5.5e files. There has certainly been a heck of a lot of work in the time since 1.5.1 by Dr. Byte!
In particular, I noticed that the differences do not show up any language-specific text, which is great.
On the other hand, the 3 shipping modules (nittsu.php, sagawaex.php, yamato.php) (and their related language and class files) do have specific Japanese-language strings in them. Presumably, for Anglicization, the best would be to make new defines for these texts, and override them with language-specific overrides; or perhaps one could just override the entire module and edit the texts in-situ as needed. Will have to test that.
In any case, I am not sure if the shipping modules will work out of the box in 1.5.5e, nor whether they are still current against the latest Nittsu, Sagawa and Yamato APIs. Again, will need to test that.

A related question would be what happens when Paypal, Nittsu, Sagawa, Yamato or whoever makes changes to their interface that breaks the modules. Fixing such issues could be quite a bit of work, but I assume any to modules would be released individually here on this site (for example I am happy to share any work I do for my site with the community).

I have split work into four parts:
(1) DB changes: leave till later (address format definition(s), name order, hiragana/katakana name field support, etc.)
(2) module changes: addition of Japanese shipping modules to 1.5.5e. This seems to require minimal changes to the declaration function and use of zone_country_id statements (apart from language-specifics).
(3) language addition of Japanese.
(4) template additions/changes (email, etc., as required).

I have started work on making the language files.
First, the differences to includes/languages/english.php between 1.5.1-jp-1 and 1.5.5.e:

Code:

---

4c4
<  * @copyright Copyright 2003-2011 Zen Cart Development Team
---
>  * @copyright Copyright 2003-2016 Zen Cart Development Team
7c7
<  * @version $Id: english.php 19690 2011-10-04 16:41:45Z drbyte $
---
>  * @version $Id: Author: DrByte  Tue Jan 5 15:06:15 2016 -0500 Modified in v1.5.5 $
19c19,20
<  @setlocale(LC_TIME, 'en_US');
---
>  $locales = array('en_US', 'en_US.utf8', 'en', 'English_United States.1252');
>  @setlocale(LC_TIME, $locales);
139d139
<  define('BOX_BBINDEX', 'Forum');
271,274c271,274
<  define('PREVNEXT_BUTTON_FIRST', '<<FIRST');
<  define('PREVNEXT_BUTTON_PREV', '[<< Prev]');
<  define('PREVNEXT_BUTTON_NEXT', '[Next >>]');
<  define('PREVNEXT_BUTTON_LAST', 'LAST>>');
---
>  define('PREVNEXT_BUTTON_FIRST', '«FIRST');
>  define('PREVNEXT_BUTTON_PREV', '[« Prev]');
>  define('PREVNEXT_BUTTON_NEXT', '[Next »]');
>  define('PREVNEXT_BUTTON_LAST', 'LAST»');
479a480
>  define('WARNING_PRODUCT_QUANTITY_ADJUSTED', 'Quantity has been adjusted to what is in stock. ');
509a511
>  define('TEXT_AUTHORIZATION_PENDING_CHECKOUT', 'Checkout Unavailable - Approval Pending');
586a589
>  define('PAYMENT_JAVASCRIPT_DISABLED', 'We could not continue with checkout as Javascript is disabled. You must enable it to continue');
602a606,607
>  define('ERROR_TEXT_COUNTRY_DISABLED_PLEASE_CHANGE', 'Sorry, but we no longer accept billing or shipping addresses in "%s".  Please update this address to continue.');
>
608a614
>  define('ERROR_DATABASE_MAINTENANCE_NEEDED', '<a href="http://www.zen-cart.com/content.php?334-ERROR-0071-There-appears-to-be-a-problem-with-the-database-Maintenance-is-required" target="_blank">ERROR 0071: There appears to be a problem with the database. Maintenance is required.</a>');

---

I therefore modified/added corresponding fields to the includes/languages/japanese.php, so that the differences to the 1.5.1-jp-1 module are as follows:

Code:

---

20c20,21
<  @setlocale(LC_TIME, 'ja_JP.UTF-8');
---
>  $locales = array('ja_JP', 'ja_JP.UTF-8', 'ja', 'Japanese_Japan.932');
>  @setlocale(LC_TIME, $locales);
292,295c293,296
< define('PREVNEXT_BUTTON_FIRST', '<<最初');
< define('PREVNEXT_BUTTON_PREV', '[<< 前へ]');
< define('PREVNEXT_BUTTON_NEXT', '[次へ >>]');
< define('PREVNEXT_BUTTON_LAST', '最後>>');
---
> define('PREVNEXT_BUTTON_FIRST', '«最初');
> define('PREVNEXT_BUTTON_PREV', '[« 前へ]');
> define('PREVNEXT_BUTTON_NEXT', '[次へ »]');
> define('PREVNEXT_BUTTON_LAST', '最後»');
498a500
>  define('WARNING_PRODUCT_QUANTITY_ADJUSTED', 'ご注文個数を在庫中数量に変えました。 ');
528a531
>  define('TEXT_AUTHORIZATION_PENDING_CHECKOUT', '現在チェックアウトを利用できません - 承認手続き中');
605a609
>  define('PAYMENT_JAVASCRIPT_DISABLED', 'Javascriptが無効になっているためチェックアウトの手続きを進めません。Javascriptを有効にしてください。');
621a626,627
>  define('ERROR_TEXT_COUNTRY_DISABLED_PLEASE_CHANGE', 'お手数ですが、"%s"の支払い先または郵送先を受け入れなくなりました。この住所を更新してください。');
>
627a634
>  define('ERROR_DATABASE_MAINTENANCE_NEEDED', '<a href="http://www.zen-cart.com/content.php?334-ERROR-0071-There-appears-to-be-a-problem-with-the-database-Maintenance-is-required" target="_blank">ERROR 0071: データベース問題が発生しているようです。メンテナンスが必要です。</a>');

---

Some contents of japanese.php are still in English in 1.5.1-jp-1, I may translate those later, but first I wanted to update to 1.5.5e standard, based on english.php.

Next, I'll work on the contents of includes/languages/Japanese.

Note: I keep getting token expired on my submissions even after Ctrl-R, pressing the reload icon in the URL bar of Friefox. Ctrl-F5 does not help either. I tried logging out and loggin in again now.

Files that changes in includes/languages/english top-level directory between 1.5.1-jp-1 and 1.5.5e. These will need updating in the languages/japanese:

1. button_names.php
2. checkout_payment.php
3. checkout_success.php
4. create_account_success.php
5. credit_cards.php
6. discount_coupon.php
7. download_time_out.php
8. email_extras.php
9. gv_faq.php
10. gv_redeem.php
11. header.php
12. meta_tags.php
13. password_forgotten.php
14. popup_coupon_help.php
15. reviews.php
16. shopping_cart.php
17. specials.php

Furthermore, a file that is only in 1.5.5e and not in 1.5.1-jp-1:
page.php

After updating the Japanese files I should put them somewhere accessible, even though a work in progress.

I will tackle the lower level directories after that, here the breakdown (no idea of differences yet):

1. classic
2. extra_definitions
3. html_includes
4. images
5. modules

Furthermore, a new directory only in 1.5.5e and not in 1.5.1-jp-1:
responsive_classic

Translations
=========

Translation of language files is completed.
First, the 18 files in the previous post were handled.
Note: in password_forgotten.php Japanese-specific definition EMAIL_GREET is translated ("様", read as "sama", to follow the name of the person addressed).
This is used in checkout_process.php as well (no update needed there).
In any case, definition additions and other changes to the core code I will tackle later.

Next, I took on the sub-directories in languages/japanese/.

A. Classic

One file updated:
1. header.php

B. extra_definitions

No files updated.
New in 1.5.5e is contents of responsive_classic/
Contains one file to translate:
1. product_free_shipping.php

C. html_includes

1. define_main_page.php
3. define_site_map.php

In classic/
3. define_site_map.php

New in 1.5.5e is contents of responsive_classic/
Most of those 12 files are placeholders at present, so I only translated a handful of items.

D. Images

No files to update.

E. modules

E.1 order_total/

One file updated:
1. ot_cod_fee.php

E2. payment/

Following files updated:
1. kuroneko_at_payment.php
2. authorizenet_aim.php
3. authorizenet.php
4. paypaldp.php
5. paypalwpp.php
Note the Paypal files are in English still.

Following file changed:
6. linkpoint_api.php -> firstdata_hco.php
Translation update was minimal.

Following files brought forward to 1.5.5e:
7. remisecps_zen.php
8. remise_zen.php
Note that the above 2 files also exist und languages/english/modules/payment in 1.5.1-jp,
so I brought those forward too and translated them, as they had been left completely in Japanese.

Following file is only in 1.5.5e:
9. payeezyjszc.php
So I copied it to lanauges/japanese/modules/payment
Note that this is untranslated for now, but also none of the Paypal modules were translated in 1.5.1-jp either,
so this is something to do later (having done the remise modules I am confident I can handle that).

H.3 shipping/

The following files were updated:
1. nittsu.php
2. sagawaex.php
3. yamato.php
All three need to be in the english version too, so I copied those from 1.5.1-jp (sawagaex.php is sagawa.php in the english subdir).
While I updated these language-wise, there are bigger problems:
(1) Nittsu no longer offers this service (since 2010 handled by Japanese Post Office "Yupack" service).
(2) all three need updates to the pricing, time service, and region definitions in the corresponding claculator code:
./includes/classes/_nittsu.php
./includes/classes/_sagawaex.php
./includes/classes/_yamato.php

Based on the above modules, a new module for Yupack service should be fairly simple to code later.

F. New in 1.5.5e: responsive_classic

Three files to translate, based on those in the other (classic and default) templates.
1. icon_names.php
2. index.php
3. other_images_names.php

Module Changes
============

I updated the Japanese-specific payment and shipping modules in two places:
- constructor statement changed from "function modulename() {" to "function __construct() {"
- (int) in front of the $order->... statement

1. includes/modules/payment/remisecsp_zen.php
2. includes/modules/payment/remise_zen.php
3. includes/modules/shipping/nittsu.php
4. includes/modules/shipping/sagawaez.php
5. includes/modules/shipping/yamato.php

Button images
===========

I copied across the entire button directory of Japanese images:
includes/templates/template_default/buttons/japanese
There do not appear to be any button changes between 1.5.1-jp and 1.5.5e.

Sumamry so far:
The above work was purely on the user side of the site, comparing changes between the English 1.5.1 and 1.5.5e, and then updating the Japanese language files 1.5.1 to 1.5.5e standard (since they do not exist in 1.5.5e).
The exception here is the Japanese-version module and class files, which were updated to 1.5.5e standard by inspection of other 1.5.5e modules (and note that the shipping modules need updating, and the remise payment module is untested for present use).

To actually make use of all of this, the following changes are required:

(1) updates to the admin/ folder. If not interested in localization, probably the admin/includes/language/japanese/ and admin/includes/languages/japanese/images/buttons/ could be left out. But a lot of customization has been done in 1.5.1-jp compared to 1.5.1, to support use in Japan. A diff between 1.5.1-jp and 1.5.1 showed up 97 files with changes. Of these 80 were in admin/includes/languages/japanese/ and likely can be skipped for now. Some naviagation sidebox has been added, so japanese.php and english.php include some changes for that.
The following files have changes, but do not appear to be directly related to Japanese:
- admin/includes/menu.css
- admin/includes/modules/document_general/preview_info_meta_tags.php
- admin/includes/modules/document_general/preview_info.php
- admin/includes/modules/document_product/preview_info_meta_tags.php
- admin/includes/modules/document_product/preview_info.php
- admin/includes/stylesheet.css
The remaining files with large changes are:
- admin/customers.php: furigana support among other things
- admin/includes/functions/localization.php: seems to be general updates/corrections, not related to Japanese use

(2) updates to the includes/ folder. Some work on modules was handled earlier and is not repeated here.

- includes/application_top.php: furigana support
- includes/functions/functions_email.php: something to do with charset (maybe general upgrade)
- includes/modules/checkout_new_address.php: furigana support
- includes/modules/create_account.php: furigana support
- includes/modules/order_total/ot_cod_fee.php: new shipping modules support
- includes/modules/pages/account_edit/header_php.php: furigana support
- includes/modules/pages/address_book_process/header_php.php: furigana support
- includes/modules/pages/contact_us/header_php.php: add display of privacy conditions (general upgrade?)
- includes/templates/classic/css/stylesheet.css: use of EZpages added
- includes/templates/template_default/templates/tpl_account_edit_default.php: furigana support
- includes/templates/template_default/templates/tpl_contact_us_default.php: add display of privacy conditions (general upgrade?)
- includes/templates/template_default/templates/tpl_modules_address_book_details.php: furigana support
- includes/templates/template_default/templates/tpl_modules_checkout_new_address.php: furigana support
- includes/templates/template_default/templates/tpl_modules_create_account.php: furigana support

(3) updates to the zc_install/ folder and actual database changes. The zc_install/includes/languages/japanese/ files (11 of them) are probably not needed at this stage. english.php and japanese.php again have the customized navigation sidebox additions, as does zc_install/includes/templates/template_default/sideboxes/navigation.php.
Other small changes are in:
- install.txt: info only
- zc_install/includes/templates/template_default/css/stylesheet.css
- zc_install/includes/templates/template_default/templates/about_zencart_ja.html
- zc_install/includes/templates/template_default/templates/gpl_license.japanese.html
- zc_install/includes/templates/template_default/templates/index_default.php: Japanese version
- zc_install/includes/templates/template_default/templates/license_default.php: Japanese version
Japanese demo data (not needed at thsi stage) is installed with:
- zc_install/demo/mysql_demo.sql
While the meat of the Japanese installation is in the following files:
- zc_install/includes/application_top.php: language setting (for installer only?)
- zc_install/includes/classes/installer.php: read localized sql (see below)
- zc_install/includes/modules/pages/store_setup/header_php.php: store country and zone set to Japan
- zc_install/sql/mysql_utf8_japanese_localize.sql: carries out the actions below
1. set display of price with tax
2. set default country Japan (107)
3. set privacy statement/conditions with Japanese law in mind
4. add a newe address format for use in Japan
5. set currency conversion defaults for USD, Euro, GBP, CAD, AUD and add JPY as standard
6. set language as Japanese
7. set use of new address format when country is Japan
8. add prefectures as zone(s?)
9. set prefecture zone(s) in same geo_zone Japan (107)
10. set tax_rate (update needed)
11. set geo_zone name/desc as tax zone
12. set tax class
13. set status words for new orders (addition, it seems, maybe use these in Japanese orders separate from English ones?)
14. add Telephone address to address book, remove from personal information (customer, orders) for privacy reasons
15. add kana (furigana) support to address book, customer, orders
16. set furigana required for coutnry Japan
17. translate general admin setting groups
18. translate mail sending (admin)
19. translate product_type layout (admin)
20. add feature for optional text to be added to product (not sure if this is needed, but it would be in some product-related templates then)

The job now is two-fold, as I see it:

First. in the above files, the logic of adding Japan-specific support in various files and in the database (with the localized sql file) needs to be added to the corresponding 1.5.5e files. At the same time, and non-Japanese-specific upgrades should be taken into account (not all changes may need to be carried forward). In particular, for now localization is not my goal, so only addition of Japan-centric information should be carried out.
This would involve comparing 1.5.1 international and 1.5.5e files, quite a job since there are many changes.

Second, any language-specific files would need to be added in 1.5.5e. diff does not work so great comparing translations, so probably the best (though tedious) way would be to to a file-by-file comparison between 1.5.1-jp and the 1.5.5e english files. No doulbt some files are no longer there, others might be new, or the functionality moved elsewhere.

I am not sure if overrides of definitions are required in any of the above, as opposed to only Japanese language additions in the language sub-folder. Even templates seem to be in this sub-folder.
However, for admin use, where I seem to recall overrides to not work, the support need for furigana would mean some changes to existing admin files. How to do this I am not quite sure, confused after too much reading of different topics...

Comments to self:

1. After reading more on the Wiki about Admin functions, it is clear (as I suspected) that a large part of the mysql_utf8_japanese_localize.sql is automating things that can be done from the admin console. Thus this can be skipped in a language pack.
2. According to overrides documentation, includes/* files can be extended in includes/extra_datafiles/*, but not sure if that means additions, or entire overrides. Also, this does not seem to be an override directory, no language or template custom name given. For Japanese we need changes to application_top.php.
3. No idea how to handle admin/customers.php, where furigana support addition is required. admin/includes seems OK for language specifics.

Note to self: from above list, set of files that cannot be overridden at present as I understand it:

A. includes/
1. includes/application_top.php
2. includes/classes/order.php
3. includes/modules/order_total/ot_cod_fee.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

B. admin/
1. admin/customers.php
2. admin/includes/functions/localization.php
3. admin/includes/menu.css
4. admin/includes/modules/document_general/preview_info_meta_tags.php
5. admin/includes/modules/document_general/preview_info.php
6. admin/includes/modules/document_product/preview_info_meta_tags.php
7. admin/includes/modules/document_product/preview_info.php
8. admin/includes/stylesheet.css

So language pack will be perhaps in three parts:
1. usual langauge translation additions which will enable users to view pages (no changes to core files required, and adds Japanese shipping modules). Anyone wishing to have this support can easily install and uninstall this part.
2. additions that will allow Japanese persons to register with Furigana support (requires changes to core files, several admin files, and database. Adds one Japanese payment module). Anyone using this will have to reconcile the modified files provided (based on standard 1.5.5e) with whatever customizations they have made in the corresponding files. Furthermore, removing the additions will require review of the database (for example, I don't know if it is feasible to remove an address format once some customer information is using that format).
3. further additions that translate the admin section into Japanese (even adding Furigana support requires changes to core and admin files though). Again, anyone using this will have to reconcile the modified files provided with whatever customization they have made in the corresponding files. However, there should not be any database changes here, so removal would be straightforward reversion to the old files (and reconciling any additional customizations made in the meantime which the additions were active).

I hope that is more or less logical.

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.

Hello mc12345678,
Many thanks for the feedback.
I will have a look at the code in more detail later this week, and study how I could use observer classes to manipulate the data.
As for what functionality in application_top, it is the addition of furigana support.
Here the diff between 1.5.1-jp and 1.5.1 (something similar is what I expected I would need to add to the corresponding 1.5.5e file):

Code:

---

diff -wu -Nr zen-cart-v1.5.1-jp-1/includes/application_top.php zen-cart-v1.5.1/includes/application_top.php
--- zen-cart-v1.5.1-jp-1/includes/application_top.php        2013-01-17 21:46:58.000000000 +0900
+++ zen-cart-v1.5.1/includes/application_top.php        2012-09-18 21:36:42.000000000 +0900
@@ -159,12 +159,3 @@
 if (!isset($_SESSION['customers_ip_address'])) {
  $_SESSION['customers_ip_address'] = $customers_ip_address;
 }
-
-/**
-  * is Furikana nesessary?
-**/
-if (defined('FURIKANA_NECESSARY_COUNTRIES') &&
-  !is_bool(strpos(strtolower(FURIKANA_NECESSARY_COUNTRIES), strtolower($_SESSION['language']))))
-  define('FURIKANA_NESESSARY', true);
-else
-  define('FURIKANA_NESESSARY', false);

---

I've been going through related Japanese language module threads while trying to figure out the best way to handle the zone for prefectures: English or Japanese or both. Crystal Koi Designs is no longer around it seems, so I cannot access any nifty pull-down jscript that was made available back in the day to enable choice between either language when selecting a prefecture.
I figure it will be logical to have 2 zone files available, one for English (default, maybe check for existing Japanese zones and update them if they exist...), and another that updates this to Japanese if desired (or installs new if no English or Japanese zones found).

The following thread has some (now old) modules for shipping that I will look at. They would need updating, but it seems they might contain size as well as weight breakdown, which is something quite necessary but missing (as far as I can tell) in the 1.5.1-jp shipping modules.
https://www.zen-cart.com/showthread....anguage+module

I've created two zones files for Japan.
The attached ZIP file contains two SQL files for adding zones:

1. An English version of the prefecture names
2. A Japanese version of the prefecture names

For the code, I have chosen the ISO 3166-2:JP code (JP-01 through JP-47), which I discovered while trying to decide on what to put for code.
The great thing is that the default sort order will result in the normal sequence of prefectures seen on Japanese sites, namely from North to South. I haven't seen this in the Japanese localized version, I think the English version would be a great addition for the default settings in ZenCart.
If someone can check that there is nothing wrong with these zones file (I have looked at some add-ons and this seems to be close to what others have uploaded) I will put this in the Zones Add-Ons sub-forum.

Quote:

---

Originally Posted by gernot

Hello mc12345678,
Many thanks for the feedback.
I will have a look at the code in more detail later this week, and study how I could use observer classes to manipulate the data.
As for what functionality in application_top, it is the addition of furigana support.
Here the diff between 1.5.1-jp and 1.5.1 (something similar is what I expected I would need to add to the corresponding 1.5.5e file):

Code:

---

diff -wu -Nr zen-cart-v1.5.1-jp-1/includes/application_top.php zen-cart-v1.5.1/includes/application_top.php
--- zen-cart-v1.5.1-jp-1/includes/application_top.php        2013-01-17 21:46:58.000000000 +0900
+++ zen-cart-v1.5.1/includes/application_top.php        2012-09-18 21:36:42.000000000 +0900
@@ -159,12 +159,3 @@
 if (!isset($_SESSION['customers_ip_address'])) {
  $_SESSION['customers_ip_address'] = $customers_ip_address;
 }
-
-/**
-  * is Furikana nesessary?
-**/
-if (defined('FURIKANA_NECESSARY_COUNTRIES') &&
-  !is_bool(strpos(strtolower(FURIKANA_NECESSARY_COUNTRIES), strtolower($_SESSION['language']))))
-  define('FURIKANA_NESESSARY', true);
-else
-  define('FURIKANA_NESESSARY', false);

---

I've been going through related Japanese language module threads while trying to figure out the best way to handle the zone for prefectures: English or Japanese or both. Crystal Koi Designs is no longer around it seems, so I cannot access any nifty pull-down jscript that was made available back in the day to enable choice between either language when selecting a prefecture.
I figure it will be logical to have 2 zone files available, one for English (default, maybe check for existing Japanese zones and update them if they exist...), and another that updates this to Japanese if desired (or installs new if no English or Japanese zones found).

The following thread has some (now old) modules for shipping that I will look at. They would need updating, but it seems they might contain size as well as weight breakdown, which is something quite necessary but missing (as far as I can tell) in the 1.5.1-jp shipping modules.
https://www.zen-cart.com/showthread....anguage+module

---

Haven't looked to see where FURIKANA_NECESSARY_COUNTRIES is defined, but if it is defined after the session has started, then the above modification could be incorporated there or in another file loaded after that point. Then application_top would not need to be modified.

Hi,
I get at what you are saying, especially in this case where it is merely a conditional (and extra) define.
For what it is worth, the define is made in the localization SQL file zc_install/sql/mysql_utf8_japanese_localize.sql:

Code:

---

INSERT INTO configuration (configuration_title, configuration_key, configuration_value, configuration_description, configuration_group_id, sort_order, set_function, date_added) VALUES
('ふりがなが必要な国', 'FURIKANA_NECESSARY_COUNTRIES', 'Japanese', 'ふりがなが必要な国名をカンマで区切って入力してください', '5', '100', '', now());

---

So this adds an admin configuration element (presumably some template files are modified to realize this) into which one can put the list of countries for which this should be true. The code I quoted in the previous comment seems to only compare the session language chosen by the user, not really a good way to decide whether to make kana necessary in my view (unless I am missing something).
OK, so clearly this condition check happens once a session is in progress, and not before. Whether that is a good way to do that is another issue, since in my view the use of kana should be separate from the language, it is a user property after all. Making it a site-wise optional element would be realistic also I suppose, controlled from the admin console.

I've made my own address format addition SQL statement, to insert the new format and set for use by country Japan (countires_id=107), checking for existing ones with a procedure, without modifying the address_format table with unique keys.

Code:

---

# Japan address format addition if not already set

# (1) simple method based on Japanese localization in 1.5.1 assuming 8 will be the next available record in address_format (7 existing formats in 1.5.5e by default)

INSERT INTO address_format VALUES (8, '$firstname $lastname$cr$postcode$cr$state$city$cr$streets$cr$country$cr$telephone$cr$fax','$statename $city');
UPDATE countries SET address_format_id=8 WHERE countries_id=107;

# (2) more complex method that uses a precedure to insert a new address format for Japan only if the values of the two fields do not yet exist
#    Note this does not modify the address_format table to use unique keys (as would be required by DUPLICATE KEYS or IGNORE statements)
#    The update to the coutries table is done at the same time, using the values of the address format

DELIMITER $$
DROP PROCEDURE IF EXISTS insert_jp_address_format $$
CREATE PROCEDURE insert_jp_address_format()
BEGIN
IF NOT EXISTS (SELECT * FROM address_format WHERE address_format = '$firstname $lastname$cr$postcode$cr$state$city$cr$streets$cr$country$cr$telephone$cr$fax' AND address_summary = '$statename $city') THEN
    INSERT INTO address_format (address_format,address_summary) VALUES ('$firstname $lastname$cr$postcode$cr$state$city$cr$streets$cr$country$cr$telephone$cr$fax','$statename $city');
    UPDATE countries SET address_format_id=(SELECT address_format_id FROM address_format WHERE address_format = '$firstname $lastname$cr$postcode$cr$state$city$cr$streets$cr$country$cr$telephone$cr$fax' AND address_summary = '$statename $city') WHERE countries_id=107;
END IF;
END $$
DELIMITER ;

CALL insert_jp_address_format();

# Utility/Reference:
#
# Direct update:
# update countries set address_format_id=(select address_format_id from address_format where address_format = '$firstname $lastname$cr$postcode$cr$state$city$cr$streets$cr$country$cr$telephone$cr$fax' and address_summary = '$statename $city') where countries_id=107;
#
# To get back to original (address_format_id=1):
# update countries set address_format_id=(select address_format_id from address_format where address_format = '$firstname $lastname$cr$streets$cr$city, $postcode$cr$statecomma$country' and address_summary = '$city / $country') where countries_id=107;

---

After reading up on notifiers/observers, I tried to find a notifier to attach in include/application_top.php. However, there does not appear to be one.
On the other hand, it seems I could use includes/extra_configures for exactly this purpose?
So I made a new file as follows, using the (slightly corrected spelling) logic from the Japanese localization for now. I don't know what to put in the header for the package, constants does not seem right, so I made up "langauges" until I learn what would be best:

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 $
 */
/**
  * is Furigana necessary?
**/
if (defined('FURIGANA_NECESSARY_COUNTRIES') &&
  !is_bool(strpos(strtolower(FURIGANA_NECESSARY_COUNTRIES), strtolower($_SESSION['language']))))
  define('FURIGANA_NECESSARY', true);
else
  define('FURIGANA_NECESSARY', false);

---

If this is correct, then this extra file would be added to the Japanese language pack now in preparation, and application_top.php has no changes.
For the code where FURIGANA_NECESSARY is used, I don't know how to handle that yet, but if it can be done by notifiers that would of course be great.

As an aside, the Japanese localization mades some changes to the database fields too for kana support obviously, but also for privacy of customer's telephone number:

Code:

---

# add telephone number to address, but remove from private information
ALTER TABLE address_book ADD COLUMN entry_telephone varchar(32) NOT NULL;
ALTER TABLE address_book ADD COLUMN entry_fax varchar(32);
ALTER TABLE orders ADD COLUMN delivery_telephone varchar(32);
ALTER TABLE orders ADD COLUMN delivery_fax varchar(32);
ALTER TABLE orders ADD COLUMN billing_telephone varchar(32);
ALTER TABLE orders ADD COLUMN billing_fax varchar(32);
ALTER TABLE orders ADD COLUMN customers_fax varchar(32);
ALTER TABLE customers CHANGE customers_telephone customers_telephone VARCHAR(32);
ALTER TABLE orders CHANGE customers_telephone customers_telephone VARCHAR(32);

# Furigana support added
ALTER TABLE address_book ADD entry_firstname_kana    varchar(32) NOT NULL default '';
ALTER TABLE address_book ADD entry_lastname_kana      varchar(32) NOT NULL default '';
ALTER TABLE customers    ADD customers_firstname_kana varchar(32) NOT NULL default '';
ALTER TABLE customers    ADD customers_lastname_kana  varchar(32) NOT NULL default '';
ALTER TABLE orders      ADD customers_name_kana      varchar(64) NOT NULL default '';
ALTER TABLE orders      ADD delivery_name_kana      varchar(64) NOT NULL default '';
ALTER TABLE orders      ADD billing_name_kana        varchar(64) NOT NULL default '';

---

Is this revertable at all, if one decides to use Japanese language with kana support (and Japan-centric privacy setting of telephone number)? Once data is entered, I presume this is not removable again if one uninstalls the language pack. It would be up to the user to decide how to dispose of the data first?

Further work, nothing with notifiers although I think part of the changes for furigana and address book change support could be done that way.

1. Custom files created for following files - to be placed in override directories (either generic common override directories, or custom template directories, as permitted)
   
   1. admin/customers.php: furigana support/address changes. Not overridable?
   2. includes/classes/order.php: since the order deals with addresses and mysql queries, I am unable to understand at present if changes can be make later with notifiers here. Overridable?
   3. includes/modules/checkout_new_address.php: furigana support/address changes. Overridable?
   4. includes/modules/create_account.php: furigana support/address changes. Overridable?
   5. includes/modules/order_total/ot_cod_fee.php: addition of Japan shipping modules. Overridable?
   6. includes/modules/pages/account_edit/header_php.php: furigana support/address changes. Overridable?
   7. includes/modules/pages/address_book_process/header_php.php: furigana support/address changes. Overridable?
   8. includes/modules/pages/contact_us/header_php.php: for privacy policy. Overridable?
   9. includes/templates/template_default/templates/tpl_account_edit_default.php: furigana support/address changes. Overridable OK.
   10. includes/templates/template_default/templates/tpl_contact_us_default.php: privay policy. Overridable OK.
   11. includes/templates/template_default/templates/tpl_modules_address_book_details.php: furigana support/address changes. Overridable OK.
   12. includes/templates/template_default/templates/tpl_modules_checkout_new_address.php: furigana support/address changes. Overridable OK.
   13. includes/templates/template_default/templates/tpl_modules_create_account.php: furigana support/address changes. Overridable OK.
2. Privacy policy for Japan has an addition to the admin configuration. I don't know if I can put that in an override somewhere, so for now I will make the definition in the same SQL file as the zones and address book, kana definition and address format additions.
   
   Code:

   ---

   # privacy conditions
INSERT INTO configuration (configuration_title, configuration_key, configuration_value, configuration_description, configuration_group_id, sort_order, set_function, date_added) VALUES ('Privacy policy confirmation for contact', 'DISPLAY_CONTACT_US_PRIVACY_CONDITIONS', 'true', 'In contact us page, display confirmation for privacy policy. <div style="color: red;">The guidelines for protection of personal information are displayed, in compliance with the Act on the Protection of Personal Information effective since April 1, 2005 and the Amended Act effective from May 30, 2017.</div>', '11', '3', 'zen_cfg_select_option(array(\'true\', \'false\'), ', now());

   ---

3. Privacy policy extended to contact_us page in Japanese as part of custom files above. But since this also should apply to the English page, I added the definitions from login.php to contact_us.pp in includes/languages/english/. The modified file can go into a custom template directory.

So now the work is just about done at a basic level:

• pure language translations without customizing for Japan
• addition of address format, zones, shipping modules for Japan
• addition of address book changes, furigana (kana) support, privacy policy support additions

No changes made to stylesheet or CSS (yet), something which is also done in the Japanese localization (something with EZ pages also, but I haven't looked at that yet, or if it is even desirable).

I hope to be able to test on my own site in the next few days, debugging as required (still trying to figure out definitively what can be overridden, and in which way - extension via generic override directory, using custom template, or replacement of core files, as the case may be).
Then I will put up the combined files for others to experiment on. I am pretty sure some people with experience will give feedback. And possible some thing, like the privacy policy addition to contact_us.php, might be desirable as a core feature in Zen Cart.

Previous post appears to be still in moderation - this post is testing the basic language module that was completed up till now.
Two things of note:

1. Charset in japanese.php (normal and admin): I had to put specific UTF-8 before generic ja_JP, else a couple of variables would not display correctly. These were things like %a for the short dayname, or %s for the month name (in Japanese). Despite looking at various threads, and adding files in extra_configures to control the charset of the DB even more, no changes were achieved. I don't know what causes this, but setting ja_JP.UTF-8 as the first item in the array solves it (all files are saved in UTF-8 format, and since this is 1.5.5e upgraded from 1.5.5d the DB and system has only ever used UTF-8 as far as I can tell).
   
   Code:

   ---

   $locales = array('ja_JP.UTF-8', 'ja_JP', 'ja', 'Japanese_Japan.932');

   ---

2. I cannot figure out how to control which language displays in the browser: Initially, when I had the default language to be English, and the Store default language setting also at default, then I only got English displaying in the browsers on (English) linux and (Japanese) Windows, even though the browser default in Japanese Windows is Japanese. Setting the default language in the store to Japanese immediately changed the browser display on linux and Windows to Japanese. Setting default store language back to English, but setting the store default language setting to "browser" had no effect, still Japanese on linux and English on Japanese windows. Very odd. I read that browser language can only be explicitly set on Windows; on linux and MacOS systems the default OS language is used. What should I expect to be able to control? Ideally, I would like to be able for a user to switch between languages - maybe that is would require a separate plugin?

Some sideboxes and other defines are apparently not yet translated - there were many more in the 1.5.1-jp japanese.php, but I removed everything that did not have a corresponding entry in 1.5.5e english.php, so now I guess I need to add them back one by one, checking that the names have not changed (or been removed).
Other than that, I am pretty happy that there are no PHP errors or debugs to do (strict error display on-screen enabled for now).
I also haven't put in the database changes and custom files for working in Japan, or activated the Japanse shipping modules.

Note: solved issue of non-controllability of language by browser settings, by activating language sidebox.
Confirmed that categories and products all have English and Japanese settings available now, so all in all, pretty happy about the progress.
I need to check the contents of includes/languages/japanese.php and admin/includes/languages/japanese.php more to see if I need to add back any defines I chopped out, but apart from that, the langauges files are done.
The core files issue still remains, I'll post where I put each file (if I could find a working override) or if I had to resort to replacing core files directly.
Then, upload my work for others to make use of as well.

Progress report:

1. As part of handling the override requirements, I added a custom template override based on responsive_classic, and made sure that the English and Japanese appeared correctly.
2. I then installed the EZPages multili-language plugin, and made sure I could translate the EZPages, leading to a completely bilingual site (keeping backups of ezpages-related original files that had to be replaced by this plugin).
3. Then, the tagline was translated using a language override.
4. I've not swapped the name and surname in the core files for Japanese customization (those mention in previous comments, related to user registration and account management), so I will need to check how registering users works. If really needed for Japan use (i.e., not possible to work around with various templates), this will be a bit of a pain, since again it is not easily revertable.

So now what is left is to continue the overrides possible with the cutom template, and document as needed if any core files need to be replaced.

I attach the database changes and the extra configs needed for Japanese address book changes, zone definitions, and kana configuration. Contents of the ZIP file are as follows:

1. Japan-address-format.sql: when run, address Japanese address format and assigns it to use for country Japan (107).
2. Japan-address-additions.sql: when run, modified address_book, customers and orders table for Japanese standard, adds kana fields, and adds an admin configuration where languages requiring kana usage should be registered. Japanese is registered by default.
3. Japan-zones-en.sql: when run, adds the ISO 3166-2:JP code (JP01 through JP-47) and Engish name for the 47 Japanese prefectures.
4. zen-extra-configs.txt: contains the contents of set_kana_support.php, which should be placed in includes/extra_configures/set_kana_support.php. This extends definitions in application_top.php withouth modifying the file. Note I have changed the key to be FURIGANA_NECESSARY_LANGUAGES rather than countries, as the test is for browser language rather than country.

Using procedure definitions, I have tested that running the SQL files ("source filename" or "\. filename" from the mysql prompt, or with "mysql DBname < filename" from the command prompt) multiple times should cause no problems, so no duplicate entries (e.g., for zone definitions) will result.

One additional SQL file with additional settings for Japan.
This one includes the admin configuration for Privacy Policy agreement when contacting store owner, and adds the tax rate and tax zone definitions (assuming tax_rates id=1 and geo_zone id=1). Again, running multiple times should have no bad effects.

So now we have the following:
- language files translated and working
- cutom template defined for template overrides
- EZPages multi-language module installed and working (needs custom template)
- database changes and admin configs added for Japan usage

The program files to actually make use of the Japan-centric definitions and fields have been created already (see previous posts), and I will endeavour to use as much of the override system as possible (no notifiers written, just custom files for now, since virtually all the issues are with the construction of queries for addresses and names).

Quote:

---

Originally Posted by gernot

I've made my own address format addition SQL statement, to insert the new format and set for use by country Japan (countires_id=107), checking for existing ones with a procedure, without modifying the address_format table with unique keys.

Code:

---

# Japan address format addition if not already set

# (1) simple method based on Japanese localization in 1.5.1 assuming 8 will be the next available record in address_format (7 existing formats in 1.5.5e by default)

INSERT INTO address_format VALUES (8, '$firstname $lastname$cr$postcode$cr$state$city$cr$streets$cr$country$cr$telephone$cr$fax','$statename $city');
UPDATE countries SET address_format_id=8 WHERE countries_id=107;

# (2) more complex method that uses a precedure to insert a new address format for Japan only if the values of the two fields do not yet exist
#    Note this does not modify the address_format table to use unique keys (as would be required by DUPLICATE KEYS or IGNORE statements)
#    The update to the coutries table is done at the same time, using the values of the address format

DELIMITER $$
DROP PROCEDURE IF EXISTS insert_jp_address_format $$
CREATE PROCEDURE insert_jp_address_format()
BEGIN
IF NOT EXISTS (SELECT * FROM address_format WHERE address_format = '$firstname $lastname$cr$postcode$cr$state$city$cr$streets$cr$country$cr$telephone$cr$fax' AND address_summary = '$statename $city') THEN
    INSERT INTO address_format (address_format,address_summary) VALUES ('$firstname $lastname$cr$postcode$cr$state$city$cr$streets$cr$country$cr$telephone$cr$fax','$statename $city');
    UPDATE countries SET address_format_id=(SELECT address_format_id FROM address_format WHERE address_format = '$firstname $lastname$cr$postcode$cr$state$city$cr$streets$cr$country$cr$telephone$cr$fax' AND address_summary = '$statename $city') WHERE countries_id=107;
END IF;
END $$
DELIMITER ;

CALL insert_jp_address_format();

# Utility/Reference:
#
# Direct update:
# update countries set address_format_id=(select address_format_id from address_format where address_format = '$firstname $lastname$cr$postcode$cr$state$city$cr$streets$cr$country$cr$telephone$cr$fax' and address_summary = '$statename $city') where countries_id=107;
#
# To get back to original (address_format_id=1):
# update countries set address_format_id=(select address_format_id from address_format where address_format = '$firstname $lastname$cr$streets$cr$city, $postcode$cr$statecomma$country' and address_summary = '$city / $country') where countries_id=107;

---

---

Had seen this post earlier and had thought then to reply, but you've been so busy I didn't want to introduce too much noise.

My recommendation regarding #1 and #2 above is to go more towards #2. Additionally, if you were to incorporate an auto-installer into this process you could use more php related functions/queries to gather the information possibly "easier" than pushing against the database. Whatever works though. :) The reason I recommend something like #2 is try to think about what it is you're doing. You are trying to make one language system more compatible and easier to work with ZC, there are other languages/destinations that may have the same situation. By reading and writing to the database rather than casting a hard value, you are making this plugin/language more pliable so that there is not a conflict between this one and another. It is a win-win.

Quote:

---

Originally Posted by gernot

After reading up on notifiers/observers, I tried to find a notifier to attach in include/application_top.php. However, there does not appear to be one.
On the other hand, it seems I could use includes/extra_configures for exactly this purpose?
So I made a new file as follows, using the (slightly corrected spelling) logic from the Japanese localization for now. I don't know what to put in the header for the package, constants does not seem right, so I made up "langauges" until I learn what would be best:

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 $
 */
/**
  * is Furigana necessary?
**/
if (defined('FURIGANA_NECESSARY_COUNTRIES') &&
  !is_bool(strpos(strtolower(FURIGANA_NECESSARY_COUNTRIES), strtolower($_SESSION['language']))))
  define('FURIGANA_NECESSARY', true);
else
  define('FURIGANA_NECESSARY', false);

---

If this is correct, then this extra file would be added to the Japanese language pack now in preparation, and application_top.php has no changes.
For the code where FURIGANA_NECESSARY is used, I don't know how to handle that yet, but if it can be done by notifiers that would of course be great.

As an aside, the Japanese localization mades some changes to the database fields too for kana support obviously, but also for privacy of customer's telephone number:

Code:

---

# add telephone number to address, but remove from private information
ALTER TABLE address_book ADD COLUMN entry_telephone varchar(32) NOT NULL;
ALTER TABLE address_book ADD COLUMN entry_fax varchar(32);
ALTER TABLE orders ADD COLUMN delivery_telephone varchar(32);
ALTER TABLE orders ADD COLUMN delivery_fax varchar(32);
ALTER TABLE orders ADD COLUMN billing_telephone varchar(32);
ALTER TABLE orders ADD COLUMN billing_fax varchar(32);
ALTER TABLE orders ADD COLUMN customers_fax varchar(32);
ALTER TABLE customers CHANGE customers_telephone customers_telephone VARCHAR(32);
ALTER TABLE orders CHANGE customers_telephone customers_telephone VARCHAR(32);

# Furigana support added
ALTER TABLE address_book ADD entry_firstname_kana    varchar(32) NOT NULL default '';
ALTER TABLE address_book ADD entry_lastname_kana      varchar(32) NOT NULL default '';
ALTER TABLE customers    ADD customers_firstname_kana varchar(32) NOT NULL default '';
ALTER TABLE customers    ADD customers_lastname_kana  varchar(32) NOT NULL default '';
ALTER TABLE orders      ADD customers_name_kana      varchar(64) NOT NULL default '';
ALTER TABLE orders      ADD delivery_name_kana      varchar(64) NOT NULL default '';
ALTER TABLE orders      ADD billing_name_kana        varchar(64) NOT NULL default '';

---

Is this revertable at all, if one decides to use Japanese language with kana support (and Japan-centric privacy setting of telephone number)? Once data is entered, I presume this is not removable again if one uninstalls the language pack. It would be up to the user to decide how to dispose of the data first?

---

I saw this one as well...

Privacy concerns??? At what stage or what portion of the overall operation is privacy being protected? By this I mean... Is it that the data should never be collected? Is it that it should not be displayed to a user when they are logged in? Is it that a store should never know the information? If the above (and I think a long time ago I had attempted installation of this language pack just to see what it did and was a little "shocked") is intended to wipe some or all of the data from the server, well there is a problem then. The problem is that the store may operate in more than one environment. Clearing/removing existing data would have a negative impact on the existing collected data. Complete prevention of collecting data from any location in the future would have the same concern. The expectation of the store's operation is that when the service is properly operated and maintained that the data not be available to others. If the desire or expectation is to not collect certain data because of where the person lives or where the item is being sent, then that should be controlled outside of the database and should be prevented from being added to the database when it meets those requirements.

If the concerns relate to the additional fields in the database, well, yes the fields would persist until they are removed (uninstall script which could be broken up to accommodate particular portions of the program so that historical data could be maintained for any collected). Another option which is a bit more extensive is to use/create tables outside of the above tables so that they are independent of the remainder of the store's code. If the store were operated only in Japanese and every entry required the kana style fields, then that would be useless, but in maintaining a database, the ideal situation is that every field in a table has a purpose and is used all of the time. If it is not, then the question arises of if it should be in a separate or linked table such that it only receives information pertinent to its intent. For example (and possibly one of the most disliked) the products_attributes table contains all of the attributes for all of the products, but not all products have attributes... So there is not an entry for every possible product, but there is an entry for every product that has attributes...

The two commands that concern me most are:

Code:

---

ALTER TABLE customers CHANGE customers_telephone customers_telephone VARCHAR(32);
ALTER TABLE orders CHANGE customers_telephone customers_telephone VARCHAR(32);

---

Which in a ZC 1.5.5 store is not necessary for the table itself (already defined that way) and I haven't done any research on the effect of executing that on an existing database... I would have thought nothing would happen, but...

Hello,
Many thanks for your feedback and advice. Regarding using procedures to read/write to the DB, agreed 100%, just need(ed) to spend the time to get something working reliably. I don't have any experience with auto installers and PHP so for now I'll try to cover everything with the direct SQL statement methods, but in future, for example for 1.5.5 upgrades or the 1.6 version support, I should think about that. I suppose the plugins I already used (EZPages) had an auto installer in it somewhere, but I simply followed the instructions for putting files somewhere, then ran install from the admin console. Will look at that at a later stage, once I know exactly what I want to achieve.

To your next message, I don't know the importance of the changes for Japan, so I cannot say whethere there was legal advice involved, but this is what the 1.5.1-jp language installer does. I wrote it a bit more clearly in the latest attachment, it basically forces the user to add a telephone number (not NULL) to the address book, but removed the restriction from customers and orders (altering the table to allow NULL there - the two lines you quoted). I haven't got the stage of testing users and orders, but I imagine it is something to do with what information is automatically output from the orders and customers table when doing orders/shipping actions, maybe emails sent? So it is not about collection of that data or not, only which table it is stored in.

Thanks for the advice on the implications of adding fields to tables, and how perhaps to avoid that. I am a bit stuck as I want to first get something working, and I think the hurdle is a bit much for me right now! Kana addition is not that much of a problem fortunately, and not even necesary to enter if a Japanese user does not want to.

Sorry if I miss something, more time tonight. I just wanted to add that in the changes to the core files required by kana support and the various address changes, I baulked at changing the order of first and last name. I don't know a good way to handle this for now, but there must be a better way than telling the user to enter last name in the first name field, and vice versa lol.

I've left the DB-related stuff till the weekend: there are afew more apparently convenient settings for shops in Japan, but I did not have time to write procedures for these yet (they are part of the localized zc_install SQL, I just did not add them to the previously uploaded Japan-settings-additions.sql).
To make it clear, I want to recreate the behaviour of the 1.5.1-jp localization before diving into both the PHP code and DB tables and looking at how to best separate core code from localizations with separate tables and logic. I haven't any experience of ZenCart as yet, so it makes me feel more secure to start out with a working if somewhat blighted system.

I've now put all the customized core files in place as far as I am able without further work. For admin/ and includes/classes and subfolders of includes/modules, I created dummy override folders based on my customname (<customname>-dummy) to hold both the original and the modified files, while I replaced the original with the modified file in the original location.
Files that were treated in that manner were:

1. admin/customers.php
2. includes/classes/order.php
3. includes/modules/order_total/ot_cod_fee.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

Files that could be overridden with the override system were:

1. includes/modules/checkout_new_address.php
2. includes/modules/create_account.php
3. includes/templates/template_default/templates/tpl_account_edit_default.php
4. includes/templates/template_default/templates/tpl_contact_us_default.php
5. includes/templates/template_default/templates/tpl_modules_address_book_details.php
6. includes/templates/template_default/templates/tpl_modules_checkout_new_address.php
7. includes/templates/template_default/templates/tpl_modules_create_account.php
8. includes/language/english/contact_us.php

Files that I had to edit to update to 1.5.5e standard (still need to do some final reviews to be sure):

1. includes/languages/japanese.php
2. admin/includes/languages/japanese.php

I discovered that there is a way to do overrides on classes and functions using the autoload/init_includes system, worth looking into later:
https://stevenkohlmeyer.com/zen-cart...php-overrides/

As mentioned previously, application_top.php could be extended with a file in extra_configures/, the language translation was completed (files not yet attached, sorry about that - will do once I have better-reviewed the two japanese.php files above), the buttons for the Japanese language are the same as in 1.5.1-JP so they could be copied across, and the DB modifications needed for the logic in the above core files are attached in previous posts (or one can get the bare bones from the Japanese 1.5.1-jp locaization SQL).

In the next few days, providing I have not broken the system, and barring any advice to do things differently, I will try to test the behaviour of user registration and email sending as part of figuring out how best to handle the Japanese name order.

Furigana support is working in the admin screen at least, as shown in this screenshot.
First and last names are correctly displayed for the test user. I haven't confirmed that the code does the right thing with the fields, but at least in the database I have kept the definitions from being swapped.
Pretty happy to see this screen!
(Note: I purposesly did not translate most things in the admin section [yet])

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.

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:

Code:

---

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

---

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

Code:

---

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....tain-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.

Quote:

---

Originally Posted by gernot

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.

---

Instead of editing the includes/classes/order.php file, it contains several notify events that can be observed (back to that again) such that the data can be reviewed and if it is determined necessary to use the alternate method of query then replace that data.

For example there are notifiers in the cart function to be able to detect specific information about the product, the attributes, prepare to apply taxes and at the very end that the processing is complete. With ZC 1.5.3 and above, there are several options made available when a notifier has additional parameters attached to it. You would be able at any of those notifiers to modify the classes delivery data to suit whatever is needed. Again, this way the class file remains untouched and the data is processed/groomed to support the need.

Hello,
Thank you for that reminder, yes, I had forgotten about the notifiers in the order.php class file!
I can try to move those changes to the notifiers later on, when I have everything working as I want (now I am working on the billing address, not sure what other parts I will need to adapt). BTW, the multilanguage country module also edited the order.php directly (well, the documentation asked me to edit it appropriately), so I should later check whether those changes too could have been done with notifiers instead.

Progress report: I have managed to integrate language choice into the create_account module and tpl_modules_create_account, currently on the login page (which pulls in the JavaScript for pages/login). It took quite a while to get the JavaScript to run properly, switching between English and Japanese language choices for the new address (while the site itself might be viewed at the time independently either in Japanese or English).
I found that there are a few bugs in the JavaScript that make themselves apparent occasionally. In particular, the hideStateField and showStateField functions work on a couple of IDs, not all of which are present in the page in question. For example, 'stText' is in the shipping estimator template but not in the login page / create_account template. This seems to break the execution of JavaScript code manipulating the select items.
I have commented out the show/hide commands relating to 'stText' for now, but if the same JavaScript is to be used for convenience in every page, then probably a test for the existence of the ID is needed to make the commands conditional.

Anyhow, the result of the above is that for a new address, the address language can be chosen as either English or Japanese, and the country and zone pulldowns change language correspondingly (they do not necessarily need this as the country and zone code is used in the address saving, but it makes for a better user experience). Additionally, if a zone has already been selected, and only the address language is changed, the zone remains selected.
The screenshots attached show the site being viewed in Japanese, and the address language being selected independently.

It has been a while, I am still working on completing documentation for a Japanese localization module, but had been stuck on the general Payment and Shipping modules. After getting through the Paypal stuff OK, I was trying to update the Japanese postage modules and ran into trouble in that I could not figure out where the modules get their dimensional information from.
There are 3 modules in the officially-released 1.5.1 Japanese version, which can be obtained for example here:
https://ja.osdn.net/projects/zencart-jp/releases/57699
They are for Yamato, Sagawa, and Nittsu (which has been supplanted by Japanese Post Office, so I just kept it for now to experiment), I updated prices to 2018, and modified the logic to handle a new cost calculation, that for "inside a prefecture" as compared to "inside a region of multiple prefectures" which is the usual logic.
Apart from the language files, the functionality is in
includes/modules/shipping/{yamato,nittsu,sagawaex,nittsu}.php <- module setup logic
includes/classes/_{yamato,nittsu,sagawaex}.php <- calculation logic
While the modules are available, and function when activated, they calculate that the dimensions are out of bounds, since there are no product dimensions currently in the products table.
The problem is, I don't see any MySQL ALTER TABLE commands anywhere in the Japanese Zen Cart package (either in zc_install or in the module, like the Canada Post module does for example), nor even a use for the SetSize function in the class.
I guess I will have to try and actually install Japanese Zen Cart somewhere and examine it, since the functionality has been there since 1.3.8 or so, apparently.

Good news. After spending some days figuring out which version of Ubuntu has the right combination of permitted PHP, MySQL, and openssl to pass pre-installation tests, turns out Ubuntu 12.04 LTS fits the bill. One VMware installation later, and 1.5.1 Japanese was installed, and shipping modules checked.
The great news is that the Japanese shipping modules work, and that the size is not currently passed, only the weight, which can be calculated from the products table entries for an order. However, the size calculation code is there, so that if the module passes length, width and height for a parcel, one can get the correct quote.
The trick of course now is twofold:
(1) adding length, width and height to the products_table. That is the easy part.
(2) finding a way to estimate parcel size(s) for an order. For that I will try to see what the Canada Post module has for this purpose.

The existing order module already calculates multiple boxes depending on weight. It remains to be seen how difficult it would be to extend that logic to handle per-product sizes. I cannot see myself writing any smart optimization lowest cost algorithm to go through permutations to find minima for weight and sizes together. Probably just go with biggest size, and then fill to the largest weight permitted by those size constraints, then to the next box.

Now that the modules are shown to be workable, I plan to do something about the configuration options, which are hard-coded into the module files, instead of using language-dependent constants. That will be part of the translation package.

Bah, mid-typhoon blackout in Tokyo destroyed my carefully-crafted message. Rough one now :-)
Canada Post module only sends list of item weights & dimensions, actual CP website has the 4D dimensional weight algorithm.
Some open-source libraries exist, e.g., pyShipping, 3dbpp, php-lapp.
So modules currently only handle weight, but work (SetSize function) if dimension parameters are given too.
And libraries would have to be called, probably in the order module, and heuristics used to reduce complexity (in my case, bottles of wines makes both writing an algorithm and heuristics fairly straight-forward).
So on two localization:
(1) take out configuration strings into language-dependent files;
(2) change the zone names to zone IDs (currently the zones are written in Japanese).
That is it for now.

I've attached the updated Japanese postage classes for Yamato, Sagawa, and Yupack (still named as _nittsu.php), for the October 2019 price changes.
The major changes apart from the prices themselves, is the expanded use of weight and volume; and for Sagawa, the addition of oversize items, the variation in which greatly increases the total number of rows in the table.
Attachment 18695