(Approved) string change in Orca

2010-09-07 Thread Joanmarie Diggs
Hi all.

As discussed [1] on the gnome-18n list, we had been told [2] that one of
the strings in Orca is too long and needed to be changed. I have
received the requisite two responses. [3][4] Therefore, the following
change has just been committed to master:

 -_(Enable notification message list mode.  \
 -   Press Escape to exit or h for help))
 +_(Present notification messages list))

Sorry for any inconvenience.
--joanie

[1] http://mail.gnome.org/archives/gnome-i18n/2010-September/msg00027.html
[2] https://bugzilla.gnome.org/show_bug.cgi?id=628589
[3] http://mail.gnome.org/archives/gnome-i18n/2010-September/msg00060.html
[4] http://mail.gnome.org/archives/gnome-i18n/2010-September/msg00064.html


___
gnome-i18n mailing list
gnome-i18n@gnome.org
http://mail.gnome.org/mailman/listinfo/gnome-i18n


String change for orca

2009-02-11 Thread Willie Walker

Hi All:

At the request of our Hungarian translator, we've changed a string in 
Orca.  The old string was this:


#. Translators: this is in reference to a heading level
#. in HTML (e.g., For h3, the level is 3).
#.
#: ../src/orca/scripts/toolkits/Gecko/speech_generator.py:90
#, python-format
msgid level %d

The new string is this:

#. Translators: the %d is in reference to a heading
#. level in HTML (e.g., For h3, the level is 3)
#. and the %s is in reference to a previously
#. translated rolename for the heading.  If you
#. change the order of the %s and %d in the string
#. (as needed for Hungarian, for example), Orca will
#. detect it and do the right thing.
#.
#: ../src/orca/scripts/toolkits/Gecko/speech_generator.py:93
#, python-format
msgid %s level %d

Thanks!

Will
___
gnome-i18n mailing list
gnome-i18n@gnome.org
http://mail.gnome.org/mailman/listinfo/gnome-i18n


Format specifier (re)ordering in Python (was: String change for orca)

2009-02-11 Thread Wouter Bolsterlee
Hi all,

The format specifiers should be in a different order problem is not new,
and not specific to Python. Let's look into this specific case once more:

2009-02-11 klockan 20:58 skrev Willie Walker:
 At the request of our Hungarian translator, we've changed a string in  
 Orca.  The old string was this:

 #. Translators: this is in reference to a heading level
 #. in HTML (e.g., For h3, the level is 3).
 #.
 #: ../src/orca/scripts/toolkits/Gecko/speech_generator.py:90
 #, python-format
 msgid level %d

 The new string is this:

 #. Translators: the %d is in reference to a heading
 #. level in HTML (e.g., For h3, the level is 3)
 #. and the %s is in reference to a previously
 #. translated rolename for the heading.  If you
 #. change the order of the %s and %d in the string
 #. (as needed for Hungarian, for example), Orca will
 #. detect it and do the right thing.
 #.
 #: ../src/orca/scripts/toolkits/Gecko/speech_generator.py:93
 #, python-format
 msgid %s level %d

While this may work in this specific case, this is by no means a generally
acceptable solution to this kind of problem. What happens if both arguments
are strings? Or both are numbers? Or if you had 4 format specifiers? Well,
it would break horribly. So we need something more reliable :)

In C, sprintf() supports reordering format specifiers using %n$f, where n
is a number. Python does not support the %1$d syntax to its built-in
sprintf-like string formatting operator, %, but it does support named
parameter substitution when a mapping (e.g. a dictionary instance) is passed
to the % operator.

This may sound cryptic, so let's illustrate this with a few examples:

   'the role is %(role)s and the level is %(level)d' % {'role': 'test', 
'level': 3}
  'the role is test and the level is 3'

If translators decide the order has to be changed, this will result in
something like this:

   'the level is %(level)d and the role is %(role)s' % {'role': 'test', 
'level': 3}
  'the level is 3 and the role is test'

This approach works in all cases, even in the case that the two format
specifiers are the same (e.g. both are numbers).

There is one downside though: translators MUST NOT translate the keywords
(level and role in my case), since those are the keys used to lookup the
value in the mapping passed to the % operator. But then, translators can
just as well mess up format specifiers that are used in the traditional,
positional way, e.g. by translating '%.3f' to %.0f', which will result in
the fraction being removed upon display. So... a short translator notice
should be fine to avoid this problem.

Hope this helps others as well.

— Wouter


signature.asc
Description: Digital signature
___
gnome-i18n mailing list
gnome-i18n@gnome.org
http://mail.gnome.org/mailman/listinfo/gnome-i18n


Re: Format specifier (re)ordering in Python (was: String change for orca)

2009-02-11 Thread Willie Walker

Hi Wouter:

From my experiences with the Q_ vs. C_ change, for example, I saw 
translators being overly aggressive in their translations, translating 
stuff the comments explicitly told them not to translate.  Hence, I 
definitely supported the change to C_ because it helped prevent this.


At the risk of translators being more likely to get %s level %d right 
and %(role)s level %(level)d wrong, however, I think I'd prefer to 
reserve the use of format specifiers where disambiguation is necessary.


But, if the gnome-i18n team makes a decree that thou shalt always use 
format specifier reordering, perhaps a rule of thumb might be to use 
cryptic parameter names, like:


_(%(p1)s blah %(p2)d) % {'p1' : 'foo', 'p2' : 3 }

Will

Wouter Bolsterlee wrote:

Hi all,

The format specifiers should be in a different order problem is not new,
and not specific to Python. Let's look into this specific case once more:

2009-02-11 klockan 20:58 skrev Willie Walker:
At the request of our Hungarian translator, we've changed a string in  
Orca.  The old string was this:


#. Translators: this is in reference to a heading level
#. in HTML (e.g., For h3, the level is 3).
#.
#: ../src/orca/scripts/toolkits/Gecko/speech_generator.py:90
#, python-format
msgid level %d

The new string is this:

#. Translators: the %d is in reference to a heading
#. level in HTML (e.g., For h3, the level is 3)
#. and the %s is in reference to a previously
#. translated rolename for the heading.  If you
#. change the order of the %s and %d in the string
#. (as needed for Hungarian, for example), Orca will
#. detect it and do the right thing.
#.
#: ../src/orca/scripts/toolkits/Gecko/speech_generator.py:93
#, python-format
msgid %s level %d


While this may work in this specific case, this is by no means a generally
acceptable solution to this kind of problem. What happens if both arguments
are strings? Or both are numbers? Or if you had 4 format specifiers? Well,
it would break horribly. So we need something more reliable :)

In C, sprintf() supports reordering format specifiers using %n$f, where n
is a number. Python does not support the %1$d syntax to its built-in
sprintf-like string formatting operator, %, but it does support named
parameter substitution when a mapping (e.g. a dictionary instance) is passed
to the % operator.

This may sound cryptic, so let's illustrate this with a few examples:

   'the role is %(role)s and the level is %(level)d' % {'role': 'test', 
'level': 3}
  'the role is test and the level is 3'

If translators decide the order has to be changed, this will result in
something like this:

   'the level is %(level)d and the role is %(role)s' % {'role': 'test', 
'level': 3}
  'the level is 3 and the role is test'

This approach works in all cases, even in the case that the two format
specifiers are the same (e.g. both are numbers).

There is one downside though: translators MUST NOT translate the keywords
(level and role in my case), since those are the keys used to lookup the
value in the mapping passed to the % operator. But then, translators can
just as well mess up format specifiers that are used in the traditional,
positional way, e.g. by translating '%.3f' to %.0f', which will result in
the fraction being removed upon display. So... a short translator notice
should be fine to avoid this problem.

Hope this helps others as well.

— Wouter


___
gnome-i18n mailing list
gnome-i18n@gnome.org
http://mail.gnome.org/mailman/listinfo/gnome-i18n


Re: Format specifier (re)ordering in Python (was: String change for orca)

2009-02-11 Thread Marcel Telka
On Wed, Feb 11, 2009 at 09:37:20PM +0100, Wouter Bolsterlee wrote:
'the role is %(role)s and the level is %(level)d' % {'role': 'test', 
 'level': 3}
   'the role is test and the level is 3'
 
 If translators decide the order has to be changed, this will result in
 something like this:
 
'the level is %(level)d and the role is %(role)s' % {'role': 'test', 
 'level': 3}
   'the level is 3 and the role is test'
 
 This approach works in all cases, even in the case that the two format
 specifiers are the same (e.g. both are numbers).
 
 There is one downside though: translators MUST NOT translate the keywords

Isn't this checked by the msgfmt command? If not, it should be, IMHO.
Bug in gettext?

 (level and role in my case), since those are the keys used to lookup the
 value in the mapping passed to the % operator. But then, translators can
 just as well mess up format specifiers that are used in the traditional,
 positional way, e.g. by translating '%.3f' to %.0f', which will result in
 the fraction being removed upon display. So... a short translator notice
 should be fine to avoid this problem.

-- 
+---+
| Marcel Telka   e-mail:   mar...@telka.sk  |
|homepage: http://telka.sk/ |
|jabber:   mar...@jabber.sk |
+---+
___
gnome-i18n mailing list
gnome-i18n@gnome.org
http://mail.gnome.org/mailman/listinfo/gnome-i18n


Re: [+gnome] Re: Format specifier (re)ordering in Python (was: String change for orca)

2009-02-11 Thread Wouter Bolsterlee
2009-02-11 klockan 21:58 skrev Willie Walker:
 But, if the gnome-i18n team makes a decree that thou shalt always use  
 format specifier reordering, [...]

Hi Willie,

No worries, if your current approach to this specific case works, by all
means leave it like it currently is. It's simpler after all.

Sorry if I wasn't clear about this: my intention was not to correct you or
urge you to revisit the changes you made. I just sent out this message for
future reference.

Keep up the good work, and take care not to insult gnome-i18n, ;)

— Wouter


signature.asc
Description: Digital signature
___
gnome-i18n mailing list
gnome-i18n@gnome.org
http://mail.gnome.org/mailman/listinfo/gnome-i18n


Re: [+gnome] Re: Format specifier (re)ordering in Python (was: String change for orca)

2009-02-11 Thread Wouter Bolsterlee
2009-02-11 klockan 22:03 skrev Marcel Telka:
 On Wed, Feb 11, 2009 at 09:37:20PM +0100, Wouter Bolsterlee wrote:
  There is one downside though: translators MUST NOT translate the keywords
 Isn't this checked by the msgfmt command? If not, it should be, IMHO.
 Bug in gettext?

If I recall correctly (it's been a while), this is not checked. However,
things might have changed in the mean time.

— Wouter


signature.asc
Description: Digital signature
___
gnome-i18n mailing list
gnome-i18n@gnome.org
http://mail.gnome.org/mailman/listinfo/gnome-i18n


Re: [+gnome] Re: Format specifier (re)ordering in Python (was: String change for orca)

2009-02-11 Thread Marcel Telka
On Wed, Feb 11, 2009 at 10:07:25PM +0100, Wouter Bolsterlee wrote:
 2009-02-11 klockan 22:03 skrev Marcel Telka:
  On Wed, Feb 11, 2009 at 09:37:20PM +0100, Wouter Bolsterlee wrote:
   There is one downside though: translators MUST NOT translate the keywords
  Isn't this checked by the msgfmt command? If not, it should be, IMHO.
  Bug in gettext?
 
 If I recall correctly (it's been a while), this is not checked. However,
 things might have changed in the mean time.

I tested it and it works!

$ tail sk.po -n 3
#, python-format
msgid %(aaa)s %(bbb)d
msgstr %(bbb)d %(zzz)s
$ LC_ALL=C msgfmt -c sk.po
sk.po:20: a format specification for argument 'aaa' doesn't exist in
'msgstr'
msgfmt: found 1 fatal error
$ msgfmt -V
msgfmt (GNU gettext-tools) 0.17
Copyright (C) 1995-1998, 2000-2007 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later
http://gnu.org/licenses/gpl.html
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Napísal Ulrich Drepper.
$



-- 
+---+
| Marcel Telka   e-mail:   mar...@telka.sk  |
|homepage: http://telka.sk/ |
|jabber:   mar...@jabber.sk |
+---+
___
gnome-i18n mailing list
gnome-i18n@gnome.org
http://mail.gnome.org/mailman/listinfo/gnome-i18n


String change in Orca

2009-02-05 Thread Joanmarie Diggs
Hi all.

In the spirit of a more user-friendly Orca Preferences dialog, we've
gotten rid of the string update interval:, replacing it with
every. :-)

~~
#. Translators: Here 'every' labels a spin button through which a user
can customize the frequency in seconds an announcement should be made.
(The spin button is followed by the label 'seconds'.) Thus if a user
chooses 5 in the spin button, the complete phrase would be 'every 5
seconds'.
#: ../src/orca/orca-setup.glade.h:178
msgid every
msgstr 
~~

As always, the Orca team is very grateful for all the work y'all do!

Take care.
--Joanie

___
gnome-i18n mailing list
gnome-i18n@gnome.org
http://mail.gnome.org/mailman/listinfo/gnome-i18n


String change in Orca trunk

2008-02-06 Thread Eitan Isaacson
Hi,

We have a minor string change in Orca.
Instead of France French 1, it is France French Grade 1.
It was probably obvious anyway.

Thanks!

Eitan.


___
gnome-i18n mailing list
gnome-i18n@gnome.org
http://mail.gnome.org/mailman/listinfo/gnome-i18n


String change for orca module.

2006-07-12 Thread Rich Burridge

Per the String Announcement Period request in the July 10th
entry on the GNOME 2.15 release planning web page
( http://live.gnome.org/TwoPointFifteen ), this is to inform you
that we've made a string change in the orca module.

The string:

  Speaks the current flat review item or word.

in .../src/orca/default.py has been changed to:

  Speaks or spells the current flat review item or word.

Thanks.

___
gnome-i18n mailing list
gnome-i18n@gnome.org
http://mail.gnome.org/mailman/listinfo/gnome-i18n