I test migration (since so long); know with new i18n version.
How to get automatically translation still existing in D6 for list text value?
I see that we can translate for each field when managing content type, but system has already that translation (I can check that in admin/config/regional/translate/translate).
But in content type, field translation, that traduction does not appear, I have the default language text (French is my default language).
I also ajusted the "default translated" value in display tab of that content type.
Thinking perhaps it's needs a refresh, I go to admin/config/regional/translate/i18n_string and active refresh for fields.
I get that error :
An AJAX HTTP error occurred. HTTP Result Code: 200 Debugging information follows. Path: /cms/mdbMig540/batch?id=33&op=do StatusText: OK ResponseText: Fatal error: Cannot use string offset as an array in C:\Program Files (x86)\EasyPHP-5.3.8.1\www\cms\mdbMig540\sites\all\modules\i18n\i18n_field\i18n_field.inc on line 148
I also respected the upgrading sequence mentionned in http://drupal.org/node/1113358
Comment | File | Size | Author |
---|---|---|---|
#4 | migrate_field_allowed_values-1431104-4.patch | 1.26 KB | amirkdv |
Comments
Comment #1
sahuni CreditAttribution: sahuni commentedI'm nearly ready for my migration, but 2 or 3 problems.
Select list values not heritating translated values from D6 is one.
Do you suggest I translate again that values in D7 for me not to be blocked?
Comment #2
Jose Reyero CreditAttribution: Jose Reyero commentedThese are different translations, not using locale t(), I'm afraid you'll need to retranslate those terms.
Comment #3
dergachev CreditAttribution: dergachev commentedWe just ran did another D6 -> D7 upgrade with i18n, and ran into this bug for the second time.
After enabling i18n_menu, we "lost" all the #allowed_value translations. Here's a diagnostic SQL query:
We have a patch that seems to work for us, and will upload it shortly.
Comment #4
amirkdv CreditAttribution: amirkdv commentedThis patch should do the job. The problem, AFAIU, is that in 6.x,
i18ncck
doesnot store the 'property' column with the content type prefix, e.g.
course-field_course_number
, see http://drupalcode.org/project/i18n.git/blob/refs/heads/6.x-1.x:/i18ncck/....Consequently, the parsing logic in
i18n_field_update_7000()
migrates allowedvalues incorrectly. In the following, I include the output of a specific query
joining data from the relevant tables:
i18n_string
(already renamed fromi18n_strings
byi18n_string.install
),locales_source
, andlocales_target
. Thequery is:
1. before enabling i18n_field the query results in:
2. without the patch,
i18n_field_update_7000()
generates the following:which is clearly broken (see objectid, property, type, location and context).
3. With the given patch, we get the following:
Comment #5
amirkdv CreditAttribution: amirkdv commented