[wp-trac] [WordPress Trac] #14972: Proposal: Pool of common strings for core, themes, and plugins

[WordPress Trac]

#14972: Proposal:  Pool of common strings for core, themes, and plugins
-------------------------+--------------------------------------------------
 Reporter:  demetris     |       Owner:                 
     Type:  enhancement  |      Status:  new            
 Priority:  normal       |   Milestone:  Awaiting Review
Component:  i18n         |     Version:  3.1            
 Severity:  normal       |    Keywords:  dev-feedback   
-------------------------+--------------------------------------------------

Comment(by demetris):

 Thanks for the thoughts, Nikolay.

 Replying to [comment:11 nbachiyski]:
 >  Strings will change. If we keep a semi-official list, we will have to
 keep it growing forever.

 The way I think about it, we won’t just be throwing stuff in the list.  It
 will be a list carefully curated, and it will include only strings
 commonly used in web-publishing environments;  not strings that we expect
 to be obsolete in the next two or three WordPress versions.  For example,
 see my small sample list at http://op111.net/80 — Also, strings would be
 reviewed before going into the common pool, so that we wouldn’t have to
 modify them later for grammar, punctuation, capitalization etc. etc.

 >  Most of the strings can and should be part of template functions. I
 think it's the better way to both standardize stuff and don't struggle
 with strings backwards-compatiblity problems. We don't have any template
 tags for admin plugins, but large percent of plugins code is related to
 their admin UI.

 This has been on my mind too, as core offers more and more functionality
 and strings to themes in the form of template functions (e.g., the new
 comment_form and login_form functions).  But I could not find a way to
 make something of it in the context of my proposal.  So I think of the two
 as independent for now.

 >  On the idea of putting many strings in a big file (like strings-
 common.php). We have two choices of referencing the strings in the file:
 >  Give them unique IDs (either in array or globals). Choosing string IDs
 is as hard as choosing variable names (and this is one of the two hardest
 problems in programming). Also, each string should be as near, to the code
 that uses it, as possible.
 >  Include just a big pile of {{{__()}}} calls in the file, like it's done
 in the proposed patch. I am not a big fan because of the "strings will
 change" reason.

 I like the big pile approach because it is simple:  We only need one extra
 file and one conditional include.  (If locale is not en_US.)

 I also like it because it will present all strings designated for common
 use in a friendly, humanly readable form, to make them easily
 discoverable.

 (By the way, the attached file is not a proposed patch.  It’s just a file
 I keep open in a tab in my editor, to throw in strings that seem
 interesting candidates.)

 >  If we include strings without a domain in the plugin, there will be no
 way for the plugin translator to override them. Sometimes in a plugin
 Header means something totally different than in core. Such words are hard
 to translate anyway. For possible solutions of this problem see below.

 We don’t need to include strings that become ambiguous out of context.
 But, in any case, it seems to me that such strings are only a small
 percentage of commonly used strings.

 If, for some reason, we want to include such a string, we could use
 {{{_x()}}}.  Or am I wrong?

 >  In any case we will need better custom tools.

 If the pot-making script can be tweaked to accept a textdomain as an
 optional argument (so that, for example, it makes a POT only with strings
 of the ''mysuperbtheme'' domain), I would be very happy.  Scribu too said
 that he would be happy if just that got added.

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