Re: [RFC PATCH 0/5] Localise error headers

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thu, Mar 30, 2017 at 05:18:59PM +0200, Michael J Gruber wrote:

> Jeff King venit, vidit, dixit 21.01.2017 15:20:
> > On Wed, Jan 11, 2017 at 10:08:46AM -0800, Junio C Hamano wrote:
> > 
> >> Jeff King <peff@xxxxxxxx> writes:
> >>
> >>> Yes, I would think die_errno() is a no-brainer for translation, since
> >>> the strerror() will be translated.
> >>>
> >>>>     apply.c:                die(_("internal error"));
> >>>>
> >>>> That is funny, too. I think we should substitute that with
> >>>>
> >>>>     die("BUG: untranslated, but what went wrong instead")
> >>>
> >>> Yep. We did not consistently use "BUG:" in the early days. I would say
> >>> that "BUG" lines do not need to be translated. The point is that nobody
> >>> should ever see them, so it seems like there is little point in giving
> >>> extra work to translators.
> >>
> >> In addition, "BUG: " is relatively recent introduction to our
> >> codebase.  Perhaps having a separate BUG(<string>) function help the
> >> distinction further?
> > 
> > Yes, I think so. I have often been tempted to dump core on BUGs for
> > further analysis. You can do that by string-matching "BUG:" from the
> > beginning of a die message, but it's kind of gross. :)
> > 
> > -Peff
> 
> I read back the whole thread, and I'm still not sure if there's
> consensus and how to go forward. Should we let the topic die? I don't
> care too much personally, I just thought the mixed tranlations look
> "unprofessional".

I don't have a strong preference either way. I also don't care
personally about the output (as I do not localize at all). My main
concern was keeping the code simple for developers. But if consistent
translation is important for people in other languages, I'm OK with
whatever we need to do.

-Peff



[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]