[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:  defect (bug)  |      Status:  new            
 Priority:  normal        |   Milestone:  Awaiting Review
Component:  i18n          |     Version:  3.1            
 Severity:  normal        |    Keywords:  dev-feedback   
--------------------------+-------------------------------------------------

Comment(by nbachiyski):

 Somebody raised that issue recently and I've been thinking about it for
 some time. Here are some random thoughts:
  * Strings will change. If we keep a semi-official list, we will have to
 keep it growing forever.
  * 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.
  * 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.
  * 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.
  * Translation functions should fallback to core strings when they cannot
 find a plugin/theme string (with a domain).
  * In any case we will need better custom tools.
         - Custom strings extractor. This is easy and we should do it
 anyway, because relying on {{{xgettext}}} being present has failed us many
 times (on many servers).
         - The extractor can only extract strings, with domain.
         - Or, the extractor can choose only strings, which are missing in
 the current stable release of WordPress and exclude common ones from the
 POT. This way translators will see only the different ones. In production
 these will fallback to core strings (see previous point.)
  * After writing all this I realized that breaking strings backwards
 compatiblity is acceptable. Plugins and themes will still work with only
 minor (and easy fixable) glitches.

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