Translators were complaining that they would use the localization client, but nothing would change on the page. Upon investigation I find that searching for those strings returns multiple translation versions of the same string, some translated in one language, some in another. So in a test account I found that i10n_client is creating strings in the "Built in interface" text group while the string refresh function, translation_table, and perhaps others are creating strings in "CCK", "Content type", or other text groups. In our site with 8 languages I am finding that we may have 5 different versions of the same original text depending on who translated it how and when. We are using D6.19 and all multilingual modules are current on a new website. Attaching string search image.
Any help on how to begin cleaning up this mess would be appreciated!
| Comment | File | Size | Author |
|---|---|---|---|
| #9 | textgroup-class.patch | 2.2 KB | gábor hojtsy |
| #1 | translate-2.jpg | 217.72 KB | strellman |
| translate-search.jpg | 246.27 KB | strellman |
Comments
Comment #1
strellman commentedAttaching a 2nd screen shot of duplicated translation strings
This may be related to issue http://drupal.org/node/361147 but I don't know enough about that issue.
Comment #2
gábor hojtsyThe 1.8 version introduced proper support for different textgroups on saving strings. Are you sure you are using this version?
Comment #3
strellman commentedYes Gabor I was.
Comment #4
gábor hojtsyOk, well, l10n_client does not in fact save source strings if they are not yet in the database, so what we are seeing here is rather some module or theme using t() for a non-default textgroup string. I think your modules and themes need an audit of use of t() for strings which actually come from custom textgroups.
Comment #5
strellman commentedGabor, I guess I don't understand your answer. When I use the localization client to translate a CCK field or it's help, a new source string entry is saved (see jpg), only it is identified differently, so it isn't used or it causes other translations not to be used.
Are you saying that you don't intend this module to translate CCK fields?
Have you tried using multiple methods to translate CCK fields and seen the difference?
Point me to a test site with CCK, Localization client, and Translation table and I can show you the problem.
Comment #6
gábor hojtsyFeel free to set up a test site, if you'd like to show the problem, thanks! The localization client can work with arbitrary textgroups in its latest release, and it will not save source strings in any case. It is the job of the module providing the string UI to save that source string. Localization client saves translations for pre-existing source strings.
Comment #7
strellman commentedWell maybe the problem is with the i18n submodule for CCK fields, I'm not sure. Sorry if I am not describing the problem correctly. How can I get you to the test site without posting all the login info here?
Comment #8
travismccauley commentedHi strellman, You should be able to email Gábor using his d.o contact page: http://drupal.org/user/4166/contact
Comment #9
gábor hojtsyHere is a patch you can try (or just update to the 6.x-2.x version of the module where I'm committing it). We've seen people having issues with IDs because other modules used elements with similar IDs on the page (such as maybe translation_table module). I'm also looking into fulfilling my thinking in #4, that l10n_client itself should not create new strings, which is not yet the case as I'm looking at the code.
Please reopen this issue if moving to a fresh Drupal 6.x-2.x checkout of the module or applying this patch did not fix the issue for future translation submissions.
Comment #10
gábor hojtsyLook at #992444: only save translation for existing strings, require textgroup, which is also now committed on the Drupal 6.x-2.x branch. I think these two patches should solve your problems. Feedback welcome.