[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 nbachiyski):

 Replying to [comment:20 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.
 >

 I agree. Fell free to change them :-)

 > 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?
 >

 Yes, we should populate them. I thought we were introducing these in 3.0
 and we had nothing to be compatible with. Thinking is bad.

 > 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.
 >

 I like groupings, too.

 > 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?

 Change of those strings is expensive, because even a minor change in
 string format or adding a new string has to be communicated with plugin
 devs and they will need to change their code.

 That's why I tried to limit the number strings we expose via this
 interface. In the future, only the most common ones should go there.
 Having post/page in the less frequently used strings is fine.

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