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.
The title is pretty much self explanatory. I have a Dutch Drupal 7 site with a content type containing translated fields. After upgrading to 7.2 these Dutch fields switched back to English for some reason.
This can't be working as designed or can it? Anybody out there for support?
Comments
Comment #1
plachThis is not so obvious as you are supposing it to be, it's a behavior never observed before so something weird must be going on. Would you please provide some more information on your setup? Languages installed, languages enabled, language negotiation settings, language-related contrib modules installed, and anything else you think might give a clue of what is happening.
Comment #2
nieuwkar CreditAttribution: nieuwkar commentedSure, I'll try to be as precise as possible. I have two languages enabled which are Dutch and English. Dutch is the default language. The negotiation settings are set to use the default language (Dutch) and the only language related modules I´ve installed are the locale (core) module, the localization client module and the localization update module.
I had given the fields English labels which I'd translated into Dutch. The only odd thing I see is that the content translation module is not necessary to translate content.
Comment #3
plachOk, now I understand your issue: you were talking about field labels. The t() calls that allowed strings to be (incorrectly) translated have been removed. See #1157426: Field system uses t() incorrectly and inconsistently.
Comment #4
nieuwkar CreditAttribution: nieuwkar commentedMmm ok thank you for your quick response.
So how do you suggest to translate these labels? use a field template? This also implicates that core themes have to be updated doesn't it?
Comment #5
plachAs stated in the other issue the solution is the 18n_field submodule shipped with the i18n package.
Comment #6
nieuwkar CreditAttribution: nieuwkar commentedRight, sorry for that.
Comment #7
mediameriquat CreditAttribution: mediameriquat commentedHello,
This issue shouldn't be fixed yet. I have the same problem, which seems to have popped up right after the Drupal 7.2 upgrade. My site is "live" and is hosted on an Aegir account so it is not really possible to patch i18n or revert back to Drupal 7.0.
For instance, I have a field called "Role" in a content type called "Profile". The string is :
field:field_role:profile:label
The English original label "Role or Position" used to be correctly translated to "Rôle ou fonction" in French. Now the English label appears both in the French node AND the node edit form, although the translation is still OK in the database.
Language negotiation is set to url (en/node-title, fr/node-title)
I should add that views-related strings (such as block titles, etc.) are OK. The problem, as far as I know, happens on the default Drupal node display.
Comment #8
plach@paradiso:
This is unfortunate but, as stated above, this cannot be fixed in core, it was an error to let field labels be translated through
t()
. As a temporary measure until this is fully addressed by i18n_field you can pass your field labels throught()
in the theming layer.Comment #9
plachComment #10
plachI guess this is fixed.
Comment #11
Mamouri CreditAttribution: Mamouri commentedI have the same problem. After upgrading to Drupal 7.2 fields titles are not translated anymore. Can you please tell me is this a bug which will solve in say 7.3 or it's a permanent things.
I did not found i18n_field submodule in i18n moudle
Comment #12
plachThis is a permanent thing. The i18n_field is a submodule of the 7.x version of i18n:
http://drupalcode.org/project/i18n.git/tree/90b6d77ae1f62e05dd00cf8fcfc9...
Comment #13
j0nathan CreditAttribution: j0nathan commentedSubscribing to this issue and #1157512: Labels are not translated with i18n_field for Drupal core..
Comment #14
webchickI've added this to the 7.2 release notes since this seems to be a common support request.
A new release of i18n module would really help people who come across this. In retrospect, I should've waited until that was done before committing this patch. :(
Comment #15
plach@webchick:
We've done this exactly because i18n_field could not go on without t() calls being removed.
Comment #16
BoobaaOK, i18n-7.x-1.0-beta7 seems to be the solution. @see #1157512: Labels are not translated with i18n_field for Drupal core.
Comment #17
bartl CreditAttribution: bartl commentedI've had the same problem, last week, and after upgrading from 7.2 beta 6 to beta 7, it looks like it's mostly fixed. But not completely.
In particular: the word "Title" still appears in English, as do the labels for date fields (associated with the Date module) which are rendered translated in view mode, but not in edit mode.
In the attachments, see 2 cropped screenshots of the same record. Note that "Date of first use" and "Date of registration" appear in English in edit mode, and in view mode, in Dutch as "Datum van ingebruikname" and "Datum van inschrijving" respectively.
BTW I just noticed that the date format is wrong, too: it uses the format for English instead of the format for Dutch as it should. I'm pretty sure this worked as intended last week. I don't know if this is just an unexplainable glitch (as often happens in Drupal, unfortunately), or if it is related to the upgrade to beta7.
update Deleting the date format for English, under "Localize date formats" (q=admin/config/regional/date-time/locale/en/edit), so it reverts to the system default, which is "dd/mm/yyyy", makes it appear as it should in Dutch. So it really does use the format for English. In Dutch.
Comment #18
Gábor HojtsyBartl: please follow up in the i18n module issue queue. Read up what people have experienced in #1157512: Labels are not translated with i18n_field for Drupal core. and if related post there. If unrelated but connected to field property translation, please open an i18n module issue.
Comment #20
yched CreditAttribution: yched commentedAnother field property that gets run through t() : #1220964: Number field prefix/suffix get t()'ed through format_plural().
Feedback from i10n / i18n folks welcome :-)
[edit : oops, I means that for #1157426: Field system uses t() incorrectly and inconsistently. Well, works here too...]
Comment #21
bartl CreditAttribution: bartl commentedWell, after updates to newer versions of Drupal and of several modules, the problem fixed itself, without me doing anything else. I don't know which upgrade fixed it, but it's nice that it did.
Comment #22
mediameriquat CreditAttribution: mediameriquat commentedThe problem persists on Drupal 7.8, i18n-7.x-1.0 (stable) with i18n_field properly activated, and field labels properly translated in the database.
Just can't get the translated field labels to show in the French node edit form and the nodes themselves.
There must be a way to fix sites that were set up before that very annoying 7.2 core upgrade. Things work fine with a fresh Drupal install, so I guess something's screwed in my DB.
Comment #23
Gábor Hojtsy@paradiso: Do you see those translations when you go to the "Translation" tab on the field's configuration screen?
Comment #24
mediameriquat CreditAttribution: mediameriquat commented@gabor : yes, I do.
Comment #25
Gábor Hojtsy@paradiso: ok, that service is provided by the i18n module, not Drupal core. If that is not working, this is an i18n module bug. You already seem to be on #1157512: Labels are not translated with i18n_field for Drupal core. which looks to be the i18n bug counterpart to this. Moving back to closed (fixed) as per the above.
Comment #26
jwilson3I've been thinking about this and cannot wrap my head around why field labels are even stored in the translation database, if the translations cannot be used to display the translated labels. Is it because my fields and content types are exported as features? I'm not honestly sure.
Anyway, I don't want or need to download i18n, install i18n_fields and all its dependencies *just* to get translated field labels.
This seems to me to be like the one single element that keeps you from cleanly running a simple non-english site without needing the i18n module, where content types in code are defined in English, and translated in the database.
So below, I've created two functions that add translatability back to Drupal: one for the front end via a hook_preprocess_field() to translate the field label (if present), and one for the backend, to translate the field labels and descriptions on the node edit form.
Use at your own risk, as this is currently considered the WRONG way to translate "user-entered" strings (even if those strings are in code, from fields created by features).
Comment #27
mohammadjolani CreditAttribution: mohammadjolani commentedThanks for all and specially fo jwilson3
I altered the code above to accept all types of fields
see my code below.
Comment #28
zuernBernhard CreditAttribution: zuernBernhard commentedSo that is still not in the Module Code on Drupal.org ? I'm on the latest DEV-Release for Drupal 7. But I also had to write my own form_alter to get translatet field labels :(
Comment #29
RAWDESK CreditAttribution: RAWDESK for Colruyt Group Services commented2018 and it's still an issues on 7.58
I have added 4 custom fields to admin/config/people/accounts/fields
with an English label on a Dutch default language site.
In my via Features exported DS settings ( myfeature.features.field_instance.inc ), I am locating this :
where label 'Last name' is not wrapped by t() function.
Setting this wrapping translation and reverting the feature did not solve the issue on our case.
Instead, I also had to implement a hook_form_alter() as shown below :
Each field type (text, date, select) has his own way of rendering a label or #title in this hook implementation making it time consuming to find the right translation override.
That said, I hope Drupal 8 will bring more relieve in overall translation transparancy.