Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.I have both l10n update and i18n string modules enabled. i18n string does a menu alter and replaces the normal translate page with a custom page.
l10n update then does a form alter on locale_translate_edit_form but this form isn't used anymore as it is called i18n_string_locale_translate_edit_form now.
i18n string does call: locale_translate_edit_form_submit but doesn't call l10n_update_locale_translate_edit_form_submit.
I'm a bit puzzled whether this is a bug in i18n string or that it is a feature request for l10n update. Because I think it's quite strange that i18n string does a menu alter. Perhaps a form alter would've been better in this case, because then other modules relying on core functionality don't need to be changed.
Anyway now l10n update is unable to set the l10n_status in the database which then causes the custom translations to always be marked as default translations. When you do a l10n update of a module where you made custom translations, all your custom translations will be overwritten.
| Comment | File | Size | Author |
|---|---|---|---|
| #1 | l10n_update-18n_string-edit-translation-2201931-1.patch | 3.27 KB | Sutharsan |
Comments
Comment #1
Sutharsan CreditAttribution: Sutharsan commentedThanks for reporting. Attached patch is committed.
Comment #3
shadysamir CreditAttribution: shadysamir as a volunteer commentedThis issue appears again in 7.x-2.x
None of the i18n translated strings have their l10n_status value set to L10N_UPDATE_STRING_CUSTOM
Comment #4
geek-merlinIf that's the case i'd say it's a bug.
It can severely affect translation workflows (see features_translations code that depends on this) causing data loss so setting major.
(Did not check though.)
Comment #5
geek-merlin> None of the i18n translated strings have their l10n_status value set to L10N_UPDATE_STRING_CUSTOM
aah i get it. all strings translated in other places than the translation page (i18n offers other translation forms) can not get that flag.
which is no problem as this flag is only important for the default textgroup (at least concerning translation deployment).
you may be interested in this patch: #2698381: I18n translations lost (if not added on main translation page)
so i'd suggest
* if the problem persists for default textgroup, then bug
* if not, then works-as-designed
Comment #6
Sutharsan CreditAttribution: Sutharsan commentedNo activity, closing the issue.