Hi,
I work on a multi-lingual site (Drupal 6.14), English by default, translated in French.
We took care of defining content types entirely in English then translating everything we needed in French. Especially for content types and their respective fields.
Everything used to work well but, one day, CCK field strings, that used to switch between English and French beforehand, only showed up in French, whatever the language selected is. I had a look in our database and found out all original english CCK strings got updated by their french translation. I mean, in the locales_source table, every string mentioned for the 'cck' textgroup is now in French (!) while it used to be in English. Strings in other text groups did not get modified and are still in English.
The translations for these CCK strings in the locales_target table are still present and valid (in French).
It really looks like a data corruption that happened after a refresh. We were about to finish the development of the site and just added a few additional translations for CCK strings when it happened.
Had someone the same experience ? Is it a known bug ? What could we do wrong ?
Thanks for your help.
Comments
Comment #1
ClearXS commentedDrupal is in English, period. People should never-ever translate the Drupal basics, because its an almost sure road to conflicts. Ofcourse one can have ADDITIONAL translation tables that never-ever affects the basic Drupal and modules English language. I want to run a multilingual site, NOT a Spanish site. I could make a new Drupal install in Spanish -as the site main purpose is in Spanish region- and bring over the many modules and database from a recent English install. But..? Database conflicts between translated items?
So it might be very wise -as you did- to install and setup everything in English and then have other language options additionally?
But still then, something like this CCK problem happens. Does Drupal lack proper multilingual programming guidelines/policy? If "lfarcy" hasn't made a mistake setting-up the additional language French, some basic multilingual programming rules might have been violated? My remarks are much more than this temporary error of a specific module: How proper is multilingual build in Drupal? How can that become even better?
Comment #2
jose reyero commentedMaybe a caching issue? Try disabling cache and see what happens.
Comment #3
lfarcy commentedJose,
Thx for your response.
I can temporarily disable the cache and see that it does not make the issue vanish.
As I stated before, English strings got updated by French strings in the database itself. And it happened again recently while we took care of resetting every content type with English labels a few weeks back.
We cannot afford to do that every 2 months. It really looks like Drupal updates the English strings in the database unvoluntarily.
Comment #4
aacraig commentedI'm having this trouble too. I have created a site entirely in English and am now translating into Italian.
The CCK field identified by field:uozap_event-field_start:widget_label does not even give the possibility of giving an Italian translation. There is the string value I put in the CCK field definition listed as "Original Language" and "English" as the only option for translation.
Comment #5
ylc208 commentedThis problem happened to me too.
What I found out was this kind of problem occurs when you configure CCK field in another language like French or Italian rather than your default language (English).
Just take a look its label when you configure a CCK field. If you are under another language, the translation is in the label text field rather than the original texts.
Once you save the configuration, the translation is saved as the CCK field label.
To solve this problem, try to type in the original texts again and save.
To avoid this problem, modify CCK fields in the default language setting.
Hope this helps.
Comment #6
rv0 commentedClearing the cache helped for me.
Comment #7
jose reyero commentedI think this problem is completely unrelated to i18n.
When you rebuild the content types, strings wrapped in t(), which I gess may be the case, are translated, and stored in the language of the current page request (when the cache rebuild happens). So you may end up with strings in the database in any of the languages.
This may be affected by deployment modules too, like features, which may cause a rebuild of all your content types and views under some circunstances.
To start with I think countent type exports or views exports shouldn't have their strings wrapped with 't'. Instead, you should be able to decide which language do you want to use for exporting them.
Moving to CCK.