[wp-trac] [WordPress Trac] #14972: Proposal: Pool of common strings for core, themes, and plugins
WordPress Trac
wp-trac at lists.automattic.com
Tue Oct 19 13:44:00 UTC 2010
#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
More information about the wp-trac
mailing list