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.
Hi everyone,
I'm using a german translation of Drupal. Webform is fully translated, the months are showing up right, but in the E-Mail confirmation the months aren't translated. I tried "Locale" and "String Overrides" - no success. Anyone any suggestion?
Greetings from Germany,
towlie
Don't forget to bring a towel!
Comment | File | Size | Author |
---|---|---|---|
#10 | webform-date.patch | 489 bytes | dayre |
#5 | webform-375874-5.patch | 722 bytes | djalloway |
#1 | date.inc_.patch | 510 bytes | Anonymous (not verified) |
Comments
Comment #1
Anonymous (not verified) CreditAttribution: Anonymous commentedI believe that's the same issue I stumbled upon. However, it can be resolved with a simple patch. In date.inc (theme_webform_mail_date) instead of using PHP's date() function Drupal's date_format() function should be used. Patch file is attached, please review. Thanks.
Comment #2
towlie CreditAttribution: towlie commentedWorks great! Thanks a lot!
Should be added to the next release. (Maybe someone should check it in an english version as well.)
Comment #3
quicksketchAh, great. Thanks mglanznig! I'm moving this to patch, RTBC, so I remember to add it.
Comment #4
towlie CreditAttribution: towlie commentedSame problem now in the new version. I fixed the date.inc again but the patch doesn't work...
Comment #5
djalloway CreditAttribution: djalloway commentedThe code is good, but the patch file seems to be broken.
It is trying to remove the correct line and adding the old one.
Try this patch, should work fine.
Comment #6
towlie CreditAttribution: towlie commentedIt works fine :)
Thanks!
Comment #7
djalloway CreditAttribution: djalloway commentedThe patch still needs to be committed, so we'll leave the status as RTBC for now.
Comment #8
quicksketchCommitted to all versions.
Comment #10
dayre CreditAttribution: dayre commentedThat patch has an error. Caused big headaches for our users....
It's calling format_date, but not passing in the correct timezone offset (0), so format_date assumes the user want's the site timezone (which is likely not GMT = 0).
To reproduce the error:
Attached is a new patch...
Comment #11
dayre CreditAttribution: dayre commentedoops... forgot to change status
Comment #12
quicksketchThank dayre, committed to 2.x versions.
Comment #14
foripepe CreditAttribution: foripepe commentedPlease, fix it in the 5.x-2.9 too.
Thanks.
Comment #15
quicksketchIt is fixed already in 2.x, we just need to make a new release (it will be in 2.10).
Comment #16
foripepe CreditAttribution: foripepe commentedPlease, do it. You can help a lot for people using date field with mails.
Comment #18
FTF CreditAttribution: FTF commentedWhen you will put out new fixed release? It's very annoying bug :-(
Comment #19
quicksketchAnytime after #604958: %profile and %server default values broken is fixed. Seems like there are plenty of solutions, we need to find the correct one and apply it.
Comment #20
Jorrit CreditAttribution: Jorrit commentedI think patch #10 was incorrect, because I am now experiencing that one-day-back error with timezone Europe/Amsterdam. It used to work because the timezone offset of strtotime() and format_date were cancelling each other. The patch caused format_date to assume GMT, while strtotime still used the system wide timezone.
The following would be better (note the +000):
Edit:
One additional thought: as an internal check to see whether the right date is output, it is perhaps wise to check the hour + minute result of the format_date function. It should be 00:00:
Comment #21
quicksketchstrtotime() should always be in UTC I believe. But considering there are a hundred different ways that the timezone might be set somehow. The current patch should work for most users.
In Webform 3.x, we've fixed this by introducing a dedicated function webform_strtotime(), which uses the same approach Date module provides to force the timezone to UTC before running strtotime:
So in short my recommendation is upgrading to Webform 3.x, I'm not sure this will be correct in 2.10.
Comment #22
Jorrit CreditAttribution: Jorrit commentedAt http://nl2.php.net/strtotime I read: "This function will use the TZ environment variable (if available) to calculate the timestamp."
I will upgrade asap.
Comment #23
quicksketchAnother alternative is just installing the Date project, which sets the timezone to UTC for you. Though really I'd just recommend upgrading :-)
Comment #24
sreynen CreditAttribution: sreynen commented#21 suggests this issue is fixed, not active.