Mailing List Archive

On Tue, 20 Oct 2015 09:08, ineiev@gnu.org said:
> I attach a patch against current HEAD to make use
> of ngettext in some places; it also marks two more messages
> localizable.

At the cost of translating a lot more and quite similar strings. This
breaks too many other translations. Although not being correct, it is
better to not apply your patch. Sorry.

Where possible I try to use a table format to avoid plural issues. BTW,
for that reason this hunk would be wrong:

> - log_info (_("permanently loaded certificates: %u\n"),
> + log_info (ngettext(" permanently loaded certificate: %u\n",
> + "permanently loaded certificates: %u\n",
> + total_loaded_certificates),


Salam-Shalom,

Werner


--
Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz.


_______________________________________________
Gnupg-i18n mailing list
Gnupg-i18n@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-i18n

On Wed, Dec 02, 2015 at 06:12:51PM +0100, Werner Koch wrote:
> On Tue, 20 Oct 2015 09:08, ineiev@gnu.org said:
> > I attach a patch against current HEAD to make use
> > of ngettext in some places; it also marks two more messages
> > localizable.
>
> At the cost of translating a lot more and quite similar strings.

The string is the same (it's single msgid); what would be needed
is filling different forms of the words (when the number of plural
forms is more then one, which is not the case for some languages).

> This breaks too many other translations.

To be precise, it makes them 'fuzzy'.

> Although not being correct, it is
> better to not apply your patch. Sorry.

In cases like

- if (n_uids == 1 )
- log_info( _("key %s: \"%s\" 1 new user ID\n"),
- keystr(keyid),p);
- else if (n_uids )
- log_info( _("key %s: \"%s\" %d new user IDs\n"),
- keystr(keyid),p,n_uids);
...
+ if (n_uids)
+ log_info( ngettext ("key %s: \"%s\" %d new user ID\n",
+ "key %s: \"%s\" %d new user IDs\n", n_uids),
+ keystr(keyid),p, n_uids);

the number of messages decreases. will you accept the patch
if I pick such cases?

> Where possible I try to use a table format to avoid plural issues. BTW,
> for that reason this hunk would be wrong:
>
> > - log_info (_("permanently loaded certificates: %u\n"),
> > + log_info (ngettext(" permanently loaded certificate: %u\n",
> > + "permanently loaded certificates: %u\n",
> > + total_loaded_certificates),

I'm not sure this method always works very well.

Thank you!

_______________________________________________
Gnupg-i18n mailing list
Gnupg-i18n@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-i18n

Sgrìobh Werner Koch na leanas 02/12/2015 aig 17:12:
> On Tue, 20 Oct 2015 09:08, ineiev@gnu.org said:
>> I attach a patch against current HEAD to make use
>> of ngettext in some places; it also marks two more messages
>> localizable.
>
> At the cost of translating a lot more and quite similar strings. This
> breaks too many other translations. Although not being correct, it is
> better to not apply your patch. Sorry.
>

Not applying an ngettext patch will be at the cost of all the Slavic
languages and of Arabic, just to name a few examples. You should at the
very least try to always use ngettext when marking up new strings for
translation.

I hope hat I am not sounding too grumpy here, but if you localize a lot
for a language that doesn't follow the English plural pattern, you
sometimes feel like Don Quixote tilting at windmills. The resulting
grammar errors also reflect badly on the localized version of the
software ;)

_______________________________________________
Gnupg-i18n mailing list
Gnupg-i18n@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-i18n

On Thu, 3 Dec 2015 11:03, fios@foramnagaidhlig.net said:

> Not applying an ngettext patch will be at the cost of all the Slavic
> languages and of Arabic, just to name a few examples. You should at the
> very least try to always use ngettext when marking up new strings for
> translation.

And for German as well. We already have way too many translatable
strings (2111 as of today) and using ngettext all over the place would
add a lot more of these strings, code complexity and new bugs.

The majority of users are anyway using a frontend to gpg and thus I
believe it is better to properly translate those GUIs.


Salam-Shalom,

Werner

--
Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz.


_______________________________________________
Gnupg-i18n mailing list
Gnupg-i18n@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-i18n

Sgrìobh Werner Koch na leanas 04/12/2015 aig 09:36:
> On Thu, 3 Dec 2015 11:03, fios@foramnagaidhlig.net said:
>
>> Not applying an ngettext patch will be at the cost of all the Slavic
>> languages and of Arabic, just to name a few examples. You should at the
>> very least try to always use ngettext when marking up new strings for
>> translation.
>
> And for German as well. We already have way too many translatable
> strings (2111 as of today) and using ngettext all over the place would
> add a lot more of these strings, code complexity and new bugs.
>
> The majority of users are anyway using a frontend to gpg and thus I
> believe it is better to properly translate those GUIs.

I agree that the frontends are more important. So yes, do make any
change a as low a cost for everybody as possible :)

_______________________________________________
Gnupg-i18n mailing list
Gnupg-i18n@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-i18n

Hello,

On Fri, Dec 04, 2015 at 10:36:13AM +0100, Werner Koch wrote:
>
> We already have way too many translatable
> strings (2111 as of today) and using ngettext all over the place would
> add a lot more of these strings, code complexity and new bugs.

I don't think this is correct. I've just run msgfmt --statistics for
gnupg2.pot regenerated before and after applying the submitted patch.
before the patch it shows 2111 strings, after patch the count is 2102.
the difference is less than 0.5% (and it's negative). it hardly can
add considerable complexity. (of course I can further rewrite
the patch to eliminate new messages in some cases.)

> The majority of users are anyway using a frontend to gpg and thus I
> believe it is better to properly translate those GUIs.

I'm afraid I don't see the point. it isn't either-or: frontends
can properly internationalize their GUIs, and GnuPG can properly
internationalize it's own messages, at the same time.

Thank you!

_______________________________________________
Gnupg-i18n mailing list
Gnupg-i18n@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-i18n