Re: [PATCH v2 2/2] i18n: mark OPTION_NUMBER (-NUM) for translation

From: Junio C Hamano <gitster@pobox.com>
Date: Feb 6, 2013, 15:47 UTC
Message-ID: <7va9rho350.fsf@alter.siamese.dyndns.org>
In-Reply-To: <CACsJy8DcXuFqjBtufQq1-0Vm3H4uxs03Crx+akY-kbrVgY8vUw@mail.gmail.com>

Duy Nguyen <pclouds@gmail.com> writes:

> How about utf8_fwprintf? wprintf() deals with wide characters and
> returns the number of wide characters, I think the name fits. And we
> could just drop utf8_ and use the existing name, because we don't use
> wchar_t* anyway.

Please, no. That line of reasoning shows a horrible design taste (or lack of taste). "We don't use X right now" (or "We will promise never to use X", for that matter) is never a good reason to abuse a name that normal people would closely associate with X to something that is completely different. That leads to more confusion, not less.

I guess utf8_fprintf() is not so bad after all. fprintf() without the utf8_ prefix is perfectly capable of showing a string encoded in UTF-8, and anybody can correctly guess that the magic utf8_ prefix would introduce (i.e. the difference between utf8_fprintf and fprintf) can only be about the return value. It can be reasonably expected that everybody would then know that the display column count can be the only sane return value that is different from what fprintf() would return.