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 _______________________________________________ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n