EasyPopulate 4.0 Support Thread

[mc12345678]

Sorry, ':products_model:'[LEFT][COLOR=#222222][/COLOR][/LEFT] had become a face mark.

It had done the same thing to me as well. :)

Ok, so I haven't reproduced the issue yet. I need to figure out how the installed version is/was 4.0.37.6, but from chaddro's distribution...

I do see that at least from the GitHub location I posted, as long as the exported file has v_products_model as a field, then it should do the substitution that seems to be missing.

Another question: in configuration->EasyPopulate V4, What is the setting for EP4_DB_FILTER_KEY? This is the setting that identifies whether to use products_model, products_id or new_blank as a setting.

Does the issue still occur if the default language is returned to English, but the language pack is installed?

[hanachi]

1.About the version of EP4:
I downloaded EP4 from https://github.com/mc12345678/EasyPopulate-4.0 and verified with former installed EP4 that occured the error.
I found they are same 4.0.37.6 of EP4.
I remember I got an error by using EP4 v4.0.35.ZC.2 and I found EP4 at https://github.com/mc12345678/EasyPopulate-4.0, so I
tried EP4 4.0.37.6, because it is later than EP4 v4.0.35.ZC.2.

2.About Another question:
in configuration->EasyPopulate V4->Import/Export Primary Key .... value is products_model
And I confirmed EP4_DB_FILTER_KEY is set products_model at the database "configuration".

3.Does the issue still occur if the default language is returned to English, but the language pack is installed?
Yes. I tried to set the default language to English without remove Japanese language Pack.
There is same error occured.

4.I delete Japanese from Localization -> Languages and tested , but the language pack is removed.
There is no error occured!!
About the Japanese language Pack, there are no SQL query included.
The Japanese language Pack only include language folder, email folder, and template(only buttons images).

5.I delete Japanese from Localization -> Languages and tested , but the language pack is installed.(I put the Japanese language Pack again)
There is no error occured!!

I think there is some conflict when add new language at Localization -> Languages

Thank you.

[mc12345678]

Sounds like some good investigation.

To ensure that the issue appears "corrected", the new languages_id for Japanese though now is 3 correct?

In the additional testing, was a new export file created after reinstalling the language pack? And do the fields of the japanese language have the current/new languages_id?

Before, English was 1 and japanese was 2. Because japanese was removed and then readded, I would expect japanese to now be 3.

If the problem continues with a new export/import, I will take a look at duplicating the issue even though I can't read Japanese. I took some lessons many years ago, but that was conversational not "business".

[hanachi]

1.About the new languages_id for Japanese
Yes, Absolutely 3.

2.Latest testing
After readded new language "Japanese" from Localization -> Languages, I made a new export and import.
No error occured!!


I still not have perform another testing, but seems to be able to avoid the error.
I can't understand there is what kind of difference between languages_id 2 and 3.
Any way I will continue test and report to you here.

You already have advanced programming skills and sense of responsibility, just add a bit "love of Japanese", I think it's not difficult to use Japanese in business.

Thank you

[hanachi]

The error still occur when CSV file include Japanese.

When I export CSV file include Japanese at Tools->EasyPopulate 4,
Bottom of the table, there displayed File Name, Size,Date & Time,Type etc.
Type of exported file displayed "CSV Unknown Delimiter".
If the exported CSV file doesn't include Japanese then displayed "CSV ,".

When I import CSV file include Japanese then error occur,
and if it doesn't include Japanese then no error occur.

Does it relate to parse a csv file include Japanese ?
Does it relate encoding Japanese ?

My php.ini has the following two lines.
"mbstring.language = Japanese".
"mbstring.internal_encoding = UTF-8".

[mc12345678]

May recommend that in the configuration settings that you try a different export delimiter? Then export again with Japanese.

It appears that the default comma is selected which is what a CSV file (Comma Separated Values file) should have. There has been some extra code added to attempt to identify the separator in the file to support easier import; however, if the delimiter (separator) is not consistent or appears to be different between rows, then the import will also not work.

Put another way, prior to trying to import a file, a small test is performed against the file to see if overall it is likely to be able to be processed. Exporting a file with a delimiter other than a comma may provide different results.

I'm not yet sure if the php.ini settings are an issue or not. Provided those settings are acceptable for php, then I don't think they are a problem.

Though not specifically stated, it does seem that the same process as before has been used: export data, attempt to import the unmodified data. If I am wrong there, please say so.