Jeff King writes:
> On Thu, Mar 30, 2017 at 05:18:59PM +0200, Michael J Gruber wrote:
>
>> 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 loo
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 writes:
> >>
> >>> Yes, I would think die_errno() is a no-brainer for translation, since
> >>
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 writes:
>>
>>> Yes, I would think die_errno() is a no-brainer for translation, since
>>> the strerror() will be translated.
>>>
apply.c:die(_("
On Wed, Jan 11, 2017 at 09:15:22AM -0800, Stefan Beller wrote:
> > That's the assumption I'm challenging. Certainly the behavior and
> > certain aspects of the output of a plumbing command should remain the
> > same over time. But error messages to stderr?
>
> In an ideal world that assumption wo
On Wed, Jan 11, 2017 at 10:08:46AM -0800, Junio C Hamano wrote:
> Jeff King 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 t
On Fri, Jan 20, 2017 at 08:08:43PM +0700, Duy Nguyen wrote:
> > In addition, "BUG: " is relatively recent introduction to our
> > codebase. Perhaps having a separate BUG() function help the
> > distinction further?
>
> I was going to write the same thing. On top of that I wonder if have
> enough
On Fri, Jan 20, 2017 at 8:23 PM, Duy Nguyen wrote:
> I've tested it a bit. Seems to work ok.
Oops. Didn't notice that the "fatal:" bit is still untranslated but
Micheal's patch can handle that.
--
Duy
On Wed, Jan 11, 2017 at 06:37:25AM -0500, Jeff King wrote:
> > To find a good example, "git grep die" giving me some food of though:
> >
> > die_errno(..) should always take a string marked up for translation,
> > because the errno string is translated?
>
> Yes, I would think die_errno() is a no-
On Thu, Jan 12, 2017 at 1:08 AM, Junio C Hamano wrote:
> Jeff King 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 su
Jeff King 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 w
On Wed, Jan 11, 2017 at 3:37 AM, Jeff King wrote:
> On Tue, Jan 10, 2017 at 10:28:42AM -0800, Stefan Beller wrote:
>
>> > And then presumably that mix would gradually move to 100% consistency as
>> > more messages are translated. But the implicit question is: are there
>> > die() messages that sho
On Tue, Jan 10, 2017 at 10:28:42AM -0800, Stefan Beller wrote:
> > And then presumably that mix would gradually move to 100% consistency as
> > more messages are translated. But the implicit question is: are there
> > die() messages that should never be translated? I'm not sure.
>
> I would assum
On Tue, Jan 10, 2017 at 1:04 AM, Jeff King wrote:
> On Mon, Jan 09, 2017 at 01:43:15PM +0100, Michael J Gruber wrote:
>
>> > I can't say I'm excited about having matching "_" variants for each
>> > function. Are we sure that they are necessary? I.e., would it be
>> > acceptable to just translate t
On Mon, Jan 09, 2017 at 01:43:15PM +0100, Michael J Gruber wrote:
> > I can't say I'm excited about having matching "_" variants for each
> > function. Are we sure that they are necessary? I.e., would it be
> > acceptable to just translate them always?
>
> We would still need to mark the strings,
Jeff King venit, vidit, dixit 04.01.2017 08:05:
> On Mon, Jan 02, 2017 at 12:14:49PM +0100, Michael J Gruber wrote:
>
>> Currently, the headers "error: ", "warning: " etc. - generated by die(),
>> warning() etc. - are not localized, but we feed many localized error messages
>> into these functions
On Wed, Jan 4, 2017 at 8:25 PM, Duy Nguyen wrote:
> On Wed, Jan 4, 2017 at 2:45 AM, Stefan Beller wrote:
>>> In this implementation, the gettext call for the header and the body are
>>> done
>>> in different places (error function vs. caller) but this call pattern seems
>>> to
>>> be the easies
On Wed, Jan 4, 2017 at 2:45 AM, Stefan Beller wrote:
>> In this implementation, the gettext call for the header and the body are done
>> in different places (error function vs. caller) but this call pattern seems
>> to
>> be the easiest variant for the caller, because the message body has to be
On Mon, Jan 02, 2017 at 12:14:49PM +0100, Michael J Gruber wrote:
> Currently, the headers "error: ", "warning: " etc. - generated by die(),
> warning() etc. - are not localized, but we feed many localized error messages
> into these functions so that we produce error messages with mixed
> locali
On Mon, Jan 2, 2017 at 3:14 AM, Michael J Gruber
wrote:
> Currently, the headers "error: ", "warning: " etc. - generated by die(),
> warning() etc. - are not localized, but we feed many localized error messages
> into these functions so that we produce error messages with mixed
> localisation.
>
On Mon, Jan 2, 2017 at 6:14 PM, Michael J Gruber
wrote:
> Currently, the headers "error: ", "warning: " etc. - generated by die(),
> warning() etc. - are not localized, but we feed many localized error messages
> into these functions so that we produce error messages with mixed
> localisation.
>
Currently, the headers "error: ", "warning: " etc. - generated by die(),
warning() etc. - are not localized, but we feed many localized error messages
into these functions so that we produce error messages with mixed localisation.
This series introduces variants of die() etc. that use localised va
21 matches
Mail list logo
