date_month_names_translated, and thus date_t, fails to translate month names because it omits the '!long-month-name ' prefix.

I think the error was introduced during this committ: http://cvs.drupal.org/viewvc.py/drupal/contributions/modules/date/date_a...

The reason why '!long-month-name ' is necessary is explained in core's common.php#format_date: "May" is both a short and a long month name in English, but in order to translate it to languages where the number of characters varies some context-information (do we want a short or long name) is necessary. Thus Drupal core uses the convention with translation keys 'May', '!long-month-name May', 'Jun', '!long-month-name June' and so forth. The key 'June' does not normally exist in a standard installation's translation database, so when the current date_month_names_translated tries such translations they fail (unless some other module or user has added these non-standard translations too).

Patch is attached.

CommentFileSizeAuthor
#2 date_long_month_translation2.diff1.33 KBemok
date_long_month_translation.diff1.02 KBemok

Comments

karens’s picture

karens commented
Status: Needs review » Fixed

Yes, I knew about this but for some reason had it in my head that the special formatting was for the short month names instead of the long month names. Patch committed, thanks!

emok’s picture

emok commented
Status: Fixed » Needs review
StatusFileSize
new date_long_month_translation2.diff1.33 KB

The patch got applied to date_month_names_untranslated rather than date_month_names_translated a few lines down. I guess there was a line number offset between the version that I rolled the patch on and version that you applied it on.
The mixup hower made me realize the amount of code could be reduced by reusing the untranslated array instead of redefining the same array in date_month_names_translated. Hopefully this patch should apply better since it covers both functions and thus should prevent a mixup.

karens’s picture

karens commented
Status: Needs review » Fixed

That wasn't your mistake, it was mine. I manually applied the patch to the wrong place :(

Thanks!

Anonymous’s picture

Anonymous (not verified) commented
Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for two weeks with no activity.

jorgeegomez’s picture

jorgeegomez commented
Title: date_month_names_translated uses incorrect translation keys » Regression? date_month_names_translated uses incorrect translation keys
Status: Closed (fixed) » Active

I think there's been a regression with this bug. The function date_month_names (previously date_month_names_translated) went back to using keys without the "!long-month-name" indicator.

I test it by using a "M" string on a format_date function call in a .tpl.php, which gives me a translated abbreviation ("Ene","Feb","Mar"), but just by changing it to "F", I get the untranslated month names ("January","February","March").

Rosamunda’s picture

Rosamunda commented

I´m sorry but I´ve got the same problem with the latest version of Date.
I´ve translated all strings to spanish and checked them out: they are in fact in spanish and correctely translated.
But when I try to get the date name (complete or the abbreviation) I keep getting the english version instead.

hip’s picture

hip commented

Same here.
Any good news about it?

damienmckenna’s picture

damienmckenna
Location TN, USA
commented
Issue summary: View changes
Status: Active » Closed (won't fix)

Unfortunately the Drupal 6 version of the Date module is no longer supported. That said, we appreciate that you took time to work on this issue. Should this request still be relevant for Drupal 7 please feel free to reopen it. Thank you.