I am trying to figure out why 'i18n menu' export and then import doesn't work

Let's say I have an english and italian versions.

I create a new menu and add couple of menu items with 'All languages' option on.

#1
Have the menu in a block sitting in a header region
I revisit the Italian page example.com/it so locale knows about these strings
I can then edit these strings and it does work

in locale_sources table location field looks like:
'item:111:title'
'item:112:title'

#2 export/import
When I try to export menu items and then import (doesn't matter if I change it or not)
the location of locale_sources changes to:
' item:111:title'
' item:112:title'
note that space in front of item
so if I revisit italian page (/it) the menu item strings are generated again and in locale_sources it looks like:
'item:111:title'
'item:112:title'
' item:111:title'
' item:112:title'
and obviously the translation doesn't work

And if I edit .po file directly, and remove one space from '#: item:112:title' so it looks like: '#:item:112:title' then it does work

This is as far as I could get with my limited knowledge of locale module.

Comments

sign’s picture

Status: Active » Closed (duplicate)
yarimbiyik’s picture

Status: Closed (duplicate) » Active

Not all problems with i18n menu translation import are limited with this "blank space problem".
I added a few lines which get called at the end of import submit to get rid of that
extra blank space but it did not help with the (menu) import problem I will explain below.
The thing is; at a given time only one of the (same source name)
translations is active at a given time. For instance, at my site Latest Activity at the personal
dashboard is Item 1003 in the po files. It may or may not be the one saved
in the db at the first import. If it is not saved then 1347 (which corresponds to another menu item with the same name) is the one that is saved. Of course at this situation Latest Activity at the Personal Dashboard is not translated. And the worst thing is with consecutive imports. It is not a single rewrite to the db field at these situations. The list expands, but it is only the
last one that is actively used; that is to say you may have all the
translations for 1003 and 1347 perfectly lined up in the db, but none or
part of these is/are active because either the latest one saved has NULLs
all over or just one of the 1003 or 1347. I may not have been clear enough in explaining the problems I see with imports, but given the variety of different scenarios you can get, it is not an easy thing to do. I think the maintainers who have the most information on the module should have a careful look at menu import problems.

yarimbiyik’s picture

The issue is better put at: http://drupal.org/node/422640 .

deverman’s picture

I am having a similar problem and I posted here:

http://drupal.org/node/429822

Is there a solution?

Jose Reyero’s picture

Status: Active » Closed (duplicate)

Follow on the linked issues.

deverman’s picture

I haven't found a solution on any of the linked issue am I missing something?

strellman’s picture

Version: 6.x-1.0 » 6.x-1.x-dev

Here is what you need to do. Get http://drupal.org/project/translation_table and put in your translations online. To fix your existing data do a /admin/build/translate/refresh which wipes out your translations for a specific area. It sounded like there was a plan for translation table to delete things from the table where the translation is null, but that didn’t happen in the dev version.

To be sure it wasn’t fixed yet I got http://ftp.drupal.org/files/projects/i18n-6.x-1.x-dev.tar.gz as of this date. Notice that the official release is January 25th, about 4 months ago. This dev version still seems to duplicate on import of taxonomy. At least with translation_table you can see what is happening.

deverman’s picture

Thanks for this information. I had my staff create custom routine to look up the new translation and copy it to the old translation.

yarimbiyik’s picture

Any updates/fixes on this issue?

yarimbiyik’s picture

Status: Closed (duplicate) » Active
yarimbiyik’s picture

Preceding white space is not the source of this problem.

Jose Reyero’s picture

Status: Active » Closed (fixed)

@deverman (et al)

If you don't find a solution in the linked issues, then follow up there. I just mean the is taken care of *somewhere else*