[wp-trac] Re: [WordPress Trac] #9730: The new date_i18n hook creates potential bugs in the admin interface

[WordPress Trac]

#9730: The new date_i18n hook creates potential bugs in the admin interface
-------------------------------+--------------------------------------------
 Reporter:  Denis-de-Bernardy  |       Owner:  Denis-de-Bernardy
     Type:  defect (bug)       |      Status:  new              
 Priority:  normal             |   Milestone:  2.8              
Component:  i18n               |     Version:  2.8              
 Severity:  major              |    Keywords:  has-patch tested 
-------------------------------+--------------------------------------------

Comment(by hakre):

 i could take a look into archives, that is especially
 ''wp_get_archives()'' in ''/wp-includes/general-template.php'' .

 compareable with the calender stuff, this function uses misc approaches to
 translate date and time information:
  - Just numbers. If only a fragment of a date/time is used (like year or
 day), often only a number is used.
  - WP_locale / $wp_locale - this is used to translate month names etc.
  - {{__()__}} - often the result is "translated" again.

 i assume that all this is done sothat current users can already translate
 (at least some) of those values.

 as denis already pointed, archives and calendar are not translated, but
 that is what #7753 is after.

 to enable translation of archives and calendar, these functions must make
 use of date_i18n() or make use of the $translate (the 3rd) parameter of
 ''mysql2date()''.

 i suggest to use that parameter at least for ''wp_get_archives()'' and
 ''get_calendar()'' in general-template.php.

 other potention functions: ''the_date()'',  ''get_post_modified_time()''.

 i must first read on how to get UTC timestamps from partial data values
 before continue.

-- 
Ticket URL: <http://core.trac.wordpress.org/ticket/9730#comment:22>
WordPress Trac <http://trac.wordpress.org/>
WordPress blogging software