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

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