[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   
-------------------------+--------------------------------------------------
Changes (by GruffPrys):

  * type:  defect (bug) => enhancement


Comment:

 Hi guys - I'm new to contributing to open projects so be gentle ;)

 Whilst Demetris' suggestion is quite ingenious in a number of ways, I
 believe it has a few drawbacks.

 I'm more of a translator than a developer, so obviously I'd welcome any
 developments that lessen the workload and increase the consistency of the
 translation. However, it seems to me that this suggestion proposes to do
 so at the expense of complicating the developers' internationalization
 process and increasing both their workload and the expertise required from
 them.

 In the proposed scenario, developers may have to become familiar with what
 is contained within any proposed strings-common.php file and what is not
 in order to decide when to use their text domain and when not to.

 This would then require developers to learn the difference between, say
 'search' (the verb) and 'search' as a mass noun or count noun, and the
 implications of these differences on the translation before they can tell
 if the form of the word that they'r after is actually in strings-
 common.php or not. There's a string containing the phrase "Search Help" in
 WP 3.0.+. Is it fair to expect developers to understand that "Search Help"
 could be a noun phrase or a verb phrase (depending on context), and could
 require very different translations accordingly?

 Personally, I think that is too much to ask of developers. The danger is
 that the proposed method wouldn't be adopted, or would be misused (i.e.
 we'd see the wrong translations of 'search', 'post' or 'vote' appear in
 plugins and themes). The beauty of the current method is that it is quite
 simple for developers to understand, whilst it leaves the linguistic
 decisions in the hands of linguists.

 I'd argue that this simplicity and the developer/linguist split needs to
 be retained, and that the issues of the translator's workload and the
 consistency of translation could better be addressed by integrating a
 translation memory system and terminology management into GlottPress.

 Each language could have its own translation memory and glossary of terms
 for each project, whilst suggestions from the memories and glossaries of
 other projects could also be displayed for that language. This would help
 with both the consistency of translation and the translator's work flow,
 whilst keeping translators in control of the linguistic aspects of the
 translation.

 I realise that incorporating such systems would be a lot of development
 work (we've developed a web-based terminology dictionary development
 environment at work), but I think ultimately it would be the correct way
 to go about it.

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