Re: String freeze break requested for Orca for GNOME 2.17.92
- From: "Christian Rose" <menthos gnome org>
- To: "Willie Walker" <William Walker sun com>
- Cc: gnome-i18n gnome org, gnome-doc-list gnome org
- Subject: Re: String freeze break requested for Orca for GNOME 2.17.92
- Date: Mon, 26 Feb 2007 14:05:29 +0100
On 2/22/07, Willie Walker <William Walker sun com> wrote:
Attached is a patch for the ngettext change as requested in response to
the original request. In discussing this issue with Andre Klapper on
IRC, we agreed the move forward plan is this:
1) Limit the break request to nautilus.py. The feature supported by it
comes at the request of our users and they really want to see it get in
for GNOME 2.18.
2) Postpone the Gecko.py changes to GNOME 2.19. My feeling is that
there are too many strings to mark as translatable and I'd rather not
put undo burden on the l10n team for GNOME 2.18.
All we need is one thumbs up on this. :-) If there is sufficient
pushback, however, we will pull the specialized nautilus support from
GNOME 2.18 and wait until GNOME 2.19. But...we just need to know one
way or the other.
So, I take it that the change you want is this one:
itemCountString = _(" %d items") % itemCount
I think there are two issues with this change itself:
A) This message really should use ngettext, otherwise this message
will be broken in any locale that uses other rules for plural than
English. See http://developer.gnome.org/doc/tutorials/gnome-i18n/developer.html#plurals.
So something along the lines of
itemCountString = ngettext(" %d item", " %d
items", %itemCount) % itemCount
(I don't speak Python, but you probably get the idea)
B) Why is there a need for a space at the beginning of the message?
When developers add spaces at the beginning of strings, it always
makes me suspect that there's some other problem with the string as
If the space is there for padding or concatenation purposes, then
that's broken localization-wise too. Using spaces for padding is
broken for RTL locales.
If the space is there for concatenation purposes, then that's broken
for all localization efforts, since proper localization of sentence
fragments out-of-context is not possible.
Furthermore, this change is suggested very late in the cycle and in
the string freeze. I feel that either solution to these problems is
not entirely adequate, since there appears to be several issues at
hand with this string.
I hence feel reluctant to approving this this late in the cycle. It's
better to adress this properly later. However, Danilo might be of
another opinion, and in that case I trust his judgement.
] [Thread Prev