Mattias Engdegård wrote:
> This version of the patch is like the previous one, but the prompt labels
> have
> been translated into English as well. This makes them more descriptive and
> easier to understand. As an extra added benefit, it makes them easier to
> translate unambiguously, in parti
This version of the patch is like the previous one, but the prompt
labels have been translated into English as well. This makes them more
descriptive and easier to understand. As an extra added benefit, it
makes them easier to translate unambiguously, in particular single
short words like "
13 apr 2013 kl. 01.31 skrev Daniel Shahaf:
Please use text/* MIME type for attachments.
Yes, sorry about that; the same patch attached, properly typed this
time.
The short codes ("mc", "mf", etc) are also valid as arguments to --
accept.
Perhaps mention that?
I did consider that, but d
Please use text/* MIME type for attachments.
Mattias Engdegård wrote on Fri, Apr 12, 2013 at 22:04:57 +0200:
> + result = apr_pstrcat(pool, result,
> + _("Words in square brackets are the corresponding "
> + "--accept option arguments.\n"),
> +
12 apr 2013 kl. 20.33 skrev Mattias Engdegård:
To make progress, I'll prepare another patch that avoids this
particular point of disagreement.
And here it is. Now the (unlocalised) --accept options are explicitly
shown in the long help, but not the prompt labels, since they are
redundant,
Mattias Engdegård wrote on Fri, Apr 12, 2013 at 20:33:34 +0200:
> 12 apr 2013 kl. 19.52 skrev Daniel Shahaf:
>
>> On Fri, Apr 12, 2013 at 07:44:23PM +0200, Mattias Engdeg?rd wrote:
>>> This is about a user being asked a question in her native language
>>> and
>>> given a set of answers labelled i
12 apr 2013 kl. 19.52 skrev Daniel Shahaf:
On Fri, Apr 12, 2013 at 07:44:23PM +0200, Mattias Engdeg?rd wrote:
This is about a user being asked a question in her native language
and
given a set of answers labelled in that language. Why force her to
reply in a code dissonant to those answers?
On Fri, Apr 12, 2013 at 07:44:23PM +0200, Mattias Engdeg?rd wrote:
> This is about a user being asked a question in her native language and
> given a set of answers labelled in that language. Why force her to
> reply in a code dissonant to those answers?
Because the user should be able to answ
12 apr 2013 kl. 12.21 skrev Branko Čibej:
On 11.04.2013 20:47, Mattias Engdegård wrote:
And if you would agree to that, why should we deny others the same
benefits?
For the same reason that I'd deny them the dubious benefit of, e.g.,
the
following:
nepredznačeno celo_število Fibonacci
On 04/11/2013 02:47 PM, Mattias Engdegård wrote:
> 11 apr 2013 kl. 14.24 skrev C. Michael Pilato:
>
> Do you really claim that any set of single- and two-letter codes is as good
> as another?
No, I cannot make, and am not making, that claim. I do claim the following:
* The long-form conflict a
On 11.04.2013 20:47, Mattias Engdegård wrote:
> Do you really claim that any set of single- and two-letter codes is as
> good as another? I don't think so -- I believe "p" to be better
> answer for "postpone" than "4" or "mc" in English, one that will both
> reach the state of memorisation much qu
11 apr 2013 kl. 14.24 skrev C. Michael Pilato:
On 04/11/2013 03:45 AM, Mattias Engdegård wrote:
[...]
3. The options that appear in the conflict prompt. These, I strongly
believe, should all be translated, since it is essentially a menu of
choices for the user. Note that this means that they w
11 apr 2013 kl. 14.03 skrev Stefan Sperling:
The keys people type at the conflict prompt will eventually become
part of muscle memory. What is mnemonic to one person might not be
mnemonic to someone else.
[...]
In which case having to type different keys
at a menu prompt depending on the langu
On 04/11/2013 03:45 AM, Mattias Engdegård wrote:
> 10 apr 2013 kl. 20.52 skrev Mattias Engdegård:
>
>> In this example, the valid shorthands for --accept ("mc" etc) also
>> double as prompt answers, but that would not have to be the case in
>> translations.
>
> On second thought, perhaps we shoul
On Wed, Apr 10, 2013 at 08:52:49PM +0200, Mattias Engdegård wrote:
> 4. The abbreviated option codes for input at the conflict prompt
> ("e", "mc", etc). I argue for localisation of these to make them go
> with the rest of the conflict prompt and to be mnemonic for the
> user;
I agree with everyth
10 apr 2013 kl. 20.52 skrev Mattias Engdegård:
In this example, the valid shorthands for --accept ("mc" etc) also
double as prompt answers, but that would not have to be the case in
translations.
On second thought, perhaps we should just drop --accept=mc and require
the long word codes fo
9 apr 2013 kl. 16.08 skrev Julian Foad:
In general I think the interactive parts should be localized as much
as possible, and if that means we need to do something special to
the command-line option processing to ensure the same options can be
used both on the command line and interactively
C. Michael Pilato wrote:
> On 04/09/2013 11:45 AM, Branko Čibej wrote:
>> I frankly cannot recall a single tool that localizes its command line,
>> either commands, options or option values. That way lies insanity; you
>> might as well localize C.
>
> Agreed. Madness.
>
>> On the other hand
On 04/09/2013 11:45 AM, Branko Čibej wrote:
> I frankly cannot recall a single tool that localizes its command line,
> either commands, options or option values. That way lies insanity; you
> might as well localize C.
Agreed. Madness.
> On the other hand, I wouldn't mind localizing the interacti
Stefan Sperling wrote:
> On Tue, Apr 09, 2013 at 03:08:33PM +0100, Julian Foad wrote:
>> I assume you mean the command line is not translated as a matter of
>> policy? Technically I see no reason why it cannot be translated. If
>> the reason why we don't is so that scripts can be locale-independe
On 09.04.2013 16:27, Stefan Sperling wrote:
> On Tue, Apr 09, 2013 at 03:08:33PM +0100, Julian Foad wrote:
>> I assume you mean the command line is not translated as a matter of
>> policy? Technically I see no reason why it cannot be translated. If
>> the reason why we don't is so that scripts ca
On Tue, Apr 09, 2013 at 03:08:33PM +0100, Julian Foad wrote:
> I assume you mean the command line is not translated as a matter of
> policy? Technically I see no reason why it cannot be translated. If
> the reason why we don't is so that scripts can be locale-independent,
> then it would still be
Stefan Sperling wrote:
> On Mon, Apr 08, 2013 at 10:15:33AM +0100, Philip Martin wrote:
>> Mattias Engdegård writes:
>>
>> > The conflict prompt is no longer localised, probably because of an
>> > oversight.
[...]
>> Do we want the long options localised? If I run
>>
>> svn update --ac
8 apr 2013 kl. 12.06 skrev Stefan Sperling:
So I think it is OK to have short menu option names in English and
provide
long descriptions in the native language.
Does that work for you, Mattias? Of course, if there is anything we're
doing in the code that makes translation harder than necessar
8 apr 2013 kl. 11.15 skrev Philip Martin:
Mattias Engdegård writes:
The conflict prompt is no longer localised, probably because of an
oversight.
Were they localised in the past?
Yes, they were. This is what happens in 1.7:
$ LC_ALL=fr_FR.UTF-8 svn up
Conflit découvert dans '/Users/matti
On Mon, Apr 08, 2013 at 10:15:33AM +0100, Philip Martin wrote:
> Mattias Engdegård writes:
>
> > The conflict prompt is no longer localised, probably because of an
> > oversight.
>
> Were they localised in the past?
>
> > Index: subversion/svn/conflict-callbacks.c
> > ==
Mattias Engdegård writes:
> The conflict prompt is no longer localised, probably because of an
> oversight.
Were they localised in the past?
> Index: subversion/svn/conflict-callbacks.c
> ===
> --- subversion/svn/conflict-callbacks
27 matches
Mail list logo
