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

 Replying to [comment:12 GruffPrys]:
 > Hi guys - I'm new to contributing to open projects so be gentle ;)
 >

 Hello, GruffPrys, and welcome to the discussion!

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

 First, the way I think of it, this method would be '''optional'''.
 Completely optional.  So, if a theme/plugin author does not want to use
 it, they can keep doing things the way they know.  For them the method
 might as well not be there at all.

 (We could force the proposed method on everyone by making makepot.php
 automatically ignore strings that are also found in strings-common.php.
 This is certainly feasible from a technical point of view, as Mark Jaquith
 said at the dev meetup of 7 Oct 2010 and as Nikolay hinted above.  But I
 think it would not be a good approach, at least not for know.)

 Second, I have an inkling that authors, at least theme authors, will like
 it.

 If you were to choose a theme for translation, would you pick one with 100
 strings or one with 50 strings, everything else being equal?

 Plugin and theme authors who understand the value of i18n and l10n will
 also understand this.  At least so I think.

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

 First, as I say in my previous reply, we don’t have to include ambiguous
 strings.  (Which are only a small percentage anyway.)

 Second, if core has ambiguous strings like “Search Help”, maybe we should
 look at them independently of i18n.  E.g., does “Search Help” mean “Search
 for Help”? Then maybe it should be “Search for Help”.  Or does it mean
 “Help for searching”?  Then maybe it should be “Help for searching”.

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

 In general I understand what you are saying, and I have been having
 similar thoughts.  The question I have asked myself, in short is:

 Many plugin/theme authors seem to struggle even with the bare essentials
 of i18n, and now I propose to add another piece to the language puzzle?

 But I think that i18n should not be treated any differently than other
 parts of WP.  WP introduces all the time various devices meant to make
 life easier for developers and users, but not all of them are adopted as
 quickly as we would like.  Sometimes because they don’t help backwards
 compatibility, sometimes because devs are happy with what they have,
 sometimes because we don’t advertise properly our new stuff, sometimes for
 other reasons.

 It would be the same for the method I propose.  What we can do, if we
 introduce a common pool or something to that effect, is:  (a) Make the
 method easy to understand and use.  (b) Advertise it well.  (c) Explain it
 with examples.

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