Early Bird Registration for DrupalCon Portland 2024 is open! Register by 23:59 PST on 31 March 2024, to get $100 off your ticket.
After upgrading to 7.x-1.8 label for Integer and File field types is not translated.
Introduced by #1875282: Improve field translation by implementing hook_field_widget_form_alter()
Comment | File | Size | Author |
---|---|---|---|
#44 | 1904368-fix-i18n-field-43.patch | 8.6 KB | bojanz |
#35 | 1904368-fix-i18n-field-34.patch | 8.21 KB | bojanz |
#32 | i18n-field-label.patch | 6.19 KB | rutcreate |
#24 | fields_label_translation-1904368-24.patch | 5.91 KB | martins.bertins |
#21 | fields_label_translation-1904368-19.patch | 6.28 KB | pbuyle |
Comments
Comment #1
spiffl CreditAttribution: spiffl commentedThanks, that patch solved the issue for me.
Comment #2
mojiro CreditAttribution: mojiro commentedThis patch works correctly, but the same problems exists on entity reference fields that use drupal's autocomplete widget.
Comment #3
Georgique CreditAttribution: Georgique commentedOne more problem for file fields - description is not translated properly.
Comment #4
Georgique CreditAttribution: Georgique commentedComment #5
funature CreditAttribution: funature commentedI have this issue not just with File field type, but also with entityreference and geofield field types. After using this patch, the file field is ok now, but the others are still the same problem.
Comment #6
mojiro CreditAttribution: mojiro commentedI have noticed that multivalue entity reference are being translated correct.
Comment #7
funature CreditAttribution: funature commented@mojiro, you are right, if I set them to multi-value, not only entity reference fields but also the Geofields are translated correct.
Comment #8
pbuyle CreditAttribution: pbuyle commentedIn addition to the missing title for field type where the
$element
contains the actual widget element under the0
orvalue
, the attached patch also add translations ofr their descriptions. It also fixes translations oflist_boolean
fields' labels.Comment #9
mojiro CreditAttribution: mojiro commentedUnfortunately this patch did not work for entity reference fields where cardinality is 1.
I tried to figure out the diferences among text fields, entity reference fields with cardinality 1 and entity reference fields with cardinality -1 (unlimited), but nothing yet.
I have also upgraded i18n, entity, entity_reference and entity_translation to the latest dev versions but nothing yet.
By using these dev versions the first patch is not needed.
Comment #10
mojiro CreditAttribution: mojiro commentedI managed it to work! After applying the #8 patch, in file i18n_field/i18n_field.module
1st change
Find
if (empty($element['#entity']) && empty($element['value']['#entity']) && empty($element[0]['#entity'])) {
And Replace with
if (empty($element['#entity']) && empty($element['value']['#entity']) && empty($element[0]['#entity']) && empty($element['target_id']['#entity'])) {
2nd change
Find
Add after
3rd change
Find
Add after
Comment #11
attiks CreditAttribution: attiks commentedRerolled patch from #8 with remarks from #10
Still not working for field collections, but that's probably for an other issue
Comment #12
attiks CreditAttribution: attiks commentedFYI: issue for field collection table at #1914568: Table headers aren't translated on edit screen
Comment #13
attiks CreditAttribution: attiks commentedNew patch sets the title on the value as well.
Comment #15
attiks CreditAttribution: attiks commentedNext problem discovered, I have a label in English "car driver's name" with a translation to Japanese, but it didn't translate.
The problem is caused by the check
$element['value']['#title'] == $instance['label']
because $element['value']['#title'] already run through check_plain changing the'
to'
Comment #16
attiks CreditAttribution: attiks commentedSame problem exists for file fields
Comment #17
attiks CreditAttribution: attiks commentedSupport for file field added
Comment #18
attiks CreditAttribution: attiks commentedanother one, more check_plain added
Comment #19
pbuyle CreditAttribution: pbuyle commentedPatch in #18 works, but for image fields the additional instructions (file size, extensions, image size) are lost.
Comment #20
attiks CreditAttribution: attiks commentedFor files the only thing that happens is setting the
$element['#title']
, so not sure what you mean by lost?Are they there without the patch?
Comment #21
pbuyle CreditAttribution: pbuyle commentedSorry, I meant an image field:
Here is a patch to keep the additional instructions by replacing the original description with the translated one in $element[0]['#description']
For a file field's label,
$element['#title'] = $instance_current['label'];
is not the only thing to happen. The followingif()
conditions are still checked and the following block could alter$element[0]['value']['#title']
.Note: There is something wrong with all these
if()
condition to alter the right$element
child's properties. The key (either none,0
,'value'
or'target_id'
should be determined only once before altering the label and description.Comment #22
attiks CreditAttribution: attiks commentedThanks for fixing, the code looks indeed a bit funny, but I'm launching in 48 hours, so I changed what was there.
Comment #23
martins.bertins CreditAttribution: martins.bertins commentedUsed the patch from #21.
It removed the label for boolean type field (list_boolean) when using the field label instead of on value.
Comment #24
martins.bertins CreditAttribution: martins.bertins commentedUpdated the patch with fix for list_boolean field.
Comment #25
watchdog CreditAttribution: watchdog commentedNice! Patch in #24 works great so far, thanks
Comment #26
facine CreditAttribution: facine commented#24 works!
Thanks
Comment #27
danieldumbrava CreditAttribution: danieldumbrava commented#24 works, but if you have any special characters in the title of the field, check plain will replace them, so the condition won't be fulfilled and any field that has special chars in the title won't be translated any more. Is check_plain actually needed in the if condition?
Comment #28
mradcliffeInstead of only looking for an indexed form child, could the patch in #24 use element_children()? This is the best way of getting a form element's child keys. It also seems like #1964234: Not all fields are translated has some duplicate code from #24.
In my field module I have named keys for child elements.
Comment #29
Piazza CreditAttribution: Piazza commentedPatch in #24 works for me. Thanks!
Comment #30
benjifisherTo answer the question in #27: yes, check_plain() is needed. See #15 above for an explanation. If you find a case where there is a problem and removing the check_plain() fixes it, please say how to reproduce it.
Comment #31
czigor CreditAttribution: czigor commented#24 works for me too.
Comment #32
rutcreate CreditAttribution: rutcreate commentedUpdated the patch with fix for email field.
Comment #34
jibran#1964234: Not all fields are translated and #1157512: Labels are not translated with i18n_field for Drupal core. are marked as duplicate. Here is another one #1961750: Unable to translate field label and description containing html tags/entities..
Comment #35
bojanz CreditAttribution: bojanz commentedWell, this was not a fun day :)
Retitling the issue. Attaching a patch without #1961750: Unable to translate field label and description containing html tags/entities., it is a separate bug, so there's no need to fix it in this issue (since we're already fixing 5 different bugs here).
I've based my work on the #32 patch.
Tested text, numeric, image, entityreference, email, list text, list boolean fields of both cardinality 1 and unlimited.
Tested most widgets, tested default values.
Here are the different parts:
This is a much smarter check, allows us to be explicit about what we're doing (ignoring the Field UI edit form, though I have to ask: why?).
It is very ugly to compare all versions of $element each time something inside needs to be changed.
Instead, I'm defining a new $alter_element before we start, and documenting what is used where.
Note that the first two IFs don't check for field types, because the same approach might make other field types work too.
The entityreference check is very specific, so that it fixes the autocomplete widget without breaking the rest.
I am not happy that we're hardcoding conditions for contrib modules, but that's what needs to be done.
A followup could perhaps introduce and document a hook that contribs could implement.
This new condition allows the description to be translated for single-value filefields and imagefields.
This fixes list_boolean fields using both available widgets.
Comment #36
mradcliffeThis is not a full review, but re-iterate my comment in #28.
Can you use element_children() here instead? An element child may be indexed or keyed, not just indexed.
Maybe something like this if you always want the first child element..?
Comment #37
bojanz CreditAttribution: bojanz commentedThe point of that code is explicit, accounting for core modules (like file) which do:
Every IF clause there matches a specific set of field types.
I am wary of blindly modifying children because we don't know what results that will give for untested field types (for instance, you definitely don't want to do that if you have multiple numeric children, like when you have an unlimited cardinality field). So, we can only lose, not gain anything.
In general, trying to support any kind of arbitrary element structure with one alter hook is a really bad idea, but since we're forced to do it, I tried to do what was safest.
Comment #38
Razia_b CreditAttribution: Razia_b commentedThanks. Your patch has saved me a lot of hassle :)
Comment #39
mradcliffeOkay, I guess i18n won't support all fields then. :|
Edit: I should really expand this instead of being disappointed.
I disagree completely. The correct way to find an element child is via element_children() whether it's an index or a key.
Comment #40
mErilainen CreditAttribution: mErilainen commentedNot sure if this is the best approach, but it works like a charm, no more bi-lingual editor interface. All the translations I have added already now appear as they should after applying the patch.
Comment #41
jibran@bojanz great work in combining the patch and come up with one approach. I am still unable to translate date field description.
Comment #42
bojanz CreditAttribution: bojanz commentedI didn't test with date fields, so you'll probably need to provide a new patch that deals with date fields.
Supporting any type of field is impossible, we need to tackle field type by field type, unfortunately.
Comment #43
caktux CreditAttribution: caktux commentedBoolean fields with the option 'Use field label instead of the "On value" as label' end up with no label at all.
Comment #44
bojanz CreditAttribution: bojanz commentedUpdated patch.
Added this part:
allows email fields to work without hardcoding them in the conditions above, and allows commerce_price fields to work as a bonus.
I have also confirmed that the set of IFs can be replaced with this code:
which is the approach mradcliffe has advocated, but I'm still unsure about the magic here, especially relying on an empty #title to trigger this check.
That's why I haven't added it to the patch (yet)
Comment #45
Jose Reyero CreditAttribution: Jose Reyero commentedAfter reading through all this and weighting pros and cons I've committed the patch in #35. Thanks everybody here because translating fields is a really difficult one. Some notes:
- This fields handling code is never going to look nice, se the best we can do is commenting all the if/then mess. Thanks @bojanz for extensive documentation in the patch.
- For this module we really have enough with translating all Drupal core field types -and not breaking contrib forms-. For translating fields provided by contrib modules, like Date and Entity references, please ,https://drupal.org/project/i18n_contrib
- Replying to some question above, we are not even trying to translate field config forms becase 1. 'field' names afaik do not show up for end user forms -as oppsed to 'field instance' ones- and 2. we have already a lot of work with trying to translate end user forms.
- Right about filtering issues, that's some other issue, please give a try to #1961750: Unable to translate field label and description containing html tags/entities.
- Yes, I know regressions are specially ugly... More tests are always welcome.
- Sorry if I forgot some names in the commit message, I've just used the one generated by Dreditor.
Btw, aiming at a new module release within the next two weeks, please do some testing.
Comment #46
bojanz CreditAttribution: bojanz commentedThanks! Do you have any feedback regarding the changes in #44? The first part (that's included in the patch) could especially be useful, otherwise I need to figure out how to add support for commerce_price fields (some kind of a hook? or hardcoding it too?).
Comment #47
jibran@bojanz please create a follow up patch/issue. Meanwhile I have posted new patch at #1961750-1: Unable to translate field label and description containing html tags/entities..
Thanks @Jose Reyero for committing the patch.
Comment #49
hoporr CreditAttribution: hoporr commentedUsed patch from #35, which was committed in #45.
Seeing issues with Boolean fields: labels are not shown any longer, instead only seeing Yes|No.
May be related to #23, #24?
Comment #50
bojanz CreditAttribution: bojanz commentedPlease open a followup issue for that.
Comment #51
hoporr CreditAttribution: hoporr commentedFollowup issue for #49, Boolean fields problem: https://drupal.org/node/2029043
(already existed)
Comment #52
Jose Reyero CreditAttribution: Jose Reyero commentedI think we should fix all these field issues for good. And this is the way:
#2061999: Add tests for field translations to avoid regressions (i18n_field.test)
Comment #53
junetellain626 CreditAttribution: junetellain626 commentedFor those who might also have a hard time with getting their reference autocomplete widgets to work even with the #35 patch already committed. Double check if you the field you are using is indeed from the entityreference module, or from a node/user reference from the references module. [facepalm]
Adding the following to line 205 would be a temporary fix for node references field.
Comment #54
Pere OrgaRunning 1.10 I'm not able to translate the 'Email' field label of accounts, in the user view page (.e.g. user/1).
Sorry to reopen but, does anyone remember testing this while fixing the other issues of this ticket? Has anyone experienced this issue?
Comment #55
Jose Reyero CreditAttribution: Jose Reyero commented@Pere,
That should be a regular text, translated through localization, nothing to do with this one.
And please don't reopen issues unless you read carefuly the previous 50 posts... (just joking, please don't)
Comment #57
Carlos Miranda Levy CreditAttribution: Carlos Miranda Levy commentedThis situation remains as of i18n 7.x-1.11.
At least for Entity Reference fields referencing User Profiles.
Not sure if this is duplicate of https://www.drupal.org/node/1961750
Comment #59
idebr CreditAttribution: idebr at One Shoe commentedThis page is ranked highly in Google for untranslatable field labels/descriptions with i18n.
Future visitors: this is the issue you are looking for: #2474403: Translation of field description overwritten