[wp-trac] [WordPress Trac] #12968: I18n-friendly strings for the new system of post types

[WordPress Trac]

#12968: I18n-friendly strings for the new system of post types
--------------------------+-------------------------------------------------
 Reporter:  demetris      |       Owner:  nbachiyski            
     Type:  defect (bug)  |      Status:  accepted              
 Priority:  normal        |   Milestone:  3.0                   
Component:  i18n          |     Version:  3.0                   
 Severity:  blocker       |    Keywords:  has-patch dev-feedback
--------------------------+-------------------------------------------------

Comment(by nacin):

 I'd rather go with add_new and add_new_item (or add_new_post), instead of
 the corresponding add_new_bare and add_new. It's more obvious for both
 core and plugin developers when the key is as close to the string as
 possible. We've already had some bugs caused by confusion among the
 different cap checks.

 Additionally:
 We need to keep label for compat. We may want to keep singular_label as
 well. Simply populate them with the same values after running the helper
 function?

 Does it make sense to group the capability checks as well? I really like
 that idea (->cap->edit_post, ->cap->edit_posts), and nothing is stopping
 us from again creating the back compat properties and just letting them
 sit here.

 How much are we backing ourselves into a corner by adopting special
 strings everywhere? Does it hurt us when we want/need to change strings in
 the future?

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