Re: Do "enabled", "disabled", and "not found" need to be qualified per instance?

[Joanmarie Diggs <joanmarie diggs gmail com>]

Hey Petr.

Thanks so much for the info!
 
> However, as long as those adjectives like "enabled" or "disabled" aren't
> incorporated into a sentence or sentence fragment, but are placed in a
> string of their own, it's often the case in i18n not to qualify per
> instance and respect various gender and declension forms, but to use
> a "general, one-gender, one-case" term that refers to all strings with the
> appropriate meaning. (In my West Slavic language [Czech], we often make use
> of the neuter gender singular nominative case for that purpose.)

Right. These words won't be part of a sentence or fragment. So the
gender and number (if required in a particular language) would be for an
object which is understood by the user, but not explicitly
stated/included in the string.

> Nevertheless, I wouldn't count that in best i18n/l10n practices, really.

The Orca team aims to do what's best practice. Therefore we will qualify
each instance. Thanks!

Follow-up question w.r.t. "not found": There are (at least) a couple of
general categories of things for which we might want to say "not found":

1. Performing a search for text displayed on screen (e.g. in a widget
that wouldn't otherwise be searchable by the user)

2. Looking for a 'structural navigation' object.

As stated above, we will qualify each. Something like:

  C_("text", "not found")
  C_("structural navigation", "not found")

with each having the appropriate, context-specific translator note
explaining exactly what that "not found" string is all about.

The thing is, there are a bunch of "structural navigation" objects in
Orca which can be "not found". In particular:

* Anchors
* Blockquotes
* Buttons
* Check boxes
* Chunks/Large Objects
* Combo boxes
* Entries
* Form fields
* Headings (regardless of level)
* Headings at a particular level
* Landmarks
* Lists
* List items
* Radio buttons
* Separators
* Tables
* Table cells
* Unvisited links
* Visited links

What those items have in common is that they're all things in a document
(most often a web page) that a user attempted to move to using Orca's
structural navigation feature. With that in mind, which is best
practice:

  C_("structural navigation", "not found")

or:

  C_("anchor", "not found")
  C_("blockquote", "not found")
  C_("button", "not found")
  [...]

And/or is there a certain point at which "best practice" loses out to
"there are already a bazillion strings in Orca. Please stop with the new
strings already." <silly grin>

Either way, let us know what you prefer and we'll be happy to do it.
(For what it's worth, structural navigation is the most extreme example.
I'm not anticipating that there will be that many additional, "short"
strings resulting from this new setting.)

> In the end, a context is what counts the most for translators. Also, I
> think that Orca is the excellent example of providing a good portion of
> useful context information to their translators, so thanks for that.

No need to thank us. We do it out of gratitude and appreciation for your
work. You guys make it possible for blind computer users around the
world to have independent access to software and information in their
preferred language. I think that's amazing.

--joanie