Re: Orca A few more questions

[Kenneth Nielsen <kenneth nielsen vgpnet telelet dk>]

Hey Will
Thanks for your quick reply.

    > That is probably a good idea for the users, but from the point of
   view
    > of the translators it's actually better if you explain it in the
   comment
    > in the header of the .po file. You see, the translation teams aren't
    > always so fortunate as to have a user of all the different pieces of
    > software that we translate. And if you are not a user it simply
   takes to
    > much time to try and get a overview of the documentation and
   track down
    > the info that way.

   Will do.  Can you tell me more about how to do this?  We've been putting
   comments in with the source code, but I've never quite figured out how
   to get the comments in a .po file.  Should we be creating an en_US.po
   file and documenting things there?


Actually some of your source-code comments made it into the .po ;)
I don't know how this looks from the programmers point of view. I may 
have been in error when I suggested that it could be commented in the 
header. I'm not sure that you can do that and on second thought I'm not 
sure it would be a good idea either, because we usually use that for our 
own notes. Instead I would suggest that you explain problematic terms in 
the string-comment the first time it is used. As I said I don't actually 
know how to code it so that comments pass through to the .po file, but I 
can paste a couple of examples where we did get comments, then perhaps 
you can study those and figure it out that way.
Here's an example:
The string "Workspace " has the following comment
#. Note to translators: the "Workspace " and "Desk " strings
#. are the prefix of what metacity shows when you press
#. Ctrl+Alt and the left or right arrow keys to switch between
#. workspaces.  The goal here is to find a match with that
#. prefix.
#.
#: ../src/orca/scripts/metacity.py:123

An another one. (I think this one is unintentional)
The string "Handler" has the following comment
#. Treeview Column Implementation:
#. (HANDLER,    DESCRIP,
#. MOD_MASK1,  MOD_USED1,  KEY1,   TEXT1,
#. MOD_MASK2,  MOD_USED2,  KEY2,   TEXT2,
#. MODIF,      EDITABLE)
#. HANDLER
#.
#: ../src/orca/orca_gui_prefs.py:103


    > Anyway I'm almost done with the translation now and a few more
   questions
    > have popped up.

   Thanks!

    > 1. (speech) Ambiguity
    > In Danish the word for what people does when they talk (tale) and the
    > word for having something read to you (læse op) are different. So my
    > question is, besides from the strings that concerns adjusting the
   pitch
    > and tone does the term speech always concern the latter of the two?

   Most of this has to do with reference to the speech synthesizer.  But, I
   think we might need to have a more careful dialog about the various
   strings.  If you can cut/paste the ones in question, I can tell you more
   about them.

All right there are couple of those. Actually you only need to tell me 
if they are in the "read back text to you" sense (1) of referring to 
"speech" in general (2).

"Decreases the speech rate."
#: ../src/orca/default.py:255

"Toggles the silencing of speech."
#: ../src/orca/default.py:295

"GNOME Speech Services"
#: ../src/orca/gnomespeechfactory.py:164

"Select desired speech system:"
#: ../src/orca/orca_console_prefs.py:122

"Speech is unavailable."
#: ../src/orca/orca_console_prefs.py:103 
../src/orca/orca_console_prefs.py:119

Speech will not be used.\n
#: ../src/orca/orca_console_prefs.py:132 
../src/orca/orca_console_prefs.py:140
#: ../src/orca/orca_console_prefs.py:153 
../src/orca/orca_console_prefs.py:162
#: ../src/orca/orca_console_prefs.py:187

Select desired speech server.
#: ../src/orca/orca_console_prefs.py:143

Speech not available.
#: ../src/orca/orca_gui_prefs.py:497 ../src/orca/orca_gui_prefs.py:569
#: ../src/orca/orca_gui_prefs.py:643

Speech enabled.
#: ../src/orca/orca.py:816

Speech
#: ../src/orca/orca-setup.glade.h:57


    > 2. (greyed) Ambiguity
    > #: ../src/orca/braillegenerator.py:197
   ../src/orca/speechgenerator.py:198
    > What is greyed. Is it buttons or text or ...? That would also be
    > different in Danish depending on what it is that is "greyed"

   It can be any object, and it really is the shorthand way of saying "this
   thing is insensitive".

Cool


    > 3. (braille)
    > According to my dictionary "braille" is that kind of text that blind
    > people can read by touching it (blindeskrift). But is that always the
    > use of the term or is there also a program or device called that?

   Braille is indeed what you think it is.  We don't have a program called
   "braille," but there is such a device we refer to as a "refreshable
   braille display".  People who use braille with Orca use such a device.

Ok. So since if any string were referring to that special display I 
would probably include the word display. It is safe to assume that all 
occurrences of the word is in the former sense.


    > 4. (heading)
    > Heading can also by translated into different words in danish
   depending
    > on whether it is, a head line or the header of tekstfile. It is
   relevant
    > in the following strings:
    > #: ../src/orca/Gecko.py:3031 ../src/orca/Gecko.py:3042
    > No more headings

   These are things like <h1> in HTML.

Cool


    > #: ../src/orca/rolenames.py:543.
    > Header

   This one has been an AT-SPI mystery to me.  It's most likely header at
   the top of a page in a document.

    > The same goes for footer
    > #: ../src/orca/rolenames.py:548
    > footer

   Again, a mystery.  But, it's most likely the footer at the bottom of a
   page in a document.

Ok. Translated as such. Let me know if you learn that it is not correct.


    > 5. (chunk)
    > #: ../src/orca/Gecko.py:3053 ../src/orca/Gecko.py:3064
    > I assume that we're talking about a text chunk

   Ahhh...this one is tough.  It's ambiguous on purpose, but it's meaning
   is intended to be a blob of information that's you can easily skip over.
     A paragraph is a chunk.  A list (and possibly a list item) is a chunk.
     A header is a chunk.  The idea here is to allow users to repeatedly
   press a single well-known keystroke to skim over meaningful chunks of a
   document until they get where they want to do.  No good word for
   it.  :-(

It's not a problem. Actually the Danish word for bite (bid) can be used 
in much the same way. (It's all a part of the same weird language 
metaphor in which the document can be eaten, I suppose ;) )


    > 6. (Enter y or n)
    > I assume that the y or n characters are hardcoded since I can't
   seem to
    > find a string for them. Is that correct? Because in the case I'm
   going
    > to make a special construction here, something like "Tast y(ja) eller
    > n(nej)", because the danish words for yes and no doesn't start
   with the
    > same letters.

   Oohhh...we blew this one.  Do you have a suggestion for how we should
   handle this in our text-based setup?  Is there a l10n/i18n thing to do
   for requesting/handling yes/no answers from the command line?

No. I mean, with my limited programming experience I could _imagine_ 
one, but I'm pretty sure it's wrong. You _could_ load the character to 
parse the user input for, directly from a heavily commented gettext 
string like "y". But as I said, since that would leave the program in a 
state where actual functionality is dependent on a correct translation, 
I'm pretty sure that it isn't done like that.
But hey don't sweat it. The current way will work. I mean probably most 
people know enough English so that if they are asked a question and 
asked to press y or n they'll figure it out. So it definitely isn't 
worth rewriting code for at this point or breaking string freeze. You 
can just fix it in the next version. That should also give you plenty of 
time to maybe ask on the l18n list how it is done. Or you could ask some 
other developers directly. I checked and it turns out that the apt 
program does this correctly.


    > 7. (Mod.Mask 1)
    > #: ../src/orca/orca_gui_prefs.py:123
    > _If_ it is short for modification mask, then does the translation
   need
    > to be kept short also

   Hmmm...this might be a mistake to flag the string for translation.  I'll
   need to ask Jorge about that.

Hmm. Actually I may have blown this one. I forgot to mention that there 
is also this string right after:
"Use Mod.1"
#. MOD_USED1
#.
#: ../src/orca/orca_gui_prefs.py:133

that would probably suggest that it should be translated. But in that 
case my original question remain. I'll wait for your reply.


    > 8. (desktop)
    > #: ../src/orca/orca_console_prefs.py:307
    > 1. Desktop
    > In this it is fairly obvious that it is a desktop (computer) you are
    > referring to since the next string is Laptop, but
    > #: ../src/orca/orca_gui_prefs.py:1922
   ../src/orca/orca-setup.glade.h:66
    > _Desktop
    > here I can't tell whether you are referring to the computer or the
    > workspace on the screen

   We're actually referring to the class of computer keyboard.  The idea is
   that a desktop keyboard has a keypad on the right and laptop keyboard
   doesn't.

Oh yeah. Done.


    > 9. Abbreviations in rolenames.py
    > There are a lot a three string sets like this one:
    > ckm
    > CheckMenu
    > check menu
    > What are the abbreviations going to used for? Are there any certain
    > rules I should try to create them by, like only using consonants?
   Is it
    > necessary to keep them the same length as the English ones?

   The abbreviations are sent to braille, and the goal is to keep them
   short to preserve valuable space on the braille display.  I wish I had
   construction rules for you, but I think those things may need to be left
   up to the linguistic expertise of someone who speaks the language.  :-(

It's ok. I can do it. I just needed to know what they were used for and 
if I would break the program if I varied the length slightly.


    > 10. (writer)
    > #: ../src/orca/scripts/StarOffice.py:1469
    > Is it just the persom currently writing or a writer as in, "the
   writer
    > of the document" or "author of the book"

   This is an unfortunate one, and we only do these things as a last
   resort.  If it's what I think it is, it's the last name of the title for
   the window being shown by OpenOffice.  We all realize how fragile and
   brittle this can be, and we only do it when we really really have to.

I don't have StarOffice. Is it like in OpenOffice where the window title 
reads: "OpenOffice.org writer" In that case it wont be translated at 
all. You see we (at least our team) don't translate program titles since 
they can also be typed into the terminal and that would just confuse the 
user. Like OpenOffice writer can be opened as oowriter. But hey it's 
probably not a bad idea to include the string. Who knows the Chinese 
might do it differently.


    > I hope you have the time, and if so I promise I won't disturb you
   again
    > untill after the 2.18 release ;)

   You're questions are welcome!  You're doing us a great favor.

   Will


Well once again thanks for your quick reply.
Regards Kenneth