2.0 - update from 1.4 about multilingual_field HOT 11 CLOSED

Why does it try to select from CACHE?

SELECT SQL_CACHE field_id FROM sym_fields_multilingual_textbox

... Bummer :(

from multilingual_field.

Let's post the issues for 2.0 on the issue tracker from my fork until the thing is stable and changes are merged here.

from multilingual_field.

This commit should fix it. Can you confirm it is working?

from multilingual_field.

@vlad-ghita Sorry but it's even worst, worst being that the error message is bigger !

BTW, I just used your lastest version from your master branch.

MySQL Error (1054): Unknown column 'unique_handle' in 'sym_fields_multilingual_textbox' in query "ALTER TABLE sym_fields_multilingual_textbox CHANGE formatter text_formatter VARCHAR(255) CHARACTER SET utf8 COLLATE utf8_unicode_ci NULL DEFAULT NULL, CHANGE unique_handle text_handle ENUM('yes', 'no') CHARACTER SET utf8 COLLATE utf8_unicode_ci NULL DEFAULT 'yes', CHANGE use_def_lang_vals def_ref_lang ENUM('yes', 'no') CHARACTER SET utf8 COLLATE utf8_unicode_ci NULL DEFAULT 'no', MODIFY text_validator VARCHAR(255) CHARACTER SET utf8 COLLATE utf8_unicode_ci DEFAULT NULL, MODIFY text_size ENUM('single', 'small', 'medium', 'large', 'huge') CHARACTER SET utf8 COLLATE utf8_unicode_ci DEFAULT 'medium', ADD text_cdata ENUM('yes', 'no') CHARACTER SET utf8 COLLATE utf8_unicode_ci NOT NULL DEFAULT 'no';"

If the issue #26 could be fixed I could wait for a more stable release of the field.

BTW, I loggued other bugs in your fork. See #1

from multilingual_field.

Regarding #26, I worked on a fresh install of this as well (1.4). Then upgraded to 2.0. Worked perfect.

The above error appears because there's a conflict between the number version of your extension and the actual data in the system.

In your case ... it would be great If you could revert everything to the state before trying to upgrade.

What version does the extension say you have installed? 1.4? 1.4.1? My hunch is that you have a version installed but not with the required modifications, so make them manually.

If 1.4, you must make sure column unique_handle ENUM('yes','no') DEFAULT 'yes' exists in tbl_fields_multilingual. If it doesn't, add it manually. Upgrade to 2.0.

If 1.4.1, you must make sure use_def_lang_vals ENUM('yes','no') DEFAULT 'yes' exists in tbl_fields_multilingual. If it doesn't, add it manually. Upgrade to 2.0.

from multilingual_field.

This can be closed as well since #26 is solved.

from multilingual_field.

Now that I can execute 1.4.1 successfully, I stay with it !
Thanks for all your help.

Finally, I have a question: If I have a mandatory field, but I used the option 'used the default text' enabled, ALL laguage must be filled. Shouldn't it be ok if the user only fills the default language ?

from multilingual_field.

Finally, I have a question: If I have a mandatory field, but I used the option 'used the default text' enabled, ALL laguage must be filled. Shouldn't it be ok if the user only fills the default language ?

Not really. If this is enabled, used the default text the default value will be returned if the value for current language is missing.

If you marked the field as required, then the user must supply data for all languages.

from multilingual_field.

Would you consider adding an option for making my scenario possible ? Like Require only default language ?

I may code it in my fork since this is something I would really be glad to have. It happens often that the translated text is entered later in the development process and this would prevent having to copy-paste texts across language.

If you think that this do not fit into your extensions, I'll leave it into mine. If you want to have this, I would be glad to send a pull request.

Thanks again.

from multilingual_field.

required == checked => the field is required => all languages will be filled (theoretically). def_ref_lang is irrelevant. The fields must be filled.

required != checked && def_ref_lang == checked => optional field and will default to def_ref_lang.

For dev purposes, it is a problem indeed with copy+paste. Why don't you simply put a dot . or something?

from multilingual_field.

We copy/paste because the dot . won't give a good idea to the client about the final layout.

Also, putting only a dot requires the user to click on the language tab for each field, which is a loss of productivity and usability.

As I said, if you do not want this feature, I'll keep it in my fork. I can sense that even after developement, this could still be usefull as some of my clients would like to have this in production.

from multilingual_field.