String change for orca
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 , 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 , 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
Re: Format specifier (re)ordering in Python (was: String change for orca)
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 , 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 , 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: [+gnome] Re: Format specifier (re)ordering in Python
I don't mean it as an insult - sorry about that. I listen to gnome-i18n and will gladly follow a decree. Those kinds of things are usually made for consistency purposes and such. So, if they are needed, I will do them. You guys do good work. Will Wouter Bolsterlee wrote: 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 ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
String break request for Orca
This has come back to spank me square in my butt. I need to change:
_("%s level %d")
to:
_("%(role)s level %(level)d")
Although my testing and testing from a Hungarian translator (Hammer
Attila) showed that the first form worked, another Hungarian translator
(Gabor Kelemen) ended up being able to coax intltool into being more
picky. So, we need to go with the parameterized form.
Gabor has also shown me that "msgfmt -cvo /dev/null hu.po" will detect
translations that attempt to translated the parameter names (e.g.,
"(role)" and "(level)" in the above), alieving my concern about those
things getting translated by accident.
Ah well, for the better, I guess,
Will
___
gnome-i18n mailing list
gnome-i18n@gnome.org
http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: String break request for Orca
Hi Claude:
Gabor Kelemen commented on the simpler form not working for him at
http://bugzilla.gnome.org/show_bug.cgi?id=572218#c6
Looks like whatever version of msgfmt that Gabor is using is smart
enough to compare the order of the parameters.
Will
Claude Paroz wrote:
Le mardi 17 février 2009 à 19:57 -0500, Willie Walker a écrit :
This has come back to spank me square in my butt. I need to change:
_("%s level %d")
to:
_("%(role)s level %(level)d")
Although my testing and testing from a Hungarian translator (Hammer
Attila) showed that the first form worked, another Hungarian translator
(Gabor Kelemen) ended up being able to coax intltool into being more
picky. So, we need to go with the parameterized form.
Is the first form really buggy? I'm all in favour of this change for
post 2.26, but I need to be convinced this is really a problem worth to
break the string freeze.
Claude
Gabor has also shown me that "msgfmt -cvo /dev/null hu.po" will detect
translations that attempt to translated the parameter names (e.g.,
"(role)" and "(level)" in the above), alieving my concern about those
things getting translated by accident.
Ah well, for the better, I guess,
Will
___
gnome-i18n mailing list
gnome-i18n@gnome.org
http://mail.gnome.org/mailman/listinfo/gnome-i18n
Orca has branched for gnome-2-26
Hi All: Orca has branched for gnome-2-26. The branches/gnome-2-26 branch will be used for continued GNOME 2.26.x release and trunk will be used for the GNOME 2.27.x release series. Will ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: New strings in Orca
There's also a new string from bgo#585948 (just committed): "Translators: This checkbox toggles whether or not Orca says the child position (e.g., 'item 6 of 7')." msgid="Speak child p_osition" This also represents a UI change and we'll update the Orca docs accordingly. Thanks much for all your hard work, Will Joanmarie Diggs wrote: Hi all. I didn't realize that the string announcement period had already begun. Sorry! There are a number of string changes in Orca since the 13th: From bgo bug #588403: #. Translators: this command will move the mouse pointer #. to the current item without clicking on it. #. #: ../src/orca/default.py:151 msgid "Routes the pointer to the current item." msgstr "" #. Translators: Orca has a command that allows the user #. to move the mouse pointer to the current object. If #. for some reason Orca cannot identify the current #. location, it will speak this message. #. #: ../src/orca/default.py:5181 ../src/orca/default.py:5202 #: ../src/orca/default.py:5222 msgid "Could not find current location." msgstr "" From bgo bug #582506 (Use GtkBuilder instead of libglade): These are technically not new strings. But in the process of the conversion, I concluded that merely marking such generic words for translation wasn't ideal. So I gave them context. #. Translators: This refers to the default/typical voice used #. by Orca when presenting the content of the screen and other #. messages. #. #: ../src/orca/orca_gui_prefs.py:721 msgctxt "VoiceType" msgid "Default" msgstr "" #. Translators: This refers to the voice used by Orca when #. presenting one or more characters which is in uppercase. #. #: ../src/orca/orca_gui_prefs.py:725 msgctxt "VoiceType" msgid "Uppercase" msgstr "" #. Translators: This refers to the voice used by Orca when #. presenting one or more characters which is part of a #. hyperlink. #. #: ../src/orca/orca_gui_prefs.py:730 msgctxt "VoiceType" msgid "Hyperlink" msgstr "" From bgo bug #585417: #. Translators: different speech systems and speech engines work #. differently when it comes to handling pauses (e.g., sentence #. boundaries). This property allows the user to specify whether #. speech should be sent to the speech synthesis system immediately #. when a pause directive is enountered or if it should be queued #. up and sent to the speech synthesis system once the entire set #. of utterances has been calculated. #. #: ../src/orca/orca_gui_prefs.py:1529 ../src/orca/orca-setup.ui.h:26 msgid "Break speech into ch_unks between pauses" msgstr "" From bgo bug #585049: #. Translators: when the user selects (highlights) text in #. a document, Orca will speak information about what they #. have selected. #. #: ../src/orca/default.py:7774 msgid "paragraph selected down from cursor position" msgstr "" #: ../src/orca/default.py:7775 msgid "paragraph unselected down from cursor position" msgstr "" #: ../src/orca/default.py:7776 msgid "paragraph selected up from cursor position" msgstr "" #: ../src/orca/default.py: msgid "paragraph unselected up from cursor position" msgstr "" From bgo bug #588910: #. Translators: this is to inform the user of the presence #. of the red squiggly line which indicates that a given #. word is not spelled correctly. #. #: ../src/orca/default.py:4084 ../src/orca/default.py:8301 msgid "misspelled" msgstr "" #. Translators: this attribute specifies there is something "wrong" with #. the text, such as it being a misspelled word. See: #. https://developer.mozilla.org/en/Accessibility/AT-APIs/Gecko/TextAttrs #. #: ../src/orca/text_attribute_names.py:133 msgctxt "textattr" msgid "mistake" msgstr "" Note that the above "mistake" is a replacement for what used to be "invalid" which was removed as part of this bug. From bgo bug #575784: #. Translators: this is how someone would speak the name of the #. non-spacing diacritical key for the acute glyph #. #: ../src/orca/keynames.py:255 msgid "acute" msgstr "" #. Translators: this is how someone would speak the name of the #. non-spacing diacritical key for the circumflex glyph #. #: ../src/orca/keynames.py:260 msgid "circumflex" msgstr "" #. Translators: this is how someone would speak the name of the #. non-spacing diacritical key for the diaeresis glyph #. #: ../src/orca/keynames.py:270 msgid "diaeresis" msgstr "" #. Translators: this is how someone would speak the name of the #. non-spacing diacritical key for the ring glyph #. #: ../src/orca/keynames.py:275 msgid "ring" msgstr "" #. Translators: this is how someone would speak the name of the #. non-spacing diacritical key for the stroke glyph #. #: ../src/orca/keynames.py:285 msgid "stroke" msgstr "" #. Translators: When this option is enabled, dead keys will be #. announced when p
Re: New strings in Orca
Two more strings from bgo#570070, which was a request from our users to eliminate the word "item" from positional/index information in order to reduce the verbosity/chattiness of the spoken output: From: msgid "on item %(index)d of %(total)d" To:msgid "on %(index)d of %(total)d" From: msgid "item %(index)d of %(total)d" To: msgid "%(index)d of %(total)d" Will Willie Walker wrote: There's also a new string from bgo#585948 (just committed): "Translators: This checkbox toggles whether or not Orca says the child position (e.g., 'item 6 of 7')." msgid="Speak child p_osition" This also represents a UI change and we'll update the Orca docs accordingly. Thanks much for all your hard work, Will Joanmarie Diggs wrote: Hi all. I didn't realize that the string announcement period had already begun. Sorry! There are a number of string changes in Orca since the 13th: From bgo bug #588403: #. Translators: this command will move the mouse pointer #. to the current item without clicking on it. #. #: ../src/orca/default.py:151 msgid "Routes the pointer to the current item." msgstr "" #. Translators: Orca has a command that allows the user #. to move the mouse pointer to the current object. If #. for some reason Orca cannot identify the current #. location, it will speak this message. #. #: ../src/orca/default.py:5181 ../src/orca/default.py:5202 #: ../src/orca/default.py:5222 msgid "Could not find current location." msgstr "" From bgo bug #582506 (Use GtkBuilder instead of libglade): These are technically not new strings. But in the process of the conversion, I concluded that merely marking such generic words for translation wasn't ideal. So I gave them context. #. Translators: This refers to the default/typical voice used #. by Orca when presenting the content of the screen and other #. messages. #. #: ../src/orca/orca_gui_prefs.py:721 msgctxt "VoiceType" msgid "Default" msgstr "" #. Translators: This refers to the voice used by Orca when #. presenting one or more characters which is in uppercase. #. #: ../src/orca/orca_gui_prefs.py:725 msgctxt "VoiceType" msgid "Uppercase" msgstr "" #. Translators: This refers to the voice used by Orca when #. presenting one or more characters which is part of a #. hyperlink. #. #: ../src/orca/orca_gui_prefs.py:730 msgctxt "VoiceType" msgid "Hyperlink" msgstr "" From bgo bug #585417: #. Translators: different speech systems and speech engines work #. differently when it comes to handling pauses (e.g., sentence #. boundaries). This property allows the user to specify whether #. speech should be sent to the speech synthesis system immediately #. when a pause directive is enountered or if it should be queued #. up and sent to the speech synthesis system once the entire set #. of utterances has been calculated. #. #: ../src/orca/orca_gui_prefs.py:1529 ../src/orca/orca-setup.ui.h:26 msgid "Break speech into ch_unks between pauses" msgstr "" From bgo bug #585049: #. Translators: when the user selects (highlights) text in #. a document, Orca will speak information about what they #. have selected. #. #: ../src/orca/default.py:7774 msgid "paragraph selected down from cursor position" msgstr "" #: ../src/orca/default.py:7775 msgid "paragraph unselected down from cursor position" msgstr "" #: ../src/orca/default.py:7776 msgid "paragraph selected up from cursor position" msgstr "" #: ../src/orca/default.py: msgid "paragraph unselected up from cursor position" msgstr "" From bgo bug #588910: #. Translators: this is to inform the user of the presence #. of the red squiggly line which indicates that a given #. word is not spelled correctly. #. #: ../src/orca/default.py:4084 ../src/orca/default.py:8301 msgid "misspelled" msgstr "" #. Translators: this attribute specifies there is something "wrong" with #. the text, such as it being a misspelled word. See: #. https://developer.mozilla.org/en/Accessibility/AT-APIs/Gecko/TextAttrs #. #: ../src/orca/text_attribute_names.py:133 msgctxt "textattr" msgid "mistake" msgstr "" Note that the above "mistake" is a replacement for what used to be "invalid" which was removed as part of this bug. From bgo bug #575784: #. Translators: this is how someone would speak the name of the #. non-spacing diacritical key for the acute glyph #. #: ../src/orca/keynames.py:255 msgid "acute" msgstr "" #. Translat
Re: New strings in Orca
One more new string (well, an ngettext pair) that was the result of fixing bgo#363820. It's nice to have this nearly 3-year-old bug fixed. #. Translators: people can enter a string of text that is #. too wide for a spreadsheet cell. This string will be #. spoken if such a cell is encountered. #. #: ../src/orca/scripts/apps/soffice/speech_generator.py:341 #, python-format msgid "%d character too long" msgid_plural "%d characters too long" Thanks again for all your hard work, everyone. Will Willie Walker wrote: Two more strings from bgo#570070, which was a request from our users to eliminate the word "item" from positional/index information in order to reduce the verbosity/chattiness of the spoken output: From: msgid "on item %(index)d of %(total)d" To:msgid "on %(index)d of %(total)d" From: msgid "item %(index)d of %(total)d" To:msgid "%(index)d of %(total)d" Will Willie Walker wrote: There's also a new string from bgo#585948 (just committed): "Translators: This checkbox toggles whether or not Orca says the child position (e.g., 'item 6 of 7')." msgid="Speak child p_osition" This also represents a UI change and we'll update the Orca docs accordingly. Thanks much for all your hard work, Will Joanmarie Diggs wrote: Hi all. I didn't realize that the string announcement period had already begun. Sorry! There are a number of string changes in Orca since the 13th: From bgo bug #588403: #. Translators: this command will move the mouse pointer #. to the current item without clicking on it. #. #: ../src/orca/default.py:151 msgid "Routes the pointer to the current item." msgstr "" #. Translators: Orca has a command that allows the user #. to move the mouse pointer to the current object. If #. for some reason Orca cannot identify the current #. location, it will speak this message. #. #: ../src/orca/default.py:5181 ../src/orca/default.py:5202 #: ../src/orca/default.py:5222 msgid "Could not find current location." msgstr "" From bgo bug #582506 (Use GtkBuilder instead of libglade): These are technically not new strings. But in the process of the conversion, I concluded that merely marking such generic words for translation wasn't ideal. So I gave them context. #. Translators: This refers to the default/typical voice used #. by Orca when presenting the content of the screen and other #. messages. #. #: ../src/orca/orca_gui_prefs.py:721 msgctxt "VoiceType" msgid "Default" msgstr "" #. Translators: This refers to the voice used by Orca when #. presenting one or more characters which is in uppercase. #. #: ../src/orca/orca_gui_prefs.py:725 msgctxt "VoiceType" msgid "Uppercase" msgstr "" #. Translators: This refers to the voice used by Orca when #. presenting one or more characters which is part of a #. hyperlink. #. #: ../src/orca/orca_gui_prefs.py:730 msgctxt "VoiceType" msgid "Hyperlink" msgstr "" From bgo bug #585417: #. Translators: different speech systems and speech engines work #. differently when it comes to handling pauses (e.g., sentence #. boundaries). This property allows the user to specify whether #. speech should be sent to the speech synthesis system immediately #. when a pause directive is enountered or if it should be queued #. up and sent to the speech synthesis system once the entire set #. of utterances has been calculated. #. #: ../src/orca/orca_gui_prefs.py:1529 ../src/orca/orca-setup.ui.h:26 msgid "Break speech into ch_unks between pauses" msgstr "" From bgo bug #585049: #. Translators: when the user selects (highlights) text in #. a document, Orca will speak information about what they #. have selected. #. #: ../src/orca/default.py:7774 msgid "paragraph selected down from cursor position" msgstr "" #: ../src/orca/default.py:7775 msgid "paragraph unselected down from cursor position" msgstr "" #: ../src/orca/default.py:7776 msgid "paragraph selected up from cursor position" msgstr "" #: ../src/orca/default.py: msgid "paragraph unselected up from cursor position" msgstr "" From bgo bug #588910: #. Translators: this is to inform the user of the presence #. of the red squiggly line which indicates that a given #. word is not spelled correctly. #. #: ../src/orca/default.py:4084 ../src/orca/default.py:8301 msgid "misspelled" msgstr "" #. Translators: this attribute specifies there is something "wrong" with #. the text, such as it being a misspelled word. See: #. https://developer.mozilla.org/en/Acces
New string in Orca
Hi All:
As part of work on http://bugzilla.gnome.org/show_bug.cgi?id=591734, we
needed to expose the 'no break space' character (" " in HTML or
U+00a0). This added the 'no break space' string to Orca:
#. Translators: this is the spoken character for the no break space
#. character (e.g., " " in HTML -- U+00a0)
#.
#: ../src/orca/chnames.py:180
msgid "no break space"
Thanks!
Will
___
gnome-i18n mailing list
gnome-i18n@gnome.org
http://mail.gnome.org/mailman/listinfo/gnome-i18n
New strings for Orca
Hi All: A user had an excellent suggestion to add --debug and --debug-file options to the command line to enable the debug feature of Orca. Prior to this, users had to hand edit a file, which was a pain in the neck and was also error prone. We added these two strings to the usage text for the command line options: #. Translators: this enables debug output for Orca. The #. -MM-DD-HH:MM:SS portion is a shorthand way of saying that #. the file name will be formed from the current date and time with #. 'debug' in front and '.out' at the end. The 'debug' and '.out' #. portions of this string should not be translated (i.e., it will #. always start with 'debug' and end with '.out', regardless of the #. locale.). #. #: ../src/orca/orca.py:1461 msgid "Send debug output to debug--MM-DD-HH:MM:SS.out" #. Translators: this enables debug output for Orca and overrides #. the name of the debug file Orca will use for debug output if the #. --debug option is used. #. #: ../src/orca/orca.py:1468 msgid "Send debug output to the specified file" Thanks for all your hard work! Will ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
New string in orca.desktop file
Hi All: As part of http://bugzilla.gnome.org/show_bug.cgi?id=592741, which was done to meet the GNOME Goal for correct desktop files (see http://live.gnome.org/GnomeGoals/CorrectDesktopFiles), the following string was added to the orca.desktop file: +_GenericName=Screen Reader and Magnifier Thanks again for your hard work, Will ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Orca branched for gnome-2-28
Hi All: Immediately after releasing Orca v2.27.91 today, I branched Orca for gnome-2-28. The gnome-2-28 branch will be used for the remainder of the GNOME 2.28.x cycle and all new work will take place on master. Thanks everyone! Will ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
String Change Announcement: new strings for Orca
Greetings:
We added the following new strings to Orca's default.py module today:
# Translators: the 'flat review' feature of Orca
# allows the blind user to explore the text in a
# window in a 2D fashion. That is, Orca treats all
# the text from all objects in a window (e.g.,
# buttons, labels, etc.) as a sequence of words in a
# sequence of lines. The flat review feature allows
# the user to explore this text by the {previous,next}
# {line,word,character}. Previous will go backwards
# in the window until you reach the top (i.e., it will
# wrap across lines if necessary). This command will
# cause Orca to speak information about the current character
# Like its unicode value and other relevant information
#
_("Speaks unicode value of the current flat review character.")
# Translators: this is information about a unicode character
# reported to the user. The value is the unicode number value
# of this character in hex.
#
_("Unicode %s")
Thanks for all your hard work!
Will
___
gnome-i18n mailing list
gnome-i18n@gnome.org
http://mail.gnome.org/mailman/listinfo/gnome-i18n
gnome-2-14 branch for gnome-speech
This is to announce that a gnome-2-14 branch has been made for gnome-speech. It is based on the gnome-speech-0.3.9 release. Due to a recent discovery and fix of a DECtalk driver hang problem, I plan to have a gnome-speech-0.3.10 release based upon this branch for gnome-2.14 very soon. This release will contain only the fix for the DECtalk problem. No string changes, new functionality, or API/ABI changes will be made. The current GNOME CVS HEAD for gnome-speech contains additional functionality, which consists primarily of the new driver for speech dispatcher. It also includes the DECtalk driver fix. When it comes time for a new release, I will bump the version for gnome-speech to 0.4.0. Will PS - You may get this who knows how many times until I get my mailing list subscriptions straightened out. Sorry. ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Announcing new strings for new file in the orca module: orca.desktop.in
Hey All: With the acceptance of Orca into GNOME 2.16 (THANK YOU EVERYONE FOR YOUR SUPPORT), we've created a new orca.desktop.in file. This file lives in the top level directory of the orca module and contains the following strings: _Name=Orca Screen Reader and Magnifier _Comment=Assistive Technologies for Blind and Visually Impaired People Thanks! Will ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Announcing new strings for new file in the orca module: orca.desktop.in
I actually modeled the strings after Gnopernicus: [EMAIL PROTECTED]:~$ egrep '_Name|_Comment' gnome-head/gnopernicus/gnopi/gnopernicus.desktop.in _Name=Screen Reader and Magnifier _Comment=Assistive Technologies for Blind and Visually Impaired But...if the gnome-i18n and gnome-doc-list people will support (and perhaps suggest) a change after the string freeze period, I'm happy to do so. It's no biggy for me - all I have to do is write the English version. How about: _Comment=Present on screen information as speech or braille, or magnify the screen Will On Tue, 2006-08-08 at 11:13 +0100, Calum Benson wrote: > On 6 Aug 2006, at 13:46, Willie Walker wrote: > > > Hey All: > > > > With the acceptance of Orca into GNOME 2.16 (THANK YOU EVERYONE FOR > > YOUR > > SUPPORT), we've created a new orca.desktop.in file. This file > > lives in > > the top level directory of the orca module and contains the following > > strings: > > > > _Name=Orca Screen Reader and Magnifier > > _Comment=Assistive Technologies for Blind and Visually Impaired People > > Don't want to be a pain, but any chance you would consider a more > actively-worded comment (as per the HIG), like the one we suggested > for gnopernicus here? > > http://live.gnome.org/UsabilityTeam/Menu > > Cheeri, > Calum. > ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Announcing new strings for new file in the orca module: orca.desktop.in
> > It's no biggy for me - all I have to do is write the English > > version. How about: > > > > _Comment=Present on screen information as speech or braille, or magnify > > the screen > > Sounds reasonable, although should be "on-screen" I think. Okie dokie. So...since we're now in the "String Freeze" period, I think I need to get official approval from gnome-i18n and gnome-doc-list to make the change. The proposed change is to make the _Comment field for the orca.desktop.in file read as follows: _Comment=Present on-screen information as speech or braille, or magnify the screen Can I assume that no negative comments between now and Friday, 11-Aug, mean acceptance of this proposal? Thanks! Will ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Announcing new strings for new file in the orca module: orca.desktop.in
Committed orca.desktop.in. Thanks everyone! _Comment=Present on-screen information as speech or braille, or magnify the screen Will On Wed, 2006-08-09 at 16:07 +0200, Danilo Šegan wrote: > Hi Willie, > > Today at 15:30, Willie Walker wrote: > > > Okie dokie. So...since we're now in the "String Freeze" period, I think > > I need to get official approval from gnome-i18n and gnome-doc-list to > > make the change. > > Since we're early in the string freeze and this is a very tiny change, > be quick! (so, there goes your i18n approval) > > > Can I assume that no negative comments between now and Friday, 11-Aug, > > mean acceptance of this proposal? > > No response means no response. Only positive response means you can > actually go on with the string freeze breakage. > > Cheers, > Danilo ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Orca Spanish translation
Hi Francisco: > I have observed you have been commiting spanish translations to orca > directly without sending us a notice. The Spanish GNOME localization > team is working with ONCE, (a Spanish blind people organization) to make > orca localization consistent with other assistive technologies that are > being deployed in Spain and other Hispanoamerican countries. Sorry about that. The translations I received also came from someone affiliated with ONCE, Jorge Sandin, who also contributed some new (and useful) GUI work. > We seek to encourage collaboration among all the implied parties, just > to avoid duplication of work, so we suggest instead of commiting the > files, sending them to our list for revision, and we will take care of > it as soon as possible. You bet. Again, sorry if crossed some boundaries without realizing it. Will ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
String freeze break requested for Orca for GNOME 2.17.92
Hi All:
I'm requesting a string freeze break for Orca. The first one, which
is in src/orca/nautilus.py comes as a result of a direct request from
our user community. It helps users understand how many items they are
working with in a folder when they open it in nautilus. It is a
highly desired feature by our users.
src/orca/scripts/nautilus.py:
itemCountString = _(" %d items") % itemCount
The second is the result of me (my fault) forgetting to mark strings
as needing translation in our Gecko.py script for Firefox and
Thunderbird. I apologize greatly for this, as I'm usually the
anal-retentive internationalization guy on the team. :-(
src/orca/Gecko.py:
_("Dumps document content to stdout."))
_("Goes to next character."))
_("Goes to previous character."))
_("Goes to next word."))
_("Goes to previous word."))
_("Goes to next line."))
_("Goes to previous line."))
_("Goes to previous heading."))
_("Goes to next heading."))
_("Goes to previous chunk."))
_("Goes to next chunk."))
_("Switches between Gecko and Orca caret navigation."))
string = _("Gecko is controlling the caret.")
string = _("Orca is controlling the caret.")
Please let me know if this is OK.
Will
___
gnome-i18n mailing list
gnome-i18n@gnome.org
http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: String freeze break requested for Orca for GNOME 2.17.92
Hi All:
Due to various midair collisions, I'm getting the feeling that the
timing of this is all bad. We'll wait until GNOME 2.19.x.
Thanks,
Will
Willie Walker wrote:
> Hi All:
>
> I'm requesting a string freeze break for Orca. The first one, which
> is in src/orca/nautilus.py comes as a result of a direct request from
> our user community. It helps users understand how many items they are
> working with in a folder when they open it in nautilus. It is a
> highly desired feature by our users.
>
> src/orca/scripts/nautilus.py:
>
> itemCountString = _(" %d items") % itemCount
>
> The second is the result of me (my fault) forgetting to mark strings
> as needing translation in our Gecko.py script for Firefox and
> Thunderbird. I apologize greatly for this, as I'm usually the
> anal-retentive internationalization guy on the team. :-(
>
> src/orca/Gecko.py:
>
> _("Dumps document content to stdout."))
> _("Goes to next character."))
> _("Goes to previous character."))
> _("Goes to next word."))
> _("Goes to previous word."))
> _("Goes to next line."))
> _("Goes to previous line."))
> _("Goes to previous heading."))
> _("Goes to next heading."))
> _("Goes to previous chunk."))
> _("Goes to next chunk."))
> _("Switches between Gecko and Orca caret navigation."))
> string = _("Gecko is controlling the caret.")
> string = _("Orca is controlling the caret.")
>
> Please let me know if this is OK.
>
> Will
___
gnome-i18n mailing list
gnome-i18n@gnome.org
http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: String freeze break requested for Orca for GNOME 2.17.92
OK, after some arm twisting, I've been convinced to unretract this
request. So, I'm re-requesting it with the following amendment: we will
fix the ngettext issue with the " % items" string for nautilus.py.
The nautilus.py fix is the result of a user request, and is discussed
laboriously here: http://bugzilla.gnome.org/show_bug.cgi?id=350674.
We'd really like to get this fix in for GNOME 2.18 as it addresses a
usability issue.
The Gecko.py fix is just due to stupidity on my part for not marking the
strings as translatable to begin with.
Are these things we can get in for GNOME 2.18?
Will
Willie Walker wrote:
> Hi All:
>
> Due to various midair collisions, I'm getting the feeling that the
> timing of this is all bad. We'll wait until GNOME 2.19.x.
>
> Thanks,
>
> Will
>
> Willie Walker wrote:
>> Hi All:
>>
>> I'm requesting a string freeze break for Orca. The first one, which
>> is in src/orca/nautilus.py comes as a result of a direct request from
>> our user community. It helps users understand how many items they are
>> working with in a folder when they open it in nautilus. It is a
>> highly desired feature by our users.
>>
>> src/orca/scripts/nautilus.py:
>>
>> itemCountString = _(" %d items") % itemCount
>>
>> The second is the result of me (my fault) forgetting to mark strings
>> as needing translation in our Gecko.py script for Firefox and
>> Thunderbird. I apologize greatly for this, as I'm usually the
>> anal-retentive internationalization guy on the team. :-(
>>
>> src/orca/Gecko.py:
>>
>> _("Dumps document content to stdout."))
>> _("Goes to next character."))
>> _("Goes to previous character."))
>> _("Goes to next word."))
>> _("Goes to previous word."))
>> _("Goes to next line."))
>> _("Goes to previous line."))
>> _("Goes to previous heading."))
>> _("Goes to next heading."))
>> _("Goes to previous chunk."))
>> _("Goes to next chunk."))
>> _("Switches between Gecko and Orca caret navigation."))
>> string = _("Gecko is controlling the caret.")
>> string = _("Orca is controlling the caret.")
>>
>> Please let me know if this is OK.
>>
>> Will
>
>
___
gnome-i18n mailing list
gnome-i18n@gnome.org
http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: String freeze break requested for Orca for GNOME 2.17.92
Hi All:
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.
Thanks!
Will
Willie Walker wrote:
OK, after some arm twisting, I've been convinced to unretract this
request. So, I'm re-requesting it with the following amendment: we will
fix the ngettext issue with the " % items" string for nautilus.py.
The nautilus.py fix is the result of a user request, and is discussed
laboriously here: http://bugzilla.gnome.org/show_bug.cgi?id=350674. We'd
really like to get this fix in for GNOME 2.18 as it addresses a
usability issue.
The Gecko.py fix is just due to stupidity on my part for not marking the
strings as translatable to begin with.
Are these things we can get in for GNOME 2.18?
Will
Willie Walker wrote:
Hi All:
Due to various midair collisions, I'm getting the feeling that the
timing of this is all bad. We'll wait until GNOME 2.19.x.
Thanks,
Will
Willie Walker wrote:
Hi All:
I'm requesting a string freeze break for Orca. The first one, which
is in src/orca/nautilus.py comes as a result of a direct request from
our user community. It helps users understand how many items they are
working with in a folder when they open it in nautilus. It is a
highly desired feature by our users.
src/orca/scripts/nautilus.py:
itemCountString = _(" %d items") % itemCount
The second is the result of me (my fault) forgetting to mark strings
as needing translation in our Gecko.py script for Firefox and
Thunderbird. I apologize greatly for this, as I'm usually the
anal-retentive internationalization guy on the team. :-(
src/orca/Gecko.py:
_("Dumps document content to stdout."))
_("Goes to next character."))
_("Goes to previous character."))
_("Goes to next word."))
_("Goes to previous word."))
_("Goes to next line."))
_("Goes to previous line."))
_("Goes to previous heading."))
_("Goes to next heading."))
_("Goes to previous chunk."))
_("Goes to next chunk."))
_("Switches between Gecko and Orca caret navigation."))
string = _("Gecko is controlling the caret.")
string = _("Orca is controlling the caret.")
Please let me know if this is OK.
Will
Index: src/orca/scripts/nautilus.py
===
--- src/orca/scripts/nautilus.py (revision 2042)
+++ src/orca/scripts/nautilus.py (working copy)
@@ -33,7 +33,8 @@
import orca.speech as speech
import orca.util as util
-from orca.orca_i18n import _ # for gettext support
+from orca.orca_i18n import _# for gettext support
+from orca.orca_i18n import ngettext # for ngettext support
# #
@@ -100,7 +101,9 @@
elif child.role == rolenames.ROLE_TABLE:
itemCount = child.table.nRows
if itemCount != -1:
-itemCountString = " %d items" % itemCount
+itemCountString = ngettext(" %d item",
+ " %d items",
+ itemCount) % itemCount
break
return itemCountString
___
gnome-i18n mailing list
gnome-i18n@gnome.org
http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: String freeze break requested for Orca for GNOME 2.17.92
We retract this request and will address this and other i18n/l10n
issues for GNOME 2.19/2.20. As part of this retraction, we are
also pulling the special nautilus script from GNOME 2.18 and will
work to get it in for GNOME 2.19/2.20.
Thanks!
Will
PS - Regarding the question of concatenation of sentences: what
we do in many cases is concatenate phrases. Since we're
dealing with speech synthesis, our goal is to present the
most important information first - so we'll present the
most important phrase first followed by other phrases.
We also need to take care with how we use punctuation as
it tends to introduce too much dead space in speech
synthesis. So, we'll often concatenate the phrases
using " ". While the resulting output does not always
result in perfect grammar, but it does result in a more
compelling user experience.
I realize these goals may be in some tension with people
who are used to seeing text on a display, and I realize
we've also blown it in spots. I look forward to fixing
this for GNOME 2.20, but I'm going to need some
understanding that the Orca user is not the typical
GUI user and we need to present things/strings a little
differently to them.
Christian Rose wrote:
> On 2/22/07, Willie Walker <[EMAIL PROTECTED]> wrote:
>> Hi All:
>>
>> 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:
>
>> src/orca/scripts/nautilus.py:
>>
>> 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
> well.
> 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.
>
>
> Christian
___
gnome-i18n mailing list
gnome-i18n@gnome.org
http://mail.gnome.org/mailman/listinfo/gnome-i18n
Orca branched for gnome-2-18
Per the instructions at http://live.gnome.org/MaintainersCorner, we have created a new branch of Orca for GNOME 2.18. Note to you wonderful translators who are still working away, I'm not sure of the appropriate svn terminology to describe the revisions at the time I made the branch. Here's the commands I typed: $ svn stat $ svn update At revision 2094. $ svn cp svn+ssh://svn.gnome.org/svn/orca/trunk \ svn+ssh://svn.gnome.org/svn/orca/branches/gnome-2-18 Committed revision 2095. Aside from any critical show stoppers that might come up between now and the release of GNOME 2.18, we don't expect to make any further code changes to Orca for GNOME 2.18. Development will continue on trunk, however, and our main focus for GNOME 2.19/2.20 includes the following areas: * Continued work with the Firefox and Thunderbird teams to provide more compelling access to the Web and E-mail. * Address the i18n/l10n picture. We will make it a high priority goal to work with the i18n/l10n teams to address these for GNOME 2.19/2.20. Bug 412200 will be used to track this. Please be nice. We really want to do a good job here. * Continued work on features/requirements which are in the specification but not implemented yet. We track all of these at http://bugzilla.gnome.org/buglist.cgi?query=product%3Aorca. * "Rear view mirror" refactoring to clean up some of the cruftier portions of the code. This may also include the ability to better support multilingual text. * Continued development of the test harness, code coverage analysis, and regression tests for Orca. Thanks! Will ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
How to handle 'y' and 'n' questions from a terminal window
Hi: In Orca, we have a terminal-based configuration utility that asks yes and no questions. Is there a standard l10n mechanism or convention we can use to ask these types of questions and handle the response? An example question is: Enable echo by word? Enter y or n: Thanks! Will ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Marking command line options for translation?
Hi All: Is it good or bad practice to mark command line options for translation? Will, who is working away at improving the i18n/l10n story for Orca for GNOME 2.19.1 ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Handling phonetic/military spelling
Hi All: In Orca, there is a feature to spell words out via speech synthesis. The options include just sending each character of a word to the speech synthesis engine as well as performing phonetic/military spelling. The phonetic/military spelling substitutes a word for each letter. For example "abc" becomes "alpha bravo charlie" in English. We currently have the phonetic/military word substitutions for the letters a-z, and we handle this via a simple dictionary: the keys are the single characters and the values are the words. I'm curious about a few things: what other languages support phonetic/military spelling? Should we include their alphabet in a big dictionary? Should we do something else to make this more flexible to allow translators to extend the military/phonetic alphabet to their language (if so, how would we do this)? Thanks! Will ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Handling phonetic/military spelling
Hey All:
As an alternative representation, how about the following. This allows
a translator to more easily extend/modify the alphabet and phonetic
words to match their language:
"{'a': 'alpha', 'b': 'bravo', 'c': 'charlie', 'd': 'delta', 'e': 'echo',
'f': 'foxtrot', 'g': 'golf', 'h': 'hotel', 'i': 'india', 'j': 'juliet',
'k': 'kilo', 'l': 'lima', 'm': 'mike', 'n': 'november', 'o': 'oscar',
'p': 'papa', 'q': 'quebec', 'r': 'romeo', 's': 'sierra', 't': 'tango',
'u': 'uniform', 'v': 'victor', 'w': 'whiskey', 'x': 'xray', 'y':
'yankee', 'z': 'zulu'}"
The note to translators would say something like:
Translators: this is a structure to assist in the generation of
military-style spelling. For example, 'abc' becomes 'alpha bravo
charlie'. It is a simple structure that consists of pairs of 'letter':
'word(s)' separated by commas. For example, we see 'c': 'charlie'. The
complete set should consist of all the letters from the alphabet for
your language paired with the common military/phonetic word(s) used to
describe that letter. If more than one word is to be used, they should
all be inside the single quotes (e.g., 'w': 'double bourbon'). Note
that the form of this string is a programming language construct, so you
need to get the syntax right. If you want to test the syntax,
build/install Orca and then type the following command in a terminal
with the locale set to the locale you're translating to. If no errors
are emitted, you got it right:
python -c 'import orca.phonnames'
Will
Willie Walker wrote:
> Hi All:
>
> In Orca, there is a feature to spell words out via speech synthesis. The
> options include just sending each character of a word to the speech
> synthesis engine as well as performing phonetic/military spelling. The
> phonetic/military spelling substitutes a word for each letter. For
> example "abc" becomes "alpha bravo charlie" in English.
>
> We currently have the phonetic/military word substitutions for the
> letters a-z, and we handle this via a simple dictionary: the keys are
> the single characters and the values are the words.
>
> I'm curious about a few things: what other languages support
> phonetic/military spelling? Should we include their alphabet in a big
> dictionary? Should we do something else to make this more flexible to
> allow translators to extend the military/phonetic alphabet to their
> language (if so, how would we do this)?
>
> Thanks!
>
> Will
>
>
___
gnome-i18n mailing list
[EMAIL PROTECTED]
http://mail.gnome.org/mailman/listinfo/gnome-i18n
Please comment on Orca's *.pot file
Hi All: We made a big push for GNOME 2.19.1 to address a lot of the comments given to us by the translation team. We think we've addressed most of these comments as part of our work on http://bugzilla.gnome.org/show_bug.cgi?id=412200. Can you please take a look at the Orca pot file and let us know what we might have missed or done wrong? Since I'm not on this alias, and since we're using bug 412200 to track the work, please add your constructive comments to bug 412200. Thanks, and we're trying to do the best we can. :-) Will ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Two new strings for Orca ("bookmark entered" and "Notification %s")
Hi Translators: This is supposed to be a quick note on a string addition for Orca, but I can't resist the opportunity to thank you all for the work you do. Your translations for Orca are going a long way, helping greatly in getting GNOME accepted in very large distributions. For example, at GUADEC last week, we learned that accessibility played a major role in the decision to use GNOME for Guadalinex. Guadalinex saw 185,000 deployments in Spain last year. Without the Spanish translation for Orca, I don't think this would have been possible. I'm also seeing signs of this type of decision being made in other countries, so your work is very very valuable. Way to go, everyone! Now, for the string change announcement. We blew it and forgot to add some files to Orca's POTFILES.in. For more information, see: http://bugzilla.gnome.org/show_bug.cgi?id=459080. In adding the missing files, we exposed some additional strings for translation. When I look at what is already in the most complete translations (Spanish and Swedish) and compare them to the new strings that are now exposed, I see the following strings (just two of them): #. Translators: this announces that a bookmark has been entered. #. Orca allows users to tell it to remember a particular spot in an #. application window and provides keystrokes for the user to jump to #. those spots. These spots are known as 'bookmarks'. #. #: ../src/orca/bookmarks.py:72 msgid "bookmark entered" #. Translators: This denotes a notification to the user of some sort. #. #: ../src/orca/scripts/notification-daemon.py:66 #, python-format msgid "Notification %s" Thanks everyone! Sincerely, Willie Walker Orca Project Lead ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Orca branched for GNOME 2.20
Hi All: With the release of Orca v2.19.6, we've branched Orca for GNOME 2.20. The Orca v2.19.6 sources represent the beginning of the branch (svn.gnome.org/svn/orca/branches/gnome-2-20), and we will soon be starting some aggressive refactoring work on the trunk. Between now and the release of GNOME 2.20, we only expect to be making high visibility bug fixes, with hopefully zero string or GUI changes. Thanks everyone! Will ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Two new strings for Orca ("Default Synthesizer" and "%s default voice")
Hi All:
Sorry for adding two more strings. :-( These are new for the Speech
Dispatcher support:
# Translators: "Default Synthesizer" will appear in the list of available
# speech engines as a special item. It refers to the default engine
# configured within the speech subsystem. Apart from this item, the user
# will have a chance to select a particular speech engine by its real
# name, such as Festival, IBMTTS, etc.
#
_SERVER_NAMES = {DEFAULT_SERVER_ID: _("Default Synthesizer")}
# Translators: This string will appear in the list of
# available voices for the current speech engine. %s will be
# replaced by the name of the current speech engine, such as
# "Festival default voice" or "IBMTTS default voice". It
# refers to the default voice configured for given speech
# engine within the speech subsystem. Apart from this item,
# the list will contain the names of all available "real"
# voices provided by the speech engine.
#
self._default_voice_name = _("%s default voice") % id
Thanks, and I hope we have no more (or at least very very few) strings
to add before the string freeze.
Will
(Orca Project Lead)
___
gnome-i18n mailing list
gnome-i18n@gnome.org
http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Orca translation
Hi Claude:
Orca will do an uppercase check (string.decode("UTF-8").isupper() in
Python) on the characters and change the pitch of the speech voice that
it uses to speak the character. If you keep the translation so that it
has uppercase letters, the behavior to change the pitch should carry
over to the new locale. That is, I would choose "A GRAVE" from the
below since it is in all uppercase.
At some point, we plan to work on verbalizing the notion of capital
letters (e.g., saying "capital a grave") in addition to changing the
pitch. This will be an option, however, and will consist of us
optionally adding some word for 'capital' if the user wants it. I'm
guessing the position of the word for 'capital' is going to depend upon
the locale, though, and we'll need to work with you i18n folks on
that. :-)
http://bugzilla.gnome.org/show_bug.cgi?id=354459
Hope this helps, and thanks for your work!
Will
PS - I'm headed out for a long weekend. Should be back by Monday at 3PM
EDT.
On Sat, 2007-09-01 at 11:04 +0200, Claude Paroz wrote:
> Hi Willie,
>
> I have a question about upper case pronounced letter, eg. "A GRAVE".
> Does the system automatically tells this is an uppercase letter or
> should I write it ? Is the "GRAVE" case important?
>
> What's the best option among these possibilities (majuscule=uppercase):
> A GRAVE
> a majuscule grave
> A grave
>
> Thanks.
>
> Claude
>
___
gnome-i18n mailing list
gnome-i18n@gnome.org
http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: String additions to 'orca.gnome-2-20'
D'Oh! I didn't realize that was going to go in. I'm working with the team to pull that string out now. I don't like it and will work with the team to resolve this before the release. Thanks, and sorry. :-( Will Claude Paroz wrote: > Le vendredi 12 octobre 2007 à 20:32 +0100, GNOME Status Pages a écrit : > >> This is an automatic notification from status generation scripts on: >> http://l10n.gnome.org/. >> >> There have been following string additions to module 'orca.gnome-2-20': >> >> + " " >> + "Display help information for Orca" >> >> Note that this doesn't directly indicate a string freeze break, but it >> might be worth investigating. >> > > Le jeudi 11 octobre 2007 à 21:39 -0400, Willie Walker a écrit : > >> Hi All: >> >> As part of http://bugzilla.gnome.org/show_bug.cgi?id=475110, Matthew >> East updated the accessibility guide to include help documentation for >> Orca. This helped enable us to support the request to enable help in >> Orca: http://bugzilla.gnome.org/show_bug.cgi?id=474958. >> >> In working on bug 474958, we decided that we needed to add a "help" >> button to the Orca main window in addition to the one that is already in >> the preferences dialog. This UI Freeze Break Request is to request >> permission to add the Help button to the main window for Orca v2.20.1 >> (for GNOME v2.20.1). No new strings have been added. >> > > E... :-) > > Claude > > ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: String additions to 'orca.gnome-2-20'
We pulled the string (but kept the new "Help" button). Sorry about that. Will Claude Paroz wrote: > Le vendredi 12 octobre 2007 à 20:32 +0100, GNOME Status Pages a écrit : > >> This is an automatic notification from status generation scripts on: >> http://l10n.gnome.org/. >> >> There have been following string additions to module 'orca.gnome-2-20': >> >> + " " >> + "Display help information for Orca" >> >> Note that this doesn't directly indicate a string freeze break, but it >> might be worth investigating. >> > > Le jeudi 11 octobre 2007 à 21:39 -0400, Willie Walker a écrit : > >> Hi All: >> >> As part of http://bugzilla.gnome.org/show_bug.cgi?id=475110, Matthew >> East updated the accessibility guide to include help documentation for >> Orca. This helped enable us to support the request to enable help in >> Orca: http://bugzilla.gnome.org/show_bug.cgi?id=474958. >> >> In working on bug 474958, we decided that we needed to add a "help" >> button to the Orca main window in addition to the one that is already in >> the preferences dialog. This UI Freeze Break Request is to request >> permission to add the Help button to the main window for Orca v2.20.1 >> (for GNOME v2.20.1). No new strings have been added. >> > > E... :-) > > Claude > > ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: String additions to 'orca.gnome-2-20'
Darn! So sorry about that. I'm not sure why it was done that way, but I just fixed it. Hopefully this is the last surprise. I just did a diff between the orca.pot from the Orca v2.20.0.1 tag and the gnome-2-20 branch, and it looks like we should be set. The only difference is that we actually removed two strings by taking advantage of stock buttons. Will Claude Paroz wrote: > Le samedi 13 octobre 2007 à 00:38 +0200, Kenneth Nielsen a écrit : > >> What is this? >> >> #: ../src/orca/orca-mainwin.glade.h:1 >> msgid " " >> msgstr "" >> > > Hmmm... this seems a rather ugly way to space between two buttons in a > glade file. Unfortunately, I'm not used to Glade to suggest a better > way, but please set at least the translatable property to "no" for this > 'space' string. > > Regards, > > Claude > > ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
String changes for Orca
Hi All: Thanks so much for all your hard work translating Orca. The Orca team and end users definitely appreciate it! We ran into an issue with Orca where we were outside the boundaries of the Section 508 guidelines, which is a definite bad thing for us to do: http://bugzilla.gnome.org/show_bug.cgi?id=440490#c33. The main issue is that we required double and triple pressing of keys to get features that could not otherwise be obtained via other means. As a result of this, we needed to allow people to rebind the double/triple press keys to single press operations. This required some rework in our keybinding code and exposed some new strings (documented in the orca.pot file) and changed/removed others: New strings: msgid "(double click)" msgid "(triple click)" msgid "Clears the dynamic column headers." msgid "Clears the dynamic row headers" msgid "Performs the basic where am I operation." msgid "Performs the detailed where am I operation." msgid "Phonetically speaks the current flat review character." msgid "Phonetically spells the current flat review item or word." msgid "Phonetically spells the current flat review line." msgid "Speaks the current flat review item or word." msgid "Speaks the status bar." msgid "Speaks the title bar." msgid "Spells the current flat review item or word." msgid "Spells the current flat review line." Removed strings: msgid "Performs the where am I operation." msgid "Speaks or spells the current flat review item or word." msgid "Speaks the title bar or status bar." Changes: From: msgid "Dynamic column header set for row " To: msgid "Dynamic column header set for row %d" While I realize we're at the tail end of the "String Change Announcement Period" (http://live.gnome.org/TwoPointTwentyone), I still feel compelled to apologize for this change as I realize it adds a bunch of new strings. It is a very serious accessibility problem, however, and I really do not think Orca should ship without the fix. Thanks! Will ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Orca branched for GNOME 2.22
Hi All: With the release of Orca v2.21.92, we've branched Orca for GNOME 2.22. The Orca v2.21.92 sources represent the beginning of the branch (svn.gnome.org/svn/orca/branches/gnome-2-22). Thanks everyone! Will ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
String and UI change (additions) for Orca
Hi All: For work on http://bugzilla.gnome.org/show_bug.cgi?id=540123, we have added new strings and a new GUI component to Orca. This work was contributed by our newest Orca community member, Mesar Hameed, and adds functionality that has been sought after by a number of users. The new UI component is a "Speak tutorial messages" on the "Speech" tab of the Orca preferences GUI. When checked, it tells Orca to speak tutorial messages for how to interact with components when a user lands on them (e.g., "Press space to toggle."). The new strings are as follows: #: ../src/orca/orca-setup.glade.h:134 msgid "Speak tutorial messages" #. Translators: this is a tip for the user on how to toggle a checkbox. #: ../src/orca/tutorialgenerator.py:154 msgid "Press space to toggle." #. Translators: this is a tip for the user on how to interact #. with a combobox. #: ../src/orca/tutorialgenerator.py:180 msgid "Press space to expand, and use up and down to select an item." #. Translators: this is the tutorial string for when first landing #. on the desktop, giving tips on how to navigate. #. Also describing how to access the menues. #: ../src/orca/tutorialgenerator.py:211 msgid "" "To move to items, use either the arrow keys, or type ahead searching. To get " "to the system menues press the alt+f1 key." #. Translators: If this application has more than one unfocused alert or #. dialog window, inform user of how to refocus these. #: ../src/orca/tutorialgenerator.py:217 msgid "Press alt+f6 to give focus to child windows." #. Translators: this is the tutorial string when navigating lists. #: ../src/orca/tutorialgenerator.py:250 msgid "Use up and down to select an item." #. Translators: this represents the state of a node in a tree. #. 'expanded' means the children are showing. #. 'collapsed' means the children are not showing. #. this string informs the user how to collapse the node. #: ../src/orca/tutorialgenerator.py:279 ../src/orca/tutorialgenerator.py:427 msgid "To collapse, press shift plus left." #. Translators: this represents the state of a node in a tree. #. 'expanded' means the children are showing. #. 'collapsed' means the children are not showing. #. this string informs the user how to expand the node. #: ../src/orca/tutorialgenerator.py:285 ../src/orca/tutorialgenerator.py:433 msgid "To expand, press shift plus right." #. Translators: This is the tutorial string for when landing #. on text fields. #: ../src/orca/tutorialgenerator.py:317 msgid "Type in text." #. Translators: this is the tutorial string for landing #. on a page tab, we are informing the #. user how to navigate these. #: ../src/orca/tutorialgenerator.py:345 msgid "Use left and right to view other tabs." #. Translators: this is the tutorial string for activating a push button. #: ../src/orca/tutorialgenerator.py:370 msgid "To activate press space." #. Translators: this is the tutorial string for when landing #. on a spin button. #: ../src/orca/tutorialgenerator.py:397 msgid "" "Use up or down arrow to select value. Or type in the desired numerical value." #. Translators: this is a tip for the user, how to navigate radiobuttons. #: ../src/orca/tutorialgenerator.py:584 msgid "Use arrow keys to change." #. Translators: this is a tip for the user, how to navigate menues. #: ../src/orca/tutorialgenerator.py:608 msgid "" "To navigate, press left or right arrow. To move through items press up or " "down arrow." #. Translators: this is a tip for the user, how to #. navigate into sub menues. #: ../src/orca/tutorialgenerator.py:613 msgid "To enter sub menu, press right arrow." #. Translators: this is the tutorial string for when landing #. on a slider. #: ../src/orca/tutorialgenerator.py:645 msgid "" "To decrease press left arrow, to increase press right arrow. To go to " "minimum press home, and for maximum press end." Thank you! Sincerely, Willie Walker (Orca Project Lead) ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
String change for Orca
We have made a string change to Orca in response to a bug filed from a translator: http://bugzilla.gnome.org/show_bug.cgi?id=548380. The change is to allow for different ordering of the words in an utterance, and it accomplishes this using special formating of the string. The old way was this: #. Translators: Orca will tell you how many characters #. are repeated on a line of text. For example: "22 #. space characters". The %d is the number and the %s #. is the spoken word for the character. #. #: ../src/orca/default.py:6289 #, python-format msgid "%d %s character" msgid_plural "%d %s characters" The new way is this: #. Translators: Orca will tell you how many characters #. are repeated on a line of text. For example: "22 #. space characters". The %d is the number and the %s #. is the spoken word for the character. #. #: ../src/orca/default.py:6290 #, python-format msgid "%(count)d %(repeatChar)s character" msgid_plural "%(count)d %(repeatChar)s characters" Thanks! Willie Walker (Orca Project Lead) ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: GDM trunk will be used for GNOME 2.24.
While I disagree with Brian's assessment (I think he tends to lean more to the 'it's OK as long as an able-bodied sysadmin can configure the system for the disabled user' side than the 'let the user be independent' side), I'll support the decision nonetheless. Will Vincent Untz wrote: Le lundi 22 septembre 2008, à 09:46 -0400, Matthias Clasen a écrit : On Sun, Sep 21, 2008 at 8:19 PM, Andre Klapper <[EMAIL PROTECTED]> wrote: The release-team is going to use gdm trunk for GNOME 2.24. Note that most release-team members have mixed feelings. Entire discussion would have been less frustrating if gdm developers had been more responsible to the concerns shared in discussions. Maybe just my point of view. Translations of gdm trunk are in a good shape. Distributors: Old gdm is still available in case you hit a regression. I'm surprised by this turn of events, after Vincent decreed that we'd go with 2.20 on Friday... See http://mail.gnome.org/archives/release-team/2008-September/msg00251.html Vincent ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Any pending Orca translations for 2.24.0?
Hey All: I must say you all are awesome for all the hard work you've been doing with Orca translations. I've been delaying the release of Orca so as many translations as possible could get in. Are there any translations left to get in? I need to start doing the release soon, but if there are a few translations just about ready to go, I can wait. Thanks again for your work! Will (I'll wait until 19:00UTC to do the Orca release) ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Orca has branched for GNOME 2.24
Hi All: We just branched Orca for GNOME 2.24. I forgot to do this when we released Orca v2.24.0 (D'Oh!). orca/branches/gnome-2-24 starts with Orca v2.24.1, which was created today. Will ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
String freeze break request for Orca 2.24.2
Hi All:
We have a couple new features that we'd really like to get into Orca
2.24.2. While I realize we *could* wait until 2.26, these features are
of the high impact, low risk category and will add two highly requested
features to Orca.
The first allows users to determine the text attributes of the contents
of a web page, which is very important because the attributes are often
the only means by which important information is expressed (e.g.,
misspelling). To get this functionality, the user presses an Orca
keyboard combination and the font attribute information will be spoken.
In addition, the user also encounters these strings when configuring
Orca to tell it which text attributes should be presented to them.
Because of the extreme usefulness of this functionality, we are willing
to take the risk that users in non-English locales might encounter
strings that have not been translated yet.
# Translators: this attribute specifies there is something "wrong" with
# the text, such as it being a misspelled word. See:
# https://developer.mozilla.org/en/Accessibility/AT-APIs/Gecko/TextAttrs
#
# ONLY TRANSLATE THE PART AFTER THE PIPE CHARACTER |
#
_textAttributeTable["invalid"] = Q_("textattr|invalid")
# Translators: this is one of the text attribute values for the
following
# text attributes: "invalid". It is an indication that the text is not
# spelled correctly. See:
# https://developer.mozilla.org/en/Accessibility/AT-APIs/Gecko/TextAttrs
#
# ONLY TRANSLATE THE PART AFTER THE PIPE CHARACTER |
#
_textAttributeTable["spelling"] = Q_("textattr|spelling")
# Translators: this is one of the text attribute values for the
following
# text attributes: "strikethrough." It refers to the line style.
#
# ONLY TRANSLATE THE PART AFTER THE PIPE CHARACTER |
#
_textAttributeTable["solid"] = Q_("textattr|solid")
# Translators: this is one of the text attribute values for the
following
# text attributes: "justification". In Gecko, when no justification has
# be explicitly set, they report a justification of "start".
#
# ONLY TRANSLATE THE PART AFTER THE PIPE CHARACTER |
#
_textAttributeTable["start"] = Q_("textattr|no justification")
The second is part of a feature that allows the user to make more
efficient use of the braille display. While this new string is
typically not encountered by end users, it is still something that
might be exposed nonetheless:
# Translators: this is a command for a button on a refreshable braille
# display (an external hardware device used by people who are blind).
# When pressing the button, it instructs the braille display to freeze.
#
command_name[CMD_FREEZE] = _("Freeze")
Comments?
Will
___
gnome-i18n mailing list
gnome-i18n@gnome.org
http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: String freeze break request for Orca 2.24.2
I got one private e-mail for a thumbs up, and another saying 2.24.x really is at feature freeze. So, the Orca team discussed whether to push one of these as a bug fix or not (the Firefox attributes) and ended up decided to not do either for 2.24.x. Thanks! Will On Nov 6, 2008, at 7:46 AM, Vincent Untz wrote: Le jeudi 30 octobre 2008, à 08:56 -0400, Willie Walker a écrit : Hi All: We have a couple new features that we'd really like to get into Orca 2.24.2. While I realize we *could* wait until 2.26, these features are of the high impact, low risk category and will add two highly requested features to Orca. I'm reading old mails, and didn't see a reply to this. Ping? Or does "no reply" mean "no way"? Vincent -- Les gens heureux ne sont pas pressés. ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Bug 569118 - Use C_() instead of Q_() with context (orca)
Hi All:
I'm looking at http://bugzilla.gnome.org/show_bug.cgi?id=569118, which
is a request to migrate to C_ from Q_. Doing this in the C programming
language seems pretty straightforward, but I'm puzzled about how to do
it in Python.
The current Orca code does the equivalent of this:
def Q_(s):
s = _(s)
s = s[s.find('|')+1:]
return s
This was easy to do since we controlled the whole string. Now that a
context is explicitly called out with the C_ method, it seems like we
might need to make a different gettext method call. I'm not quite sure
what to do.
Is there a Python precedence that exists that I can take a look at?
Will
___
gnome-i18n mailing list
gnome-i18n@gnome.org
http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Bug 569118 - Use C_() instead of Q_() with context (orca)
Hey All:
We've had some good discussion at
http://bugzilla.gnome.org/show_bug.cgi?id=569118 for how to handle
Python files.
http://bugzilla.gnome.org/show_bug.cgi?id=569118#c9 provides the Python
equivalent for C_.
http://bugzilla.gnome.org/show_bug.cgi?id=569118#c17 provides a script
that hammers through the *.po files to change them from Q_ form to C_ form.
I've attached two patches to the bug for Orca - one for the source code
and another for the *.po files. It all seems to work fine in my testing
between the C locale and the en_GB locale -- I made some temporary mods
to the en_GB.po file to make sure I was getting the right string for the
right context.
In the past, I was slapped seriously by the l10n team for touching *.po
files. So, I'm requesting permission here before I check in the *.po
changes. Is this OK with you all?
Will
Willie Walker wrote:
Hi All:
I'm looking at http://bugzilla.gnome.org/show_bug.cgi?id=569118, which
is a request to migrate to C_ from Q_. Doing this in the C programming
language seems pretty straightforward, but I'm puzzled about how to do
it in Python.
The current Orca code does the equivalent of this:
def Q_(s):
s = _(s)
s = s[s.find('|')+1:]
return s
This was easy to do since we controlled the whole string. Now that a
context is explicitly called out with the C_ method, it seems like we
might need to make a different gettext method call. I'm not quite sure
what to do.
Is there a Python precedence that exists that I can take a look at?
Will
___
gnome-i18n mailing list
gnome-i18n@gnome.org
http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Bug 569118 - Use C_() instead of Q_() with context (orca)
Leonardo F. Fontenelle wrote: Em Ter, 2009-01-27 às 14:09 -0500, Willie Walker escreveu: In the past, I was slapped seriously by the l10n team for touching *.po files. So, I'm requesting permission here before I check in the *.po changes. Is this OK with you all? This might be more to the point: for file in po/*.po; do sed -i "s+msgid \"\([^|]*\)|+msgctxt \"\1\"\nmsgid \"+" $file done Heh. But yes, let's see what happens to nl.po before doing it for every file :) Comment #23 from the bug (http://bugzilla.gnome.org/show_bug.cgi?id=569118#c23) "Thanks, Willie. This approach to update PO files seems to work quite well. The nl.po patch looks good, please commit nl.po for me. Thanks again :) " I also separated the *.po diffs into individual files here: http://master.gnome.org/~wwalker/569118/ This change touches a number of files, so I'd like to get it in sooner than later so as to avoid needing to keep up with a moving target. So, I'll hold off until tomorrow afternoon (US Eastern). If there are great cries of "NO! NO! NO!", I won't check it in. Otherwise, I'll check it in. Will ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Bug 569118 - Use C_() instead of Q_() with context (orca)
Gabor Kelemen wrote: Willie Walker írta: This change touches a number of files, so I'd like to get it in sooner than later so as to avoid needing to keep up with a moving target. Looks ok for hu.po. Thanks! Only a side note: the lines like #. ONLY TRANSLATE THE PART AFTER THE PIPE CHARACTER | are now unnecessary, please throw them out of the source files. The patch at http://bugzilla.gnome.org/attachment.cgi?id=127348 tosses them already. Thanks! Will ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Bug 569118 - Use C_() instead of Q_() with context (orca)
Leonardo F. Fontenelle wrote: Em Ter, 2009-01-27 às 14:09 -0500, Willie Walker escreveu: In the past, I was slapped seriously by the l10n team for touching *.po files. So, I'm requesting permission here before I check in the *.po changes. Is this OK with you all? This might be more to the point: for file in po/*.po; do sed -i "s+msgid \"\([^|]*\)|+msgctxt \"\1\"\nmsgid \"+" $file done BTW, just a quick comment that this doesn't catch mistakes where the translator translated the entire Q_ string rather than translating just the stuff after the "|". Orca's ar.po file, for example, appears to have several cases of this. The second "sed" at http://bugzilla.gnome.org/show_bug.cgi?id=569118#c17 fixes those. Note that the scripts are also making an assumption that the "|" character only shows up in strings for the purposes of the Q_ form. So, if someone has put the "|" character in something other than the Q_ form, the scripts will catch those and split them. As a result, one should carefully examine the files to make sure the expected changes have been made. Will ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Bug 569118 - Use C_() instead of Q_() with context (orca)
Hey Everyone: Thanks much for the conversation around this. Just to follow up, we accomplished this: 1) Came up with a good plan for Python and applied it to accerciser and orca: http://bugzilla.gnome.org/show_bug.cgi?id=569118 http://bugzilla.gnome.org/show_bug.cgi?id=569341 2) Added comments to http://live.gnome.org/GnomeGoals/MsgctxtMigration to help others in the same boat. Will ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
