Thanks Andre!  These are the first complaints we've heard about l10n/translation for Orca, even though people have been writing translations for it for quite a while now.  We'll definitely look at doing a better job for GNOME 2.20, and will engage the GTP folks for more help.

hi willie,

i'd be happy to work things out for GNOME 2.20 together with you. i'm not an i18n guy, but (after some years with evolution) i think that i've got a basic understanding for stuff that could improve the situation.

yeah, translators are way to quiet with regard to translation issues! i've taken a look into several .po files in the last weeks just to get an idea of gnome's problems, and i now have the deepest respect for translators... :-)

Here's a comment from bug 408729.  I'll close that one out and we can keep this bug open as a general l10n meta-bug:

src/orca/scripts/nautilus.py:

                        itemCountString = _(" %d items") % itemCount

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

*** Bug 408729 has been marked as a duplicate of this bug. ***

*** Bug 413105 has been marked as a duplicate of this bug. ***

*** Bug 413082 has been marked as a duplicate of this bug. ***

From the orca-list:

Halim Sahin wrote:
> Perhaps a little bug:
> 
> I am getting in German
> Strich Bindestrich,
> after typing only one -
> The Strich comes from the german translation and the Bindestrich perhaps 
> directly from the synthesizer.

(In reply to comment #7)
> From the orca-list:
> 
> Halim Sahin wrote:
> > Perhaps a little bug:
> > 
> > I am getting in German
> > Strich Bindestrich,
> > after typing only one -
> > The Strich comes from the german translation and the Bindestrich perhaps 
> > directly from the synthesizer.

Oops - two things.  This came from direct e-mail to me and it is not an l10n issue.  Logging this as bug 413457.

In orca_console_prefs.py the user has to answer a couple of questions with 'y' or 'n'. As far as I see there is no way to exchange 'y' and 'n' by using the common l10n mechanisms. So the user has always answer 'y' or 'n' - even if the words for "yes" and "no" in the user's preferred language start with other letters. Or have I just missed something?

From hermann on the Orca mailing list:

"where can I correct a lack in translation of Orca to German?
When I press the space key, i hear the word "space", but pronounced in
German, which sounds a bit silly. But when I move the cursor over a
space, for example in this text, i hear the correct German word,
"leerzeichen". Is there a way to correct this? In /orca/po/de.po there
is the correct translation, however it isn't invoked all the time (see
my explanation).
Do I have to add something?"

I've had a few mail exchanges with the developers and was encouraged to add some of the issues here. In general I would say: comments! Not all translation teams have users of all software (nor the time to get acquainted with it). So if you use terms that are very specific to the software you make you should explain them. (Actually a good explanation might help translators find a better translation even if they do know the program. Users and developers might think differently about a certain feature and so having the developers point of view might give better translations)
The term "flat review" comes into mind.

The long list of widgets in rolenames.py could also have used some explanation:
Does preserving the length of the abbreviations matter?
What are the camelcase strings used for and should they also be written with camelcase in my language?

The word "desktop" i ambiguous and since it is used in both meanings of the word it should definitely have a comment attached to it.

Oh yes and then a big +1 on the "don't split sentences". It's bad ! *G*
Spread the word ;)

Regards Kenneth Nielsen

PS: Oh and on another note. Actually a few, what appears to be, inline code comments have made it into the .po file also. I guess by accident. Now those comments we don't need ;)

> In general I would say: comments! Not all translation
> teams have users of all software (nor the time to get acquainted with it). So
> if you use terms that are very specific to the software you make you should
> explain them. 

OK, I'm starting to look at this -- I want to give our translators plenty of time to work on the updated translations.  

I think I figured out that if a comment precedes a _("") line, it will automatically get added to the po file.  This helps, and I can go through the po files and *.py files to make sure things have appropriate comments for starters.

(In reply to comment #9)
> In orca_console_prefs.py the user has to answer a couple of questions with 'y'
> or 'n'. As far as I see there is no way to exchange 'y' and 'n' by using the
> common l10n mechanisms. So the user has always answer 'y' or 'n' - even if the
> words for "yes" and "no" in the user's preferred language start with other
> letters. Or have I just missed something?
> 

I need help here.  Are there common l10n mechanisms for exchanging 'y' and 'n' for console based input?

refering to comment #13:
good question for the gnome-i18n mailing list.

Created attachment 85471 [details] [review]
Start adding comments for translators

This is just the start of working on bug 412200.  I'm just working my way from the top of a po file to the bottom, making sure:

1) There are useful comments for translators and unuseful comments are removed
2) We avoid the nasty concatenation of strings and blank spaces to make phrases
3) We incorporate ngettext where needed
4) Whatever else comes up

Note to people looking at this: remember that Orca is a different beast.  It outputs spoken language via speech and an alternative written form of language using braille.  Both are much different media than graphical user interfaces.  The temporal nature of speech combined with the need to present the most important information first can result in ungrammatical (but desirable) utterances.  The limited output of a braille display (typically 40 characters) can also result in some things that may seem unsavory to people used to large displays.

As a result, there will still be some concatentation going on, but the intent will be to concatenate utterances from phrases.

(In reply to comment #13)
> (In reply to comment #9)
> > In orca_console_prefs.py the user has to answer a couple of questions with 'y'
> > or 'n'. As far as I see there is no way to exchange 'y' and 'n' by using the
> > common l10n mechanisms. So the user has always answer 'y' or 'n' - even if the
> > words for "yes" and "no" in the user's preferred language start with other
> > letters. Or have I just missed something?
> > 
> 
> I need help here.  Are there common l10n mechanisms for exchanging 'y' and 'n'
> for console based input?
> 

Please excuse my lousy bug description. I just wanted to express that you can't translate these 'y' and 'n' within the po-files. I just noticed that all other strings that can be translated well are enclosed in double quotes (") but these 'y' and 'n' are just enclosed in single quotes ('). Maybe this helps you to find the problem (sorry, I'm neither an expert in Python nor in the usage of gnu gettext).

Created attachment 85477 [details] [review]
More comments for translators

More comments for translators and also unmarked some debug strings as things needing translating.  I'm now at my first "uh oh...we need to fix this" msg.  Will get to that soon.

Created attachment 85478 [details] [review]
Patch to use ngettext for presentation of number of tabs and spaces on a line

NOTE folks scratching their heads about the use of " " for concatenation.  This is one of those cases where we just build up a spoken utterance from discrete phrases.  For example: "one space" + " " + "two tabs".  For all intents and purposes, they are separate phrases, but we concatenate them together to send to the speech synthesis engine as one string so as to avoid unnecessary pauses caused by the speech synthesis engine.

==========
generally:

i myself would prefer to not have an empty line at the end of the comment, because without it's easier and faster to read the po file.

willie, if you want to test the results of adding comments yourself, you can take a look at the empty translation file by going to the orca/po directory, running "intltool-update --pot", and then opening the resulting .pot file.

these patches will definitely improve the situation, but let's try to only add comments where needed, otherwise the po file will become hard to read.
but nearly all of your comments are needed in my opinion, so: good work! :-)

==========

   # Translators: this represents an item on the screen that has
   # been set insensitive (or grayed out).
   return [_("grayed")]

how is this spoken in the context? can i imagine that the screenreader reads all the items in the menu, and for the insensitive item X the screenreader says "X grayed"? i'm just afraid again that we're splitting sentences, or that there are languages out there that would have to say "grayed: X" instead.

also, if i remember correctly, it's enough to add *one* comment to translatable terms that are used more than once, e.g. "collapsed" or "blank" - comments will just be concatenated, so currently the comment would be printed several times in the .po file in front of the translatable term.

==========

   Script.sayAll,
   # Translators: the Orca "SayAll" command allows the
   # user to press a key and have the entire document in
   # a window be automatically spoken to the user.  If
   # the user presses any key during a SayAll operation,
   # the speech will be interrupted and the cursor will
   # be positioned at the point where the speech was
   # interrupted.
  _("Speaks entire document."))

i think you should not mentioned the "SayAll" command here, because it's not "interesting"/visible for the translator, and it is not part of the string to translate. same goes for "Searches for the next instance of a string." i'd say - perhaps we don't need a comment here at all, it's pretty clear what it means.

(but please keep the comments for example for "Performs the where am I operation.", because it's not clear for a translator what the "where am I" operation is.)

Hi Andre:

Thanks for your review of the early changes!

I prefer the blank line.  It's a documentation style used throughout the rest of the code.

> willie, if you want to test the results of adding comments yourself, you can
> take a look at the empty translation file by going to the orca/po directory,
> running "intltool-update --pot", and then opening the resulting .pot file.

I've been doing a "make update-po" and then looking at en_GB.po.  But...your method is definitely much better.  :-)

>    # Translators: this represents an item on the screen that has
>    # been set insensitive (or grayed out).
>    return [_("grayed")]
> 
> how is this spoken in the context? can i imagine that the screenreader reads
> all the items in the menu, and for the insensitive item X the screenreader says
> "X grayed"? i'm just afraid again that we're splitting sentences, or that there
> are languages out there that would have to say "grayed: X" instead.

We're dealing with a temporal media (speech) and we want to speak the most important information first.  That's a user design requirement that trumps proper grammar.  The reason for this is that the user may be quickly navigating a dialog and does not want to suffer through proper Queen's English or Inuit's Inuit to hear what they really want to hear (e.g., the name of the object they are on).  As they hear the information they want, they can hit a tab key to interrupt speech and move on to the next item of interest.

In the case we're dealing with here, the constructed phrase may be "Apply button grayed".  The name "Apply" is most important, the role "button" is next, and the state "grayed" is last.  The order in which we present information is the order that our users prefer.

> also, if i remember correctly, it's enough to add *one* comment to translatable
> terms that are used more than once, e.g. "collapsed" or "blank" - comments will
> just be concatenated, so currently the comment would be printed several times
> in the .po file in front of the translatable term.

I thought about doing this, but I had a concern about the possibility of removing the one comment sometime in the future.  I thought it safest to duplicate the comment to avoid this.  In additon, I didn't see the comment printed several times when I was experimenting with this.  Do you have an example where the comment really was printed several times?  I don't see it in the .pot file or the en_GB.po file.

>    # Translators: the Orca "SayAll" command allows the
>    # user to press a key and have the entire document in
>    # a window be automatically spoken to the user.  If
>    # the user presses any key during a SayAll operation,
>    # the speech will be interrupted and the cursor will
>    # be positioned at the point where the speech was
>    # interrupted.
>   _("Speaks entire document."))
> 
> i think you should not mentioned the "SayAll" command here, because it's not
> "interesting"/visible for the translator, and it is not part of the string to
> translate. same goes for "Searches for the next instance of a string." i'd say
> - perhaps we don't need a comment here at all, it's pretty clear what it means.

I added these comments based upon private e-mail I exchanged with translators for GNOME 2.18.  They really needed to know what the context was for the strings so they could use appropriate verbs and nouns.  I specifically remember a short essay on the notion of "speak".  I also had similar questions for other strings, so I concluded I could make no assumption that the user had any idea behind the context of the string and chose to offer it.  I'd also find it hard to believe that translators would complain about docs that can help clarify things.  ;-)

(In reply to comment #20)

hi willie,

> >    return [_("grayed")]
> > how is this spoken in the context?
> we want to speak the most important information first.
> That's a user design requirement that trumps proper grammar.
> The order in which we present information is the order that our users prefer.

sounds like there have been some usability tests (as i know sun ;-), i hope that this also works well with languages that have other sentence structures and not "subject - verb - object". but i get your point and understand it, yeah.

> > also, iirc, it's enough to add *one* comment to translatable terms
> I didn't see the comment printed several times

my fault. it only happens if the comment is not always exactly the same one, right... sorry for the noise. :-)

> I added these comments based upon private e-mail I exchanged with translators
> for GNOME 2.18.  They really needed to know what the context was for the
> strings so they could use appropriate verbs and nouns.

ah, okay! if translators are fine with this, then everything is perfect. and yes, better one comment too much than too less. so: awesome job so far, thanks so much!

> sounds like there have been some usability tests (as i know sun ;-), i hope
> that this also works well with languages that have other sentence structures
> and not "subject - verb - object". but i get your point and understand it,

Our UI design lead is a user and also led the script writing department for a leading Windows screen reader.  So....we have a lot of reasons for doing the things the way we do them.  :-)  The goal with concatenation here is not to do some sort of natural language generation based upon localization sentence structures, but is more of an ordered presentation of information based upon importance.  But...having said that, when creating the individual chunks of information, I'll definitely try to make sure the code does the right thing.  For example, I made a change yesterday where we used to have something like this:

    a = _("Speak ")
    if b:
        a += _("cell")
    else:
        a += _("row")

I just changed it to:

    if b:
        a = _("Speak cell")
    else:
        a = _("Speak row")

I suppose I could have done something like _("Speak %s").  Would that have been the better thing to do (I can always go back and change it)?

> my fault. it only happens if the comment is not always exactly the same one,
> right... sorry for the noise. :-)

Phew!

> > I added these comments based upon private e-mail I exchanged with translators
> > for GNOME 2.18.  They really needed to know what the context was for the
> > strings so they could use appropriate verbs and nouns.
> 
> ah, okay! if translators are fine with this, then everything is perfect. and
> yes, better one comment too much than too less. 

Yeah...it's kind of like the Inuit's having a gazillion words for "snow" and the translators need to pick the right word.  Well...the "snow" thing seems to be a hoax (http://www.mendosa.com/snow.html), but I guess you know what I mean.  We'll get there step by step.  

Thanks!

Will

> I need help here.  Are there common l10n mechanisms for exchanging 'y' and 'n'
> for console based input?

Jochen Skulj sent me some code for the console module that basically creates a new method to check the user's input and returns true if the input matches a yes answer (all other input is assumed to be no).  This seems like a great start.

I dug a little more into what Python might have to offer for y/n support, and there's the locale.YESEXPR and locale.NOEXPR support.  These might be useful:

>>> import locale
>>> print locale.nl_langinfo(locale.YESEXPR)
^[yY]
>>> print locale.nl_langinfo(locale.NOEXPR)
^[nN]
>>> import re
>>> validInput = re.compile("%s|%s" % (locale.nl_langinfo(locale.YESEXPR), locale.nl_langinfo(locale.NOEXPR)))
>>> validInput.match("You bet")
<_sre.SRE_Match object at 0xb79c29c0>
>>> validInput.match("you bet")
<_sre.SRE_Match object at 0xb79c29f8>
>>> validInput.match("y")
<_sre.SRE_Match object at 0xb79c29c0>
>>> validInput.match("yes")
<_sre.SRE_Match object at 0xb79c29f8>
>>> validInput.match("Y")
<_sre.SRE_Match object at 0xb79c29c0>
>>> validInput.match("Yes")
<_sre.SRE_Match object at 0xb79c29f8>
>>> validInput.match("Not on your life")
<_sre.SRE_Match object at 0xb79c29c0>
>>> validInput.match("0")
>>> validInput.match("1")
>>> validInput.match("affirmative")
>>> validInput.match("contrary")
>>> isYes = re.compile(locale.nl_langinfo(locale.YESEXPR))>>> isYes.match("y")
<_sre.SRE_Match object at 0xb79c2a68>
>>> isYes.match("Y")
<_sre.SRE_Match object at 0xb79c29c0>
>>> isYes.match("1")
>>> isYes.match("yes")
<_sre.SRE_Match object at 0xb79c2a68>
>>> isYes.match("Yes")
<_sre.SRE_Match object at 0xb79c29c0>
>>> isYes.match("Yeppa deppa do")
<_sre.SRE_Match object at 0xb79c2a68>
>>> isYes.match("n")
>>> isYes.match("No")
>>> isYes.match("no")
>>> isYes.match("N")

The only thing that scares me is that the docs say "Warning: The expression is in the syntax suitable for the c:regex function from the C library, which might differ from the syntax used in re."

Created attachment 85741 [details] [review]
Fixes for Gecko.py

Created attachment 85743 [details] [review]
Work for gnomespeechfactory.py.

There are a couple spots in here I'm not terribly comfortable with, but I don't have a good answer for.  The first is how we handle ellipses to be sent to the speech synthesis engine: "Open..." turns into "Open dot dot dot", and the string to be translated is " dot dot dot".  The second is how we handle negative numbers to be passed to the speech synthesis engine: "-56" turns into "minus 56", where we turn "-" into "minus" and concatenate "minus" + " " + "56" together.

> I dug a little more into what Python might have to offer for y/n support, and
> there's the locale.YESEXPR and locale.NOEXPR support.  These might be useful:

After some investigation, YESEXPR and NOEXPR seem to have some troublesome problems, and I'd be afraid they might get out of sync with the locale being used by Orca.  So...I think the final solution to the yes/no console problem is to define our own regular expressions for yes and no.  Something like _("^[Yy1]") and _("^[Nn0]").  They would contain gratuitous comments for translators that say something like "This is regular expression that means any string of text beginning with 'y' 'Y' or '1'.  Translate the internals (e.g., 'Yy1') of this string as appropriate.  Furthermore, ensure that the translations for the prompts that request yes/no answers will elicit strings that match these regular expressions.".  

hmm, that means that we would expect translators to know what regexps are.

(In reply to comment #27)
> hmm, that means that we would expect translators to know what regexps are.
> 

Do you really think, this is a problem? I thought that translators should have enough experience to have at least a basic knowledge about regexps. And these patterns won't be that complicated so that it should be no big problem to translate them or redefine them. Or do you have another opinion on that?

(In reply to comment #28)
> (In reply to comment #27)
> > hmm, that means that we would expect translators to know what regexps are.
> > 
> 
> Do you really think, this is a problem? I thought that translators should have
> enough experience to have at least a basic knowledge about regexps. And these
> patterns won't be that complicated so that it should be no big problem to
> translate them or redefine them. Or do you have another opinion on that?

I don't think it should be a problem.  It's not like we're asking translators to understand the complete specification of regexps.  We're merely providing a very simple pattern for them to follow, and the note to the translators should hopefully clarify questions they may have.  

(In reply to comment #27 and #28)
if we add a good comment that is also easy to understand if you don't know what regexp's are, this should not be a problem, yepp.

> I thought that translators should have enough experience to have 
> at least a basic knowledge about regexps.
i beg to differ here, i don't expect any knowledge of maths or CS from a translator. anyway, i'm nitpicking a bit it seems, sorry for the noise, guys. :-)

#15
Note to people looking at this: remember that Orca is a different beast.  It
outputs spoken language via speech and an alternative written form of language
using braille.  Both are much different media than graphical user interfaces. 
The temporal nature of speech combined with the need to present the most
important information first can result in ungrammatical (but desirable)
utterances.  The limited output of a braille display (typically 40 characters)
can also result in some things that may seem unsavory to people used to large
displays.

#20
In the case we're dealing with here, the constructed phrase may be "Apply
button grayed".  The name "Apply" is most important, the role "button" is next,
and the state "grayed" is last.  The order in which we present information is
the order that our users prefer.

These two are excellent examples of cases where comments are really important. We (translators) are actually pretty creative ;) but we need to know what we are dealing with. So if you add comments indicating that something needs to be keep under a certain length or that this sentence is created grammatically wrong on purpose and should be kept that way, we can probably figure it out, but we don't have any betazoid (http://en.wikipedia.org/wiki/Betazoid) on our team ;)

#19
these patches will definitely improve the situation, but let's try to only add
comments where needed, otherwise the po file will become hard to read.
but nearly all of your comments are needed in my opinion, so: good work! :-)

Agreed. I might have been a little overly-eager in my first post. With syntax highlighting I don't actually think that extra comments make the .po-file more difficult to read, but sure you are wright. Don't add comments to obvious strings, but I would still say that if you are in doubt better one to many than one to few.


Oh and another thing. If you add a comment explaining that something is a regular expression then I think most of us would be able to figure out what that meant and translate it correctly, but is that really the smartest way to go? Why not just ask us to translate the "y", "Y", "n" and "N" and explain that we should translate them into, the lower and upper case first letter of our native  word for "yes" and "no", as they are used in these other strings marked by the a comments like this... and so on and so on..  and then create the regular expression yourselves, directly in the code?

Cheers TLE

This is a great discussion.  Thanks!

> These two are excellent examples of cases where comments are really important.
> We (translators) are actually pretty creative ;) but we need to know what we
> are dealing with. So if you add comments indicating that something needs to be
> keep under a certain length or that this sentence is created grammatically
> wrong on purpose

You bet!  The grammatically wrong on purpose stuff should be shielded from translators (we concatenate things together in code), but we will provide comments to ease concerns that we may not be aware it is grammatically wrong.  We'll also provide hints for string length and such -- I remember getting a few questions along those lines during the GNOME 2.18 l10n push.

> Oh and another thing. If you add a comment explaining that something is a
> regular expression then I think most of us would be able to figure out what
> that meant and translate it correctly, but is that really the smartest way to
> go? Why not just ask us to translate the "y", "Y", "n" and "N" and explain that
> we should translate them into, the lower and upper case first letter of our
> native  word for "yes" and "no", as they are used in these other strings marked
> by the a comments like this... and so on and so on..  and then create the
> regular expression yourselves, directly in the code?

The only concern I have about this particular case is that we'd be making an assumption about the number of ways to say "yes" and the availability of upper/lower case.  So, a simple regular expression that's under control of the translator seems as though it would allow for the most flexibility and the likelihood that things would turn out right.  In addition, assume a language used the same first letter for "yes" and "no" (I know of no such language: I only know English, a little French, can count to 10 in Japanese, and can say "black coffee, please" in Spanish).  The translated regular expression technique would allow us to handle this exception by expanding the expression to match a complete word versus a single character.  In the event the translator for that language did not know regular expressions, we'd gladly offer assistance.

#32
The only concern I have about this particular case is that we'd be making an
assumption about the number of ways to say "yes" and the availability of
upper/lower case.  So, a simple regular expression that's under control of the
translator seems as though it would allow for the most flexibility and the
likelihood that things would turn out right.  In addition, assume a language
used the same first letter for "yes" and "no" (I know of no such language: I
only know English, a little French, can count to 10 in Japanese, and can say
"black coffee, please" in Spanish).  The translated regular expression
technique would allow us to handle this exception by expanding the expression
to match a complete word versus a single character.  In the event the
translator for that language did not know regular expressions, we'd gladly
offer assistance.

Good point. And if you explain the regular expression it should be bullet proof.

Created attachment 85830 [details] [review]
Remove bizarre _("%s") % string constructs

This patch removes a number of very strange _("%s") % string constructs, replacing them with just the string.  In the event that the string was not flagged for translation (even stranger), the patch also upgrades them for translation.  The patch also includes some comments on strings to finish out work on the where_am_I.py module.

Created attachment 85851 [details] [review]
Patch to cover keybindings.py and keynames.py.

Created attachment 85852 [details] [review]
Patch to handle the y/n questions using regular expressions and to do more l10n cleanup

This patch implements the regular expression method for matching y/n questions in the Orca console configuration utility, and it includes copious comments for how to translate the regular expression.

Created attachment 86108 [details] [review]
Patch to work on orca_gui_prefs.py

This patch cleans up the documentation for orca_gui_prefs.py, adding clarification to all the things I received questions on, and demoting a few debug and other strings that never would be shown to a user.

Created attachment 86169 [details] [review]
Patch for rolenames.py

This patch addresses probably one of the more confusing aspects of Orca for translators: rolenames for short braille, long braille, and speech.

Created attachment 86210 [details] [review]
Patch to fix up all the scripts

This patch finishes off of the scripts.  There are three files left: orca.py (need to know if we should translate command line arguments or not), phonnames.py (need a better way to handle military spelling for more than just a-z) and pronunciation_dict.py (need a better way to reduce/augment the dictionary for common acronyms and such for languages).

Created attachment 86298 [details] [review]
This patch provides a more flexible means for translators to support military spelling

Not sure if I'm paranoid, but translation can be done through rosetta for example and often they aren't controlled at all. Maintainer can commit this part without review and as a result you'll delete your home directory.

So Willie, please, don't execute translation, make it a list with say : or , delimiters and split it.

(In reply to comment #41)
> Not sure if I'm paranoid, but translation can be done through rosetta for
> example and often they aren't controlled at all. Maintainer can commit this
> part without review and as a result you'll delete your home directory.
> 
> So Willie, please, don't execute translation, make it a list with say : or ,
> delimiters and split it.

Nickolay: I'm not sure I understand what you're commenting on here.  Can you please give an example?

Created attachment 86532 [details] [review]
Patch to drop evaluation of translation

Thanks!  Committed with minor edits.

Thank you :)

I suggest adding in a couple of URL links to the comment for the military
spelling, to help translators easily find their countries equivalent

One of them should be:

http://en.wikipedia.org/wiki/NATO_phonetic_alphabet

Will, you came up with another one a couple of months back, but I don't
remember what it was.

> http://en.wikipedia.org/wiki/NATO_phonetic_alphabet

Done!

Created attachment 86587 [details] [review]
Unmark usage text for translation.

This patch unmarks the usage text and command line options for translation.  The next patch to do is hopefully the last one for this big L10N push: we need to do something similar in chnames.py as we did phonnames.py.  After that, we'll send a message to the gnome-i18n folks asking for a review to see if they see any glaring problems.

> The next patch to do is hopefully the last one for this big L10N push: we need
> to do something similar in chnames.py as we did phonnames.py.  

Discussed this with the gnome-i18n folks and decided not to do it.

> After that,
> we'll send a message to the gnome-i18n folks asking for a review to see if they
> see any glaring problems.

Message sent, and I requested they post constructive comments here. 

593 	selectedItems = []
594 	totalSelectedItems = 0
595 	for i in range(0, childCount):
596 	child = panel.child(i)
597 	if child.state.count(atspi.Accessibility.STATE_SELECTED):
598 	totalSelectedItems += 1
599 	selectedItems.append(child)
600 	
601 	# Translators: this is a count of the number of selected icons
602 	# and the count of the total number of icons within an icon panel.
603 	# An example of an icon panel is the Nautilus folder view.
604 	#
605 	utterances.append(_("%d of %d items selected") % \
606 	(totalSelectedItems, childCount))

this message needs ngettext. in czech language, you have different words for "items" whether you talk about <=4 or >=5 items.

oops... i'm talking about /src/orca/where_am_I.py here :-)
apart from that: great, awesome work, guys!

Created attachment 88684 [details] [review]
Patch to fix the problem mentioned in comment #51.

Thanks Andre!

I'm going to close this bug out as FIXED -- there were a large number of issues covered by this one bug, and I think we got all known problems.  If more specific problems arise, specific bugs should be opened to address them.  Thanks everyone!