Re: fprintf_ln() is slow

From: Duy Nguyen <pclouds@gmail.com>
Date: Jun 27, 2019, 12:32 UTC
Message-ID: <CACsJy8AgmM0xYMMdYvpRSs4JRbNahcQyGcMMfPmaTS4Uv=Ok6A@mail.gmail.com>
In-Reply-To: <8736jv8bnc.fsf@evledraar.gmail.com>

On Thu, Jun 27, 2019 at 7:18 PM Ævar Arnfjörð Bjarmason <avarab@gmail.com> wrote:

Show 11 quoted lines

> Why shouldn't we just move back to plain fprintf() with "\n"? Your
> 9a0a30aa4b ("strbuf: convenience format functions with \n automatically
> appended", 2012-04-23) doesn't explain why this is a convenience for
> translators.
>
> When I'm translating things tend to like knowing that something ends in
> a newline explicitly, why do we need to hide that from translators? They
> also need to deal with trailing \n in other messages, so these *_ln()
> functions make things inconsistent.
>
> It's also not possible for translators to do this by mistake

This (accidentally dropping \n which sometimes is significant) is the part that I made me prefer *printf_ln(). I had been translating for years, as far back as 2003-ish, but I've stopped since the last few years so I'm no longer uptodate with gettext development. And my very old/outdated experience with gettext might make me think it's still the problem.

> without
> being caught, because msgfmt will catch this (and other common issues):
>
>     po/de.po:23: 'msgid' and 'msgstr' entries do not both end with '\n'

Ok good. And with the downside of degraded performance, sure remove all the *printf_ln()

-- 
Duy