translations not being saved

same here

What browser(s) are you trying with?

Ok, we've had reports of saving not working in Opera due to HTML uppercasing (http://drupal.org/node/264230). Anyway, can you please try and update to the latest version, which fixes possible HTML invalidity/unescaping issues. The difference between the two sites is either the data shown or the modules you use.

same problem for me with FF 3 Linux

I have tried in several other browsers and get the same issue - I don't think it's browser related.

1. I type in the string I want to translate
2. I locate it from the list on the left
3. I click on it
4. I type my translation on the right
5 .I press save
6. The row on the left gets highlighted in green - AND the original string disappears
7. The translated string disappears from the right
8. I am now unable to locate the originals string on the left without refreshing the page.

Note: at step 6 - In firefox, I get left with an empty green row, about 4 pixels high... In IE I get a full height empty green row.

I have noticed this issue for profile fields only, other content can be translated using the localization client.

@thelostboy
Not just profile - i'm getting it now on menu translations, FF3 browser

Some context and what I've discovered during debugging: (Bare with me because up to now I'd never looked at this code)

In my case, I am attempting to translate the contents of a block that has been configured to be Any Language (Translatable).
I tried using the localization client and saw what was reported in #8 with no translation (apparently) being saved.

I then also tried translating the same block contents via the traditional built in translation interface. Doing so works.
I made note of the 'lid' when I translated via the old interface.

I then tried the localization client again, but this time I traced the code in my debugger when I submitted the form.
As I trace through the code, I see that it in fact does save the translation (and there are records in both the source and target tables)
BUT what was saved was saved using an entirely different 'lid' than the one used when I translated via the other method.

So on closer examination _locale_import_one_string_db determined the lid by looking for 'source' with a textgroup = default (and not textgroup = 'block').
This explains why something gets saved, but doesn't have the same 'lid'. And ultimately why it appears as those the saving doesn't work.

So I back traced to see where 'textgroup' was set. (i18nstrings_save_string())
It is supposed to be determined by a value posted with the form, but there was no 'textgroup' field that was submitted (not an empty value - the field simply wasn't posted)
The code then simply defaults the value of 'textgroup' to 'default'.

I haven't yet looked at how the forms are built so I can't say with certainty if this is a bug or by design. i.e. I'm not sure if the form is supposed to have 'textgroup' set or not.

I will investigate further and see what I can find, but maybe this will help someone move this issue forward.

Took a bit more of a look and this problem can start to be traced back to
i18nstrings_tt function which is partially responsible for the population of strings that show up in the localization client.

It attempts to give the localization client the source, translation AND the 'textgroup', but localization client's l10_client_add_string_to_page function only takes the first two arguments.
THEREFORE localization client will never know what the textgroup is supposed to be and therefore will never be able to set it as part of the form and certainly won't be able to submit it either.

Long story short, this is in part a shortcoming of the localization client but ultimately a problem with i18nstrings.module and its communication with the localization client.

Ok, looks like we need to fix it in l10n_client. Can you share a patch? :)

I will most certainly start crafting a patch once I fully grok the interactions of these modules.

It will likely require patching both modules. It will also require writing some javascript that doesn't exist yet to make this all work.

I will keep you posted.

Any news regarding this issue?

Any news?

Sorry,

Any news on fix on this. It does not seem to update for me either...

Thanks.

Not working for me either. Patch on the way?

Thanks!

Subscribing

Since this is related to textgroups not being supported, I think it's a duplicate of #361147: Support for different text groups.

I just got the problem exactly as described in #8, then I got this:

Die ausgewählte Datei /var/www/climateimc.org/httpdocs/sites/default/files/temp/fileDak7JR konnte nicht hochgeladen werden, da das Ziel sites/default/files/languages/de_3dded401833684b004768dba74fc062e.js nicht richtig konfiguriert ist.

Which in English is

The selected file / var/www/climateimc.org/httpdocs/sites/default/files/temp/file0dFejK could not be uploaded, because the target sites/default/files/languages/de_3dded401833684b004768dba74fc062e.js is not configured properly.

or something

@naught101 This looks like a Drupal file system configuration problem where the file system for JS translation caching is not set properly. This is a core configuration issue and unrelated to l10n_client.

I am having this problem I was using 6.x-1.8 and tried updating to dev version but nothing i do can get a translation to save. It is a block text I am trying to translate.

I am thinking another translation module is interfering with this. Is it designed to work alongside other modules like translation table or is it bad to use both maybe?

@gsquirrel: as long as the other module uses textgroups (you can see in the built-in locale interface that there are textgroups for your blocks and other items), then it should work fine with l10n_client.