Created attachment 107626 [details]
Orca debug output whilst testing this problem.

> Expected results:
> That Orca announces only really unread messages, that Orca announces an
> attachment only when there's one, and that flaggs were announced only
> when they really exist.
> Finally I don't want to hear "unselected" when I've placed the cursor on a
> message.

Tested with latest Orca from SVN trunk and latest Ubuntu Hardy.

My understanding was that Orca would announce each message as you
arrowed Up or Down to it in the message list. As well as this, there 
are three "smarts":

1/ Rather than always announcing the first column, it would only
   speak/braille "unread" if the message is unread. See lines
   1932 and 2043 for an example of this.

2/ Rather than always announcing the second column, it would
   only speak/braille "attachment" if the message had an attachment.
   See lines 2304 and 2407 for an example of this.

3/ Rather than always announcing the third column, it would
   only speak/braille "flagged" if that message was flagged.
   (I don't have an example of this in my INBOX, but I have no
    reason to believe it isn't working).

I am not getting "unselected" spoken.

Mike, is my understanding about correct?

Note that there were two other recent bugs that dealt with this:

http://bugzilla.gnome.org/show_bug.cgi?id=503874
filed by Will (from Hermann's email to the orca-list) also dealt with this.
This was fixed on Jan 18th 2008.

http://bugzilla.gnome.org/show_bug.cgi?id=508153
This was closed as fixed on Jan 25th 2008.

Hermann, if you are using latest Orca and are getting something
different, could you attach an Orca debug file so I can compare
your results with mine?

Thanks.

Currently I use Orca 2.22.0 from the Gnome server. Does this patch also 
apply for this version?

> Currently I use Orca 2.22.0 from the Gnome server. Does this patch also 
> apply for this version?

Yes.

The attachment is a debug.out, so what to do with it?
As I wrote in earlier comments, I never got the messages list in Evolution shown properly, no matter which Orca version 
I used. I think I sent a debug.out showing the behavior of Evolution on my machine.

Sorry for the confusion.  The debug.out is just a mechanism to record/track progress on this bug.  When a patch is ready, it should hopefully be marked as a patch.

I am unable to reproduce these problems so I guess this should be changed to "need info" until we get the requested debug.out 

Just so it's clear -- we NEEDINFO from Hermann:

> Hermann, if you are using latest Orca and are getting something
> different, could you attach an Orca debug file so I can compare
> your results with mine?

Created attachment 108131 [details]
My orca debug.out showing the behavior of Evolution.

This is my debug.out that shows how Evolution is behaving on my machine. I hope the difference to the expacted behavior 
is shown.

Thanks Hermann. I'll investigate this in depth tomorrow, but
I have a gut feeling I know what the problem is going to be.

From the debug.out file, I can see you are running in the German 
locale. In the Evolution script, in order to provide these smarts: 

* Rather than always announcing the second column, it would
  only speak/braille "attachment" if the message had an attachment.

* Rather than always announcing the third column, it would
  only speak/braille "flagged" if that message was flagged.

we are looking for column headers of "Status" and "Flagged".
Now, in your case, we should be looking for the German 
localized equivalents, but I'm wondering whether the Orca
translations aren't matching up with what Evolution is using. 

I can fully check that tomorrow.

In the mean time, could you possibly run Evolution with Orca
in one of the English locales and see if it performs better 
for you?

Unfortunately this was never possible in Ubuntu:
dpkg-reconfigure locales
starts the process without presenting the usual frontend, and it performs without changing anything. I observe this 
since Edgy, and nobody knows a solution for this.

Problem found and it's a big one.

In the Evolution script, in the code where it's looking for the table
cells from those three columns, it's wants to compare the column header
names, looking for localized strings like "Status" and "Flagged".

In order to do that (at line 1043 in Evolution.py) it's doing:

                            if action.getName(j) == "toggle":

By running in the German locale, I can see that what we are getting back
from "action.getName(j)" is a localized string, so this string equality
is failing. So no smarts in the Evolution mail header list.

But it's much worst than that. It means that whereever we look at an
"action.getName(<n>)" and compare it against a string like "toggle",
it's going to do the wrong thing.

From grepping the Orca source I found:

In .../orca/src/orca/*.py
braillegenerator.py:                        if action.getName(j) == "toggle":
braillegenerator.py:                if action.getName(i) == "toggle":
flat_review.py:                    if action.getName(i) == "toggle":
focus_tracking_presenter.py:        #        print someThread.getName(), someThread.isAlive()
Gecko.py:                name = action.getName(i)
speechgenerator.py:                        if action.getName(j) == "toggle":
speechgenerator.py:                if action.getName(i) == "toggle":
speechgenerator.py:                                    if action.getName(j) == "toggle":
where_am_I.py:                if action.getName(i) == "toggle":
where_am_I.py:                    if action.getName(i) == "toggle":

In .../orca/src/orca/scripts/*.py
Evolution.py:                if action.getName(i) == "toggle":
Evolution.py:                            if action.getName(j) == "toggle":

So it looks like we need to localize the "toggle" string in all
these comparisons. Will, is that the correct solution or is there
a better way?

(In reply to comment #11)
>                             if action.getName(j) == "toggle":
...
> By running in the German locale, I can see that what we are getting back
> from "action.getName(j)" is a localized string

Yech.  Nice catch, though!  This is going to be a troublesome one.  I'm curious where the "toggle" is coming from.  One place I can find it is in the add_cell_actions method of gailtreeview.c:  

http://svn.gnome.org/viewvc/gail/trunk/gail/gailtreeview.c?view=markup

It's not marked for translation there.  So...this leads me to look in the Evolution code, and I come across the gal_a11y_e_cell_toggle_new method in gal-a11y-e-cell-toggle.c:

http://svn.gnome.org/viewvc/evolution/trunk/a11y/e-table/gal-a11y-e-cell-toggle.c?view=markup

It's marked for translation there, and the change to do this was made in January 2005 by Li:

http://svn.gnome.org/viewvc/evolution/trunk/a11y/e-table/gal-a11y-e-cell-toggle.c?revision=28572&view=markup

This leads me to wonder if the action name should or should not be marked for translation.  The fact that actions have a name and a description leads me to believe these are parallels of an accessible's name and description.  So, they probably should be marked for translation.  If this is the case, we have nastiness to deal with for backward/forward compatibility.

I'd guess the way to move forward would be to ask Li what his interpretation of the Accessibility_Action spec is (i.e., should name/description be translated?).  If he thinks it should not be translated, we can isolate this to an Evolution bug.  :-)  

If he thinks it should be translated, we need to log a gail bug to mark all action names and descriptions in gail for translation, and we probably should modify the Orca code to do something like the following, where we look for both the translated and untranslated forms:

        # Translators: this is the action name for the 'toggle' action.
        # It must be the same string used in the *.po file for gail.
        #
        if action.getName(i) in ["toggle", _("toggle")]:

Alternatively, I've often hated the need to make our translators translate the same string more than once -- once for the original source (e.g., Evolution in this case) and then again in Orca.  I sometimes wonder if we can play tricks in orca_i18n.py to try to pull translations from the original source if we can.  Doing so may be quite error prone, though, and may also assume we know what locale the other app is running with.

CC'ing Li for his thoughts.

I think the name and description of an action should be translated because it can be shown on GOK. I will file a gail bug for this. Thanks.

Li, when you file that gail bug, could you add a "blocks" for this bug
please?

In the meantime, I'll work up a patch using Will's nice idea of searching
for both the translated and the untranslated "toggle".

There is a similar check for "open" in Gecko.py. We should probably
add a similar change there.

Thanks.

Created attachment 108354 [details] [review]
Revision #1.

I've adjusted all the occurrances of "toggle" (and the one occurance
of "open" in Gecko.py), to now look for either a translated or an
untranslated one.

I also ran "intltool-update -p" in the po directory to create a
new orca.pot file. From that, I copied the part for the new "toggle"
string to the de.po file and adjusted the msgstr part to be the German
translation of "toggle" (which is "Umschalten"). 

I then ran the new patched version of Orca in the German/German locale
with Evolution against one of my mail folders which had messages which 
were read, had attachments and flags and generated the following output:

$ orca
SPEECH OUTPUT: 'Willkommen bei Orca.'
BRAILLE LINE:  'Willkommen bei Orca.'
     VISIBLE:  'Willkommen bei Orca.', cursor=0
BRAILLE LINE:  'orca Anwendung Orca-Bildschirmleser/-lupe Rahmen'
     VISIBLE:  'Orca-Bildschirmleser/-lupe Rahme', cursor=1
SPEECH OUTPUT: 'Orca-Bildschirmleser/-lupe Fensterrahmen'
BRAILLE LINE:  'orca Anwendung Orca-Bildschirmleser/-lupe Rahmen Einstellungen Schaltfläche'
     VISIBLE:  'Einstellungen Schaltfläche', cursor=1
SPEECH OUTPUT: ''
SPEECH OUTPUT: 'Einstellungen Schaltfläche'
BRAILLE LINE:  'evolution Anwendung Zu erledigen (30 insgesamt) - Evolution Rahmen'
     VISIBLE:  'Zu erledigen (30 insgesamt) - Ev', cursor=1
SPEECH OUTPUT: 'Zu erledigen (30 insgesamt) - Evolution Fensterrahmen'
SPEECH OUTPUT: 'Down'
SPEECH OUTPUT: 'orca (bugzilla.gnome.org) <bugzilla-daemon@bugzilla.gnome.org>'
SPEECH OUTPUT: '[Bug 426010] Implement Verbailized Links in OOo'
SPEECH OUTPUT: '06. Jan, 8:36'
BRAILLE LINE:  'orca (bugzilla.gnome.org) <bugzilla-daemon@bugzilla.gnome.org> [Bug 426010] Implement Verbailized Links in OOo 06. Jan, 8:36 '
     VISIBLE:  'orca (bugzilla.gnome.org) <bugzi', cursor=0
SPEECH OUTPUT: 'Down'
SPEECH OUTPUT: 'Anlage Spaltenkopf'
SPEECH OUTPUT: 'Anlage'
SPEECH OUTPUT: 'Klaus.Niederkrueger@umpa.ens-lyon.fr'
SPEECH OUTPUT: 'clean up of gcalctool sourcecode ausgeklappt'
SPEECH OUTPUT: '09. Jan, 1:50'
BRAILLE LINE:  'Anlage Klaus.Niederkrueger@umpa.ens-lyon.fr clean up of gcalctool sourcecode ausgeklappt 09. Jan, 1:50 '
     VISIBLE:  'Anlage Klaus.Niederkrueger@umpa.', cursor=1
SPEECH OUTPUT: 'Down'
SPEECH OUTPUT: 'Klaus.Niederkrueger@umpa.ens-lyon.fr'
SPEECH OUTPUT: 'Re: clean up of gcalctool sourcecode ausgeklappt'
SPEECH OUTPUT: '10. Jan, 7:58'
BRAILLE LINE:  'Klaus.Niederkrueger@umpa.ens-lyon.fr Re: clean up of gcalctool sourcecode ausgeklappt 10. Jan, 7:58 '
     VISIBLE:  'Klaus.Niederkrueger@umpa.ens-lyo', cursor=0
SPEECH OUTPUT: 'Down'
SPEECH OUTPUT: 'Anlage Spaltenkopf'
SPEECH OUTPUT: 'Anlage'
SPEECH OUTPUT: 'Markiert'
SPEECH OUTPUT: 'Klaus.Niederkrueger@umpa.ens-lyon.fr'
SPEECH OUTPUT: 'Re: clean up of gcalctool sourcecode'
SPEECH OUTPUT: '13. Jan, 16:22'
BRAILLE LINE:  'Anlage Markiert Klaus.Niederkrueger@umpa.ens-lyon.fr Re: clean up of gcalctool sourcecode 13. Jan, 16:22 '
     VISIBLE:  'Anlage Markiert Klaus.Niederkrue', cursor=1

--

In short, I think the problem is fixed.

Hermann (and others), I think it's ready for testing. I haven't checked the
patch in. You are going to need to apply it against Orca from SVN trunk,
re-configure, re-compile and re-install.

Cool and thanks for digging deeper to find all the places where an action name was used and for your testing of this.

BTW, if you make the comments for translators be word-for-word and line-by-line identical, they *should* only appear once in the *.po file.  Based upon past history with the l10n team, I know this is something the translators prefer.  ;-)  I see you did this for a number of the comments and identical looking ones ended up getting repeated.  My only guess there is that there might be trailing whitespace on some of the comments.

> BTW, if you make the comments for translators be word-for-word and line-by-line
> identical, they *should* only appear once in the *.po file.

The problem here is that one of the cases is very much right-indented
so the text has to be smushed into a small number of columns to pass
pylint. If you are okay with that for all of the occurances of this
translators message, then I can easily adjust it to do that.
 

(In reply to comment #17)
> The problem here is that one of the cases is very much right-indented
> so the text has to be smushed into a small number of columns to pass
> pylint. If you are okay with that for all of the occurances of this
> translators message, then I can easily adjust it to do that.

I'm OK with that - there are more translators than Orca developers, and they like to yell at us when we do something that annoys them.  ;-)  Thanks!

How to apply that patch? It patches a bunch of files, and do I really have to type in every file? I hope that is a 
sumary command to apply all the patches.

> How to apply that patch? It patches a bunch of files, and do I really have 
> to type in every file?

* Check out Orca from SVN trunk.

* Change directory to the top-level Orca directory.

* Patch the files with:

  $ patch -p0 < patch-519936-1

* Then do the autogen.sh, make and sudo make install.

Created attachment 108362 [details] [review]
Revision #2.

Patch adjusted so all the translators comments for the "toggle"
string are all formatted identically.

The patch works. Two questions: 1. Can I use it for version 2.22? 2. When in cell mode, I still hear "unselected", but only there. Any ideas why?

> 1. Can I use it for version 2.22?

We would probably not be supplying this patch for GNOME 2.22.
If you were willing to keep patching the new versions of Orca
2.22.X, I don't see any reason why it shouldn't work.

> 2. When in cell mode, I still hear "unselected", but only 
> there. Any ideas why?

That looks like another separate bug. From first blush, I'd say
it's Evolution's, but we might be able to work around it in Orca.
I'll file a separate Bugzilla bug on this.

You're welcome.

Bug #525439 has been opened on the new problem.

(In reply to comment #21)
> Created an attachment (id=108362) [edit]
> Revision #2.
> 
> Patch adjusted so all the translators comments for the "toggle"
> string are all formatted identically.
> 

Yeah!  Thanks.  Be careful about checking in the German PO file -- the last time I made a change to a *.po file, the i18n/l10n team lambasted me even though the modifications were correct.  That is, the last I knew, they were very protective of the files in the po directory and didn't want us touching any of them except the POTFILES* files.  So, I say commit everything except modulo de.po.  Then, contact jochen at jochenskulj dot de regarding the de.po changes.  Thanks!

Patch committed to SVN trunk. Closing as FIXED.

Adding Jochen to the CC: so he's aware of the need
to update the de.po file. Jochen, the diff in the second
attached patch (http://bugzilla.gnome.org/attachment.cgi?id=108362)
works nicely.

Thanks.

Today I updated the German translation - at least I tried to. Currently I don't find »toggle« in the po-file of gail, even after executing intltool-update. Therefore I am not sure whether »toogle« should be translated as a verb or a noun. I just translated it as a verb. If this translation causes any trouble please contact me or file a bug against the translation. Please excuse my late response.

Created attachment 109116 [details]
The output of the "make" command, wich produces errors.

I tried to update the latest Orca, but got the error messages attached here. I think the translation is wrong somewhere in the file.

The bug has come bakc. After installing the very latest Orca, I hear the same wrong messages again as before: "unread" "attachment" and "flagged" no matter whether it's true or not. I think the localization should be completely be revisited. 

Hermann, I wonder if it's not that the bug has come back per se, but rather you had fixed the bug on your box because Rich's patch (attached to this bug) included an adjustment to po/de.po and that adjustment was not checked in because we don't adjust the language files but leave that to the translation team.  If you just apply the part of Rich's patch for po/de.po, does the bug go away again?

Scratch what I just said as that doesn't make sense.  I need to drink more coffee before commenting. :-)

Jochen checked in an updated de.po file so that shouldn't be it.  Looking at the differences between what Rich had in his patch (which I gather worked for you) and what Jochen checked in, the only difference I'm seeing is the capitalization:

Rich's patch:

+msgid "toggle"
+msgstr "Umschalten"

Jochen's checkin:

msgid "toggle"
msgstr "umschalten"

Maybe capitalization counts?

Jochen, the translation notes indicate the string should match what Gail uses -- which is correct.  However, my understanding (still pre-coffee and unverified) is that Gail didn't have action strings marked for translation -- and perhaps still does not.  The source of the problem (again, as I understand it, again, pre-coffee :-) ) is that the string was marked for translation in Evolution so, alas, the string in Evolution and the string in Gail and the string in Orca all need to match (and perhaps the string in Evolution needs to not be marked for translation).

Sorry, it's my fault. I translated "toogle" with "umschalten", but according to the patch it should be "Umschalten". I updated the translation file (revision 3829) in the hope that it will work again.

But from a translators view it is a rather unsuitable approach to establish dependencies between applications by using translation files. There have to be a strong distinction between strings that are labels and strings that are keys for events and widgets. If you mark your keys as translatable you always risk that your application don't work robustly. If you use a translatable key that has to match another translatable key from a completely different application you double that risk.

Therefore I think it's worth to check if there is a different approach to fix this issue. At least I would make the string comparisons case insensitive.

After the latest changes, everything is all right again. Thanks to Jochen.

(In reply to comment #32)
> But from a translators view it is a rather unsuitable approach to establish
> dependencies between applications by using translation files. There have to be
> a strong distinction between strings that are labels and strings that are keys
> for events and widgets. If you mark your keys as translatable you always risk
> that your application don't work robustly. If you use a translatable key that
> has to match another translatable key from a completely different application
> you double that risk.
> 
> Therefore I think it's worth to check if there is a different approach to fix
> this issue. At least I would make the string comparisons case insensitive.

Agreed.  We do our best to try to avoid references to translated strings coming from other applications.  Sometimes, however, we run into situations where we need to do it as a last resort.  Believe me, the Orca team can get frustrated with me trying to find a different way than resorting to string compares on translated strings coming to us.

In this particular case, we have an issue where the action names are *supposed* to be translated, but we have a mixed condition where Evolution translates them, but gail doesn't (see bug 525226).  When gail is changed, we have an issue where we no longer have access to programmatic constants for doing a comparison.  Bug 351477 may help us address this some, and I'll add some more information to it.