GNOME Bugzilla – Bug 309039
typos in the .po file
Last modified: 2005-09-28 12:04:09 UTC
gnopernicus bugs 1. po:112 reference: ⑤ ../gnopi/cmdmapui.c:98 Original: ⌘0 detailed informations "information" is already plural: it's a mass noun, like water and rice. 2. .po:382 reference: ⑤ ../gnopi/gnopi_files/Find/find.glade2.h:20 Original: ⌘0 Search criteria is a graphics Việt: .po:383 reference: ⑤ ../gnopi/gnopi_files/Find/find.glade2.h:21 Original: ⌘0 Search criteria is a text Việt: .po:384 reference: ⑤ ../gnopi/gnopi_files/Find/find.glade2.h:22 Original: ⌘0 Search criteria is an attribute Is each string about one _criterion_, or about several _criteria_? (Greek root, so irregular plural structure.) Thus either: "Search criteria are graphics" or "Search criterion is a graphic" is correct for .po:382 The other two appear to be singular, so should be: "Search criterion is a piece of text" and "Search criterion is an attribute" 3. The file uses both "crosshair" and "cross-hair" repeatedly: it would be less confusing both for translators and for users if one spelling was chosen. 4. po:590 reference: ⑤ ../gnopi/gnopi_files/Speech_Settings/speech_settings.glade2.h:60 Original: ⌘0 Replecement "Replacement" 5. po:1139 reference: ⑤ ../srcore/srspc.c:1004 Original: ⌘0 Tildaes "Tildes" See en.wiktionary.org…Tilde 6. Starting with these two strings: po:1138 reference: ⑤ ../srcore/srspc.c:1004 Original: ⌘0 Tilde .po:1139 reference: ⑤ ../srcore/srspc.c:1004 Original: ⌘0 Tildaes you have a long section of singular and plural strings in turn. I strongly suggest you use the plural msgid form, because different languages have different numbers of plural forms. My language doesn't have plural nouns in that way, so I had to fill in two strings each time where my plural header would have picked that up and only supplied one field. Other languages have more plural forms than English does. Please see the gettext manual on plural strings: gnu.org…gettext.html#SEC150 7. po:1156 reference: ⑤ ../srcore/srspc.c:1013 Original: ⌘0 Left Paranthesis .po:1157 reference: ⑤ ../srcore/srspc.c:1014 Original: ⌘0 Right Paranthesis "Parenthesis" (easy to remember if you note that brackets are the "parents" of what's inside them. 8. po:1202 reference: ⑤ ../srcore/srspc.c:1572 Original: ⌘0 speech initialization succeded "succeeded" (long e sound)
>you have a long section of singular and plural strings in turn. I strongly >suggest you use the plural >msgid form, because different languages have different numbers of plural forms. >My language doesn't >have plural nouns in that way, so I had to fill in two strings each time where my >plural header would >have picked that up and only supplied one field. Other languages have more plural >forms than English >does. Please see the gettext manual on plural strings: >gnu.org…gettext.html#SEC150 This is true, but not easy to be solved. If those forms are not in a ngettext call, then they are not marked for plural instruction (the case of tables). For moment I see no chance to change this.
Remus, why can't we use ngettext here? Is it because glade doesn't support ngettext?
The code is something like: struct OneMany { gchar ch; gchar *one; gchar *many; }one_may[] = { {'?', N_("question mark"), N_("question marks")}; ......... } and later: ch=.... (in our case '?') cnt = ..... (1,2,....) index= get_index (ch); /* the issue is in the code below */ if (cnt == 1) printf ("%s", _(one_many[index].one)); else printf ("%s", _(one_many[index].many)); an implementation is printf (ngettext (cnt, one_many[index].one, one_many[index].many)); but, this implementation will not generate the right output, because the table items are marked only for translation and not for pural. One of the right solution is if (ch=='?') printf (ngettext (cnt, "question mark", "question marks")); else...... But, in this case the solution with tables cannot be used.
Created attachment 49710 [details] [review] Proposed patch
Comment on attachment 49710 [details] [review] Proposed patch I think we should be using "crosswire" instead of 'cross-hair'; although sometimes "crosshair" is used to mean the same thing, "crosshair" is also used to refer to the "cross shaped" cursor, as opposed to 'wires' that extend over the whole screen (for instance, the "crosshair cursor"). Also, it seems that "crosshair" is preferred over "cross-hair" even in that case. Now would be a good time also to search for comments like "TO BE TRANSLATED", and actually mark them (there is one at the end of the patch, for instance). Rest of patch looks good, thanks!
Created attachment 50054 [details] [review] reworked patch
Comment on attachment 50054 [details] [review] reworked patch "Search criterion is a text" seems odd, since 'text' is normally a mass noun. How about "Search criterion is text" ? Rest of patch is good, thanks! Also, please remember not to use C++-style comments "//" in your C code, I see that the patch removes a few of these.
Created attachment 50060 [details] [review] reworked patch
Remus, it looks like you've addressed Bill's comments - no more C++ style comments and the "is a text" problem is fixed. Please go ahead and apply the patch.
Created attachment 51111 [details] [review] Proposed patch to mark strings for translation Mark strings for translation.
Created attachment 51112 [details] [review] Proposed patch to fix some typos Correct translation for some strings.
Patch from comment #10 committed to CVS head.
The patch applied appears to break the compilation of gnopernicus in two instances. See: http://bugzilla.gnome.org/show_bug.cgi?id=314824 For example, in - fprintf(stderr, _("BrlAPI detected a %dx%d display\n)", dd.x, dd.y); + fprintf(stderr, _("BrlAPI detected a %dx%d display\n"), dd.x, dd.y); In addition, GNOME is in string freeze at the moment, meaning that no new translatable strings can be added to the core packages (gnopernicus is one of them), unless there is approval from the gnome-i18n mailing list. There has been a discussion on this at gnome-i18n, see: http://mail.gnome.org/archives/gnome-i18n/2005-August/thread.html#00303 Is this patch critical to gnopernicus so that it justfies inclusion to GNOME 2.12? In any case, if the patch remains, please attend to http://bugzilla.gnome.org/show_bug.cgi?id=314824
The brltty support is not installed by default. The compilation break appears _ONLY_ when brltty is installed.
Patch from comment #11 committed to CVS head.
Did you branch gnopernicus for gnome-2.12 first? Should do that before breaking string freeze... and need to announce this to desktop-devel-list and the gnome-i18n-list Bill